oauth-2.0oauthredirect-uri

Does OAuth 2.1 require to configure every single frontend path as a valid redirect_uri?

Probably a very generic question: Does OAuth 2.1 require configuring every single frontend path as a valid redirect_uri?

See: https://oauth.net/2.1/

Redirect URIs must be compared using exact string matching

We were wondering how this will work with flows where the access_token/refresh_token expires while the user is accessing an application.

A common flow (and one we use) is like this:

  1. User logs in and navigates through webapp. -> https://webpage.io/account/me
  2. User loses session (deletes cookies, session expires, no refresh_token etc.).
  3. User is being redirected to login page but the redirect_uri is set to wherever the user has left off. -> https://provider.io?redirect_uri=https://webpage.io/account/me

With OAuth 2.1, do we have to enable every single route the application has as a valid redirect_uri to now? It works if the redirect_uri includes a wildcard *, but how would this work with exact string matching?

Solution

  • No, there is no "wildcarding" per se.

    Either stick the URL you want the user to be eventually returned to, into your session - and then read it back from there & redirect to it, after the user has arrived at your static redirect_uri again (and you verified the success/got your access token),

    or

    put the URL into the state parameter - that is the only part of the redirect_uri that is allowed to deviate from your registered redirect URIs.

    https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10#section-2.3.1:

    The client MAY use the state request parameter to achieve per-request customization if needed rather than varying the redirect URI per request.

    The state parameter is usually used to prevent CSRF attacks - by passing a random value, that also gets stored into the user session, and comparing the two when the user arrives back at the redirect URI. If you are already using it in that way, you can for example provide a data structure encoded as JSON for the state parameter, so that you can stick the random session state, and your desired target URL, in there both. (You will have to decode that then accordingly, at the point where the CSRF check happens.)