New OAuth redirect_url requirement for static URI

> "After February 14th, 2022, the redirect URL sent in the Authorization request must exactly match the redirect URL in the Developer Dashboard or it will error."

How is a web developer supposed to provide an application that supports many sites meet these new restrictions? I.e. the redirect_url is static while some of the parameters are actually dynamic. Eg. I use the ‘state’ parameter to determine the domain name and other parameters used to identify the site so I can send it the authorization code via a secure API request from the OAuth server. All the other parameters are static so they can be put in the new redirect_url. However, I believe the ‘state’ parameter should be exempted from this requirement.

How is one supposed provide a static url for dynamic information?

:wave: Typically the state parameter is separate from the redirect parameter and it’s returned in the callback.

For example if this request is made:
https://connect.squareup.com/oauth2/authorize?client_id=<id>&scope=MERCHANT_PROFILE_READ&redirect_uri=http://localhost:8000/callback&state=StateTest

The response would be:
http://localhost:8000/callback?code=<authCode>&response_type=code&state=StateTest

You will still have access to whatever you pass in to the state variable in the callback and that shouldn’t be part of the redirect_url. :slightly_smiling_face:

One of us is confused… Most likely me.

The email discussed the “redirect_url” (URL) set in the application panel which is intended to point to the OAuth server. The “redirect_uri” (URI) in the parameters is a hint for the OAuth server where it should redirect to with the authorization_code, merchant_id, etc.

So my question is, how do I set a static “redirect_url” (URL) in the developer’s application panel to be a static value when things like the ‘state’ parameter is dynamic?

I’m sure you have it, but here’s the email that was sent.

We are making a change to how our oAuth service handles the redirect URL. Currently the redirect URL configured in the Developer Dashboard only needs to match a subset of the URL passed in the Authorization request.

Current State Example

If the redirect URL in the Developer Dashboard is configured to: https://example.com/

And the redirect_uri parameter in the authorization request is: https://connect.squareup.com/oauth2/authorize?client_id=abcd-1234-zyxw&scope=PAYMENTS_READ&redirect_uri=https://example.com/oauth-redirect

Then the request succeeds because the first part of the redirect_uri parameter matches the configured redirect URL.

After February 14th, 2022 , the redirect URL sent in the Authorization request must exactly match the redirect URL in the Developer Dashboard or it will error.

Exact Match Example

If the redirect_uri parameter in the authorization request is:

https://connect.squareup.com/oauth2/authorize?client_id=abcd-1234-zyxw&scope=PAYMENTS_READ&redirect_uri=https://example.com/oauth-redirect

Then the redirect URl in the Developer Dashboard must be configured to:

https://connect.squareup.com/oauth2/authorize?client_id=abcd-1234-zyxw&scope=PAYMENTS_READ&redirect_uri=https://example.com/oauth-redirect

To prepare for this change, you need to update the Developer Dashboard to match the URL in the Authorization request. If all of your Authorization requests already match the Developer Dashboard-set redirect URL, you do not need to take any action. If you have any questions or concerns please reach out to us via Slack, our forums, or developer support.

Possibly this is what’s confusing… The “redirect URL” above should be “redirect URI”.

But I still can’t provide a static value for a dynamic parameter. Right now, I don’t even send a redirect_uri parameter so it seems to default to whatever I had set in the developer application panel for ‘redirect URL’ which is a domain name only. I.e. ‘https://mydomain.com/square

Can I get a response?

Upon even further detailed reading, the email has other issues as well.
1 - There is no “redirect URI” in the developer panel. However, there is a “redirect URL”.
2 - It states that in the example, the "redirect URI in the Developer Dahsboard must be configured to: https://connect.squareup.com/oauth2/authorize?client_id=abcd-1234-zyxw&scope=PAYMENTS_READ&redirect_uri=https://example.com/oauth-redirect which makes no sense at all. Why would one configure the “redirect URL” to the authentication request? I’m assuming what they mean is “redirect URI (correcting this to URL) in the Developer Dahsboard must be configured to: *https://example.com/oauth-redirect

So should I assume that if I set “redirect_uri=https://mydomain.com/square” and have the Developer Dashboard as “https://mydomain.com/square” that the OAuth sever will pass the parameters passed in the authorization request to that URL?

Could you provide an example of what their authorize request currently looks like?

The redirect_uri parameter is not a required parameter when making the authorize request and in this case it will just redirect to what is set in Developer Dashboard. If you are currently not passing anything for the redirect_uri when making the authorize call then you are already using strict redirect and should be good.

Then I’d strongly suggest that someone fix and resend the email. It is missleading and contains erroneous information (as I’ve detailed above for your QA team).

A current authorize request looks like:

https://connect.squareup.com/oauth2/authorize?client_id=1234s&session=false&scope=MERCHANT_PROFILE_READ PAYMENTS_READ PAYMENTS_WRITE CUSTOMERS_READ CUSTOMERS_WRITE ITEMS_READ ITEMS_WRITE ORDERS_READ ORDERS_WRITE&state=client_domain.com-123

My Dev Panel redirect URL is ‘auth.my_site.com/square’.

Where the ‘state’ parameter (client_domain.com-123) is the domain_name of the site and the 123 is the payment_id. I expect the state parameter to be passed to auth.my_site.com/square?state=client_domain.com-123 with the other parameters such as merchant_id, auth code, etc. Which I in turn pass back to the client site.

We’re constantly working to improve our products and services based on the feedback we receive from customers. I’ll be sure to share this with the appropriate team.