https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 states:
4.1.1. Authorization Request"
"state"
RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
Is it safe to use a "state" parameter I generate (uuid/v4
) in OAuth2 authorization request besides CSRF protection to identify the user in the provider callback in the authorization flow? Thus making the oauth2 flow "stateless" and don't require "sticky-sessions" for the load-balancer.
Currently, when a user starts the OAuth2 flow (visits login page) I create a unique auth-request-id
and state
for him and store it in Redis and send the auth-request-id
in the cookies.
After the user logins into the provider (Google or Facebook) in the callback request, I try to find the user's session from the auth-request-id
cookie in Redis and validate whether a session exists and that the received state
matches the one I sent (against CSRF attacks).
Wondering, can I skip creating the auth-request-id
cookie and identify the user in the callback by the state
? Given the logic, if no matching state
can be found in Redis, presume the state to be invalid and all Redis stored state
has a 5 min expiry time.