link afferma:
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.
È sicuro utilizzare un parametro "stato" che generi ( uuid/v4 ) nella richiesta di autorizzazione OAuth2 oltre alla protezione CSRF per identificare l'utente nella callback del provider nel flusso di autorizzazione? In questo modo, il flusso di oauth2 è "stateless" e non richiede "sessioni appiccicose" per il bilanciamento del carico.
Attualmente, quando un utente avvia il flusso OAuth2 (visita la pagina di accesso) creo un auth-request-id e state unici per lui e lo memorizzo in Redis e inviamo il auth-request-id nei cookie.
Dopo che l'utente accede al provider (Google o Facebook) nella richiesta di callback, cerco di trovare la sessione dell'utente dal cookie auth-request-id in Redis e di convalidare se esiste una sessione e che il state ricevuto corrisponde al uno che ho inviato (contro gli attacchi CSRF).
Mi chiedo, posso saltare la creazione del cookie auth-request-id e identificare l'utente nella callback da state ? Data la logica, se non è possibile trovare state corrispondente in Redis, presume che lo stato non sia valido e che tutti i redis memorizzati state abbia una scadenza di 5 minuti.