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.