Esta pregunta es sobre cómo asegurar el punto final de redirección en el lado del cliente al final de un flujo de "código de autorización".
Hemos diseñado un servidor de servicios de fondo que maneja el proceso de autorización de OAuth 2.0 con diferentes servidores de autorización: nuestra aplicación del lado del servidor es un cliente de múltiples proveedores de OAuth 2.0. Llamémoslo administrador de autorizaciones .
El proceso de autorización puede ser iniciado por varias aplicaciones (móvil, sitio, etc.), pero queremos que el administrador de autorización maneje todas las credenciales y la lógica de OAuth 2.0 (como obtener un token, etc.) . Las aplicaciones "preguntan" al administrador de autorizaciones donde redireccionar al cliente, y el administrador de autorizaciones crea una URL de solicitud de autorización con su ID de cliente, redirectURI, etc. La aplicación solo tiene que abra esa url en una nueva ventana de marco / navegador y no se preocupe por manejar el resto del proceso.
Como el administrador de autorizaciones no inicia el flujo de autorización (el navegador del usuario no lo alcanza primero), no ha autenticado al usuario, por lo que no tiene ninguna prueba de "autenticación de usuario" cuando el el usuario alcanza su redirectURI, solo el estado y el código.
¿Es necesario que nuestro punto final de redirección requiera la autenticación del usuario? ¿Deberíamos necesitar que el usuario se autentique previamente cuando se redirige a nuestro URI de redirección (como una cookie de sesión)?
Desde mi punto de vista, el código de autorización del estado + hace una superficie de ataque realmente pequeña:
- ambas son cadenas generadas aleatoriamente
- ambos tienen una vida muy corta
- uno es generado por el cliente (estado), el otro por el servidor de autorización (código). Un atacante tendría que "romper" ambos generadores
- El código de autorización es validado por el servidor de autorización al realizar una solicitud de token
- incluso si un atacante rompiera ambos, solo activaría una solicitud de token de acceso válida de back-end a back-end, pero nuestro punto final de redirección no ofrece información a cambio.