enlace declara:
4.1.1. Solicitud de Autorización "
"estado"
RECOMENDADO. Un valor opaco usado por el cliente para mantener Estado entre la solicitud y devolución de llamada. La autorizacion El servidor incluye este valor al redireccionar al agente de usuario. al cliente. El parámetro DEBERÍA ser usado para prevenir falsificación de solicitudes en sitios cruzados como se describe en la Sección 10.12.
¿Es seguro usar un parámetro de "estado" que genero ( uuid/v4 ) en la solicitud de autorización OAuth2 además de la protección CSRF para identificar al usuario en la devolución de llamada del proveedor en el flujo de autorización? Por lo tanto, hacer que el flujo de auth2 sea "sin estado" y no requiera "sesiones pegajosas" para el equilibrador de carga.
Actualmente, cuando un usuario inicia el flujo de OAuth2 (visita la página de inicio de sesión), creo un único auth-request-id y state para él, lo almaceno en Redis y envío el auth-request-id en las cookies.
Después de que el usuario inicie sesión en el proveedor (Google o Facebook) en la solicitud de devolución de llamada, trato de encontrar la sesión del usuario en la cookie auth-request-id en Redis y validar si existe una sesión y que el state recibido coincide con la uno que envié (contra ataques CSRF).
Preguntándome: ¿puedo omitir la creación de la cookie auth-request-id e identificar al usuario en la devolución de llamada mediante el state ? Dada la lógica, si no se puede encontrar state coincidente en Redis, suponga que el estado no es válido y que todos los Redis almacenados state tienen un tiempo de caducidad de 5 minutos.