This question is about securing the redirect endpoint on the client side at the end of an "authorization code" flow.

We have designed a back-end server that handles the OAuth 2.0 authorization process with different authorization servers : our server side application is a client of multiple OAuth 2.0 providers. Let's call it an authorization manager.

The authorization process can be initiated by various apps (mobile, site, etc), but we want the authorization manager to handle all the OAuth 2.0 credentials and logic (like obtaining a token, etc). The applications "ask" the authorization manager where to redirect the client, and the authorization manager creates an authorization request URL with its clientId, redirectURI, etc. The application just has to open that url in a new frame/browser window and not worry about handling the rest of the process.

Because the authorization manager does not initiate the authorization flow (the user browser does not reach it first), it has not authenticated the user, so it has no proof of "user authentication" when the user reaches its redirectURI, only the state and code.

Is it necessary for our redirect endpoint to require user authentication ? Should we need the user to be pre-authenticated when he is redirected to our redirect URI (like a session cookie) ?

From my point of view, the state + authorization code make a reallly small attack surface :

  • both are random generated strings
  • both are very short lived
  • one is generated by the client (state), the other by the authorization server (code). An attacker would need to "crack" both generators
  • The authorization code is validated by the authorization server when making a token request
  • even if an attacker cracked both, it would only trigger a valid access token request from back-end to back-end, but our redirect endpoint offers no information in return.
  • Late to the game: I'm a bit more concerned about the route your application uses to "ask" the authorization manager where to redirect the client. How do you establish trust between the application and the authorization manager? – neverendingqs Oct 17 '16 at 20:17
  • It's a secure internal HTTP call between two web apps : private network, https, authentication. – Michael Técourt Oct 20 '16 at 10:25
  • Note I wouldn't have chosen that design. I was trying to figure out how much security is required at the end of the OAuth 2.0 authorization process, given that the callback provides two short-lived random strings generated by different parties. – Michael Técourt Oct 20 '16 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.