4.1.1. Authorization Request"
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
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.