Parámetro de estado en el flujo de código OAuth2.0 en el lado del servidor.
Tengo un escenario en el que necesito implementar el flujo de autorización de código de OAuth 2.0 en el lado del servidor: el usuario autoriza un servicio de backend contra Microsoft, el servicio recibe un token, lo guarda en una base de datos y lo utiliza para realizar trabajos diarios en segundo plano sobre los datos del usuario. El token en sí no es necesario ni se recibe en la aplicación frontal.
El servicio de backend es una aplicación asp.net 5 con una API y un servicio alojado. La aplicación frontal solo realiza la solicitud inicial a la API, lo que resulta en una redirección a Microsoft. La URL de devolución de llamada de oauth está dirigida al punto final de la API que recibe el código, obtiene un token y redirige a la aplicación frontal en caso de éxito/fallo.
La pregunta es, ¿cómo implementar el parámetro de estado contra ataques CSRF en este escenario? Por ejemplo, para evitar que alguien publique el código de otra persona en el punto final de devolución de llamada. En el flujo de código habitual, la aplicación frontal generaría un parámetro de estado y lo almacenaría en el almacenamiento local (descrito aquí) y lo compararía en la redirección al regresar a la aplicación frontal.
En mi caso, es la API la que necesita generar un parámetro de estado, guardarlo y comprobarlo en la URL de devolución de llamada. No tengo una sesión de usuario y la API está equilibrada en carga, por lo que necesito un almacenamiento externo, pero la solución debería ser similar. Mi plan era:
- En el punto final que redirige al inicio de sesión de
oauth2, generar unguidque actúe como el estado, - Almacenarlo en una
DistributedCachecomo clave con el valor de algunos datos adicionales del usuario (id, nombre, etc.) que recibe el punto final, - Pasar el guid en el parámetro de consulta de estado (
?state=asd123) a la URL de redirección, - En el punto final de devolución de llamada, recuperar el estado y comprobar si existe esa clave en la memoria caché,
- Si existe, la solicitud es válida y puedo utilizar los datos adicionales asociados a la clave.
Todos los tutoriales que pude encontrar tratan sobre la aplicación frontal y el almacenamiento local, por lo que mi idea parece un parche y no me gustaría correr riesgos en cuanto a seguridad al implementar algoritmos aleatorios. ¿Es necesario pasar esos datos adicionales del usuario en el estado o es suficiente confiar en que estarán presentes en la memoria caché si la solicitud es válida? ¿Existe una manera más estándar y segura de hacer esto?
Aquí tienes un diagrama de secuencia del flujo de inicio de sesión descrito, por si es útil:
davy.ai
Implementar un parámetro de estado es un paso crucial para prevenir ataques CSRF en el flujo de código de autorización OAuth 2.0. En el escenario descrito, donde el servicio backend necesita generar y almacenar el parámetro de estado sin acceso a una sesión de usuario, una DistributedCache es una solución viable.
Tu plan de generar un
guidcomo estado y almacenarlo en la DistributedCache es un buen comienzo. Sin embargo, dado que el estado es un valor aleatorio, es esencial adjuntar datos de usuario, como el ID o nombre del usuario, al estado para asegurarse de que la sesión del usuario esté vinculada al valor del estado. Pasar los datos adicionales de usuario en el parámetro de consulta del estado también es un enfoque válido.En el punto final de devolución de llamada, recupera el estado del parámetro de consulta y verifica si existe una clave en la DistributedCache con ese valor de estado. Si la clave existe, la solicitud es válida y se pueden utilizar los datos adicionales de usuario adjuntos a la clave.
Almacenar los datos de usuario en la caché es esencial para prevenir ataques CSRF, pero no es necesario depender de que estén presentes en la caché si la solicitud es válida. En su lugar, el servicio backend puede utilizar los datos adicionales de usuario adjuntos a la clave para cualquier otro procesamiento.
En general, tu plan es una forma segura de implementar el parámetro de estado en este escenario. Es esencial seguir las mejores prácticas y pautas enumeradas en la especificación de OAuth 2.0 para garantizar la máxima seguridad.