Setting up authentication but need a variable redirect URI

[MartinG105]

Hi there,

I am setting up a Wordpress plugin which will enable end users to sign up to one of their Constant Contact lists. I am following these instructions here about oauth:

http://developer.constantcontact.com/docs/authentication/oauth-2.0-client-flow.html 

The problem I am having is that the redirect URI can only be a single URL, but I need it to go the customers Wordpress website. So this isn't going to work. I was hoping I could pass an additional query string paramter so I could then do a 2nd redirect from my website back to their Wordpress website, but I can't pass in any additional parameters. 

How do I go about solving this issue? Is the solution with like a SSO as detailed here: https://developer.constantcontact.com/docs/account-management/sso.html  it says: Approved Constant Contact technology partners selling Toolkit can integrate with Constant Contact's Single Sign On how do I go about becoming a technology partner? If this is what I need to do?

Your help is much appreciated!

Thanks,

[Elijah_G · Accepted solution]

Hello,

The best solution to this issue involves having a very minimal hosted page under your control that can be used as the redirect, which would then pass the request back to wordpress. This can be done by taking advantage of OAuth 2.0 allowing query parameters to be freely appended to the redirect URI. So for example, you can set up your redirect URI as http://www.google.com and then send http://www.google.com?redirect=yahoo.com with the actual authorization request. This process would allow the page you control to read the "redirect" parameter and simply forward the request along, including any relevant OAuth parameters. It is also very important to mention that this specific process only works with the Server flow rather than the Client flow.

To give a bit of clarity on the two flows, the client flow is created for implementations such as a mobile app where you need to capture the token from a browser object and store it locally. The client flow accomplishes this by appending the token as a URL fragment, which cannot be passed along in the scenario I described above. The server flow is better suited to applications such as a wordpress plugin due to the dynamic URL. 

Hopefully this provides some clarity, but please let me know if there's any questions!

Sincerely

[MartinG105]

Thanks so much Elijah, I am sure I can get this working now. I was on the right track but using the wrong protocal like you said.

Thanks once again, 

[GregB3955]

Hey there!

I found this thread searching for the same thing. In our case, our app is multi-tenant, so each account is scoped using a subdomain (like basecamp and slack).

I was happy to read your response and see that I could use url parameters to differentiate which account was making the call, but then I saw a message explicitly stating that this is not possible:

Would you mind double checking as to the current status as far as the ability to use url parameters? I'm hoping this message isn't true / outdated?

[David_B.]

Hello Greg,

This information means that URL Query Parameters are not allowed within your registered redirect URI. You can use them in practice, they just can't be stored as a part of your registered redirect URI within Mashery.

Regards,
David B.
Tier II API Support Engineer

[GregB3955]

Got it! Thanks! I was able to get our app set up using a generic redirect URL in the constant contact API settings, and then passed in a subdomain parameter to properly redirect the user when they authorize.

[user24983]

Hi API support team,

Can you confirm if this method can still work with the v3 API? I found the refresh token will be invalidated/revoked once another refresh token is generated (say I have two sites and they are authenticated in the same app with the same CTCT account).

Thus I feel this "having a very minimal hosted page under your control that can be used as the redirect" method cannot work with v3 API anymore. Can you clarify this for me? Thanks!

[Jimmy_D]

Hi @user24983,

This method can still work. It sounds like you have two different locations that a user can authorize. If that is the case are both locations for the exact same application or do they do different things? If they are for the exact same application then I ask why can the user authorize in two different places? If the applications do different things then I suggest to add a second API Key for your second application that way the different authorizations do not interfere with each other.

[user24983]

Hi Jimmy,

> If they are for the exact same application then I ask why can the user authorize in two different places?

Yeah because it's a WordPress plugin so a user can install it on multiple sites with just one account.

From the answer of this approach:

> The best solution to this issue involves having a very minimal hosted page under your control that can be used as the redirect, which would then pass the request back to wordpress.

In this scenario, do you mean the user should still pass their own API keys instead of just using ours (we registered an app for this minimal hosted page)? If so, then it will work like:

1. We provide this minimal hosted page URL to our users.

2. Users register their application with our URL as the return URI.

3. Users pass their API keys to our minimal hosted page (for authentication) and get redirected to their website.

Can you clarify this a bit? Thanks!

[Jimmy_D]

Hi @user24983,

We never recommend to have your customers get their own API Key. In this scenario you can have multiple Access Tokens to the same Constant Contact account with the v3 API. I just tested this to verify it works. Please keep in mind that an Access Token expires after 24 hours so it will have to be refreshed. However; if you have written a complete oAuth flow then each individual install of your application should be just fine as it will authenticate and refresh correctly as needed.

[user24983]

Hi Jimmy,

Thanks for your reply. 

> In this scenario you can have multiple Access Tokens to the same Constant Contact account with the v3 API. I just tested this to verify it works.

Yes this works for sure. I can get multiple Access Tokens in my websites. The issue is that I CANNOT refresh tokens. When the access token expired and I tried to refresh token, only the last authorized website can get the tokens, but not the others. I got the 400 error with a message like this:

{"error_description":"unknown, invalid, or expired refresh token","error":"invalid_grant"}

That's why I suspect the refresh token is invalidated every time when I authorize a new website. To reproduce this, can you try:

1. Authorize on multiple websites.

2. Refresh tokens on all sites.

3. See if you can get all sites the refreshed tokens, or if the error message shows up. 

If it works at your end, can you explain in what scenario I could get the above error message? Thanks! 

[Jimmy_D]

Hi @user24983,

You are correct. I was going through the Access Token phase, but did not go through the Refresh Token phase. You can get multiple Access Tokens, but when you then try to refresh those it "breaks" the tokens. I was only able to refresh one token.

It appears this is set up purposefully for security reasons. I understand your scenario of having one Constant Contact account connected to two different installations (websites). Can you tell me how often this occurs with your plugin? I'll take this to our engineers with your use case and the amount of times you run in to this and see what they say.

[user24983]

Hi Jimmy,

Thanks for your reply. I understand this could be for security reasons. I noticed in CTCT API we cannot revoke a refresh token and I guess that's why such auto invalidation is needed.

As to how often would this occur, from my experience it's very common to have subscription forms on websites nowadays, especially for marketing websites. And it's also very common, as you can imagine, that CTCT customers could run multiple websites and taking subscriptions from different websites and send them to different lists to segment contacts, it's how email marketing businesses work these days. 

If there's no solution we need to make the customers aware of it (or our plugin will look buggy). And we then probably suggest users register their apps if that's the case. We'd really appreciate if it's something can be changed in the API, since we all know for non-techy people, registering their own apps will be a challenging work.

When you get the chance, can you let me know your team's decision on it? Thank you!