Auth0-spa-js: Authorization code flow sends incorrect redirect_url parameter

Created on 21 Nov 2019  路  13Comments  路  Source: auth0/auth0-spa-js

Description

Following oAuth authorization code flow first user is redirected to /authorize endpoint and one of the parameters is redirect_url for callback url. That part works just fine, however there is issue with later step - code for token exchange. Callback url receives code, state etc. parameters to perform token exchange but /oauth/token endpoint receives incorrect redirect_uri. The culprit seems to be this line: https://github.com/auth0/auth0-spa-js/blob/2ace866d33cefc8140dceae7437e2a9e61469564/src/utils.ts#L195

The following statement strips out the path and query string parts of the url. This parameter should be populated either with redirect_url that's present in the client instance or retrieved (if it's saved) from corresponding state object.

Even Auth0 documentation states that both redirect_url parameters sent to /authorize and /oauth/token must be the same: https://auth0.com/docs/api-auth/tutorials/authorization-code-grant-pkce#4-exchange-the-authorization-code-for-an-access-token

Reproduction

  1. Set redirect_url on the client config to https://some-domain.com/callback and proceed with authorization code flow.
  2. After signing in and redirect to provided redirect_url code for token exchange takes place
  3. Parameter redirect_url sent to /oauth/token has value of: https://some-domain.com

Environment

  • Version of this library used: 1.3.2
bug

Most helpful comment

Thanks for the info @H4kor. I'm hoping to put a patch out next week that includes this change, it's just waiting on a couple of other PRs being finalized. If you can work with the branch for now, I'll update when this patch goes out.

All 13 comments

@LKay Can you let me know what specific error you're seeing or how this is blocking you?

I鈥檓 getting 401 with access denied error. This only happens if the application on auth0 is not of SPA type. In such case redirect_uri parameter in token exchange seems to be ignored. However, if application type is of other type ie. generic with authorization code grant enabled, above error is returned even if it鈥檚 configured proper according to docs. It blocks use of applications other than SPA.

Thanks @LKay. I'm interested in your use-case here; given that this is the SDK for SPAs, we would expect you to be connecting to a client that is configured as a Single Page Application. If you're saying that works, I'm keen to find out why you would be using any other application type.

For what it's worth I'm seeing the exact same behavior:

  • Authorize endpoint is called using the redirect_uri: http://localhost:4200/redirect
  • When we have an active session on the Authorization server, the Authorize request returns a 302, with the location set to http://localhost:4200/redirect, including a code and state query string parameter.
  • The token call, used to exchange the Authorization Code for the Token is including a different redirect_uri, for the /token endpoint it's sending http://localhost:4200.

Can you let me know what specific error you're seeing or how this is blocking you?

Myself, I am not seeing any error or nothing is blocking me. However, the behavior I'm seeing is not inline with the documentation of Auth0, where it explicitly mentions that both redirect_uri's need to be identical.

image

Also, looking at the source code of the SPA SDK, we have no control over the redirect URI as it's being hardcoded to window.location.origin (hardcoding this will make it very hard to ensure it's the same as the one sent to the /authorize endpoint), see: https://github.com/auth0/auth0-spa-js/blob/master/src/utils.ts#L195

I think we want to be doing something like this: https://github.com/auth0/auth0-spa-js/blob/master/src/Auth0Client.ts#L365.

I mentioned:

I think we want to be doing something like this: https://github.com/auth0/auth0-spa-js/blob/master/src/Auth0Client.ts#L365.

However, it looks like this is not true and looks like this is also a bug in the SDK, which is tangentially related to the current issue.
The spec clearly mentions that the redirect_uri is optional for the /authorize request. Falling back to window.location.origin will ensure the redirect_uri always has a value while the spec defines this differently, see: https://tools.ietf.org/html/rfc6749?fbclid=IwAR0b9o_ARDWZyVl_acrf4PFoP22VJvwXzZv8BxmhcG1PNac0t-rpU7CcHdM#section-4.1.1

So to summarize, it looks like there are two issues regarding redirect_uri:

  • Spec defines that the redirect_uri, that's being sent to the /token endpoint has to be identical to the one that's being sent to the /authorize endpoint
  • Spec defines that the redirect_uri for the /authorize endpoint is optional, so falling back to the window.location.origin doesn't sound to be in line with the spec.

So I think for both /authorize and /token we should never fall back on the window.location.origin value.

@frederikprijck Thanks for providing the additional context. Let me follow up internally about how to proceed with this.

@frederikprijck So the outcome of this is that we will change the behaviour so that it does send the same redirect_uri value to both endpoints as defined in the spec.

As for the value being optional, we're not too concerned about this. auth0-spa-js is not designed as a generic OAuth client and we're fine with always sending a value here.

Thanks for raising the issue!

Hey. Just stumbled over this bug and it is blocking for me. Have seen that there already is a fix on the branch fix/redirect-uri.

Will this be merged/released any time soon?

@H4kor can you tell me more about why it's blocking for you? What is your situation?

@stevehobbsdev I have a SPA wrapped with capacitor. The callback url is <package_id>://callback but inside the app window.location.origin is http://localhost. The call to oauth/token fails because it uses the http://localhost as redirect_uri.

I've used your fix on the branch and it seems to work. Thanks :)

Thanks for the info @H4kor. I'm hoping to put a patch out next week that includes this change, it's just waiting on a couple of other PRs being finalized. If you can work with the branch for now, I'll update when this patch goes out.

These patch is not integrate in master ?

Was this page helpful?
0 / 5 - 0 ratings