¿Por qué la URL de redireccionamiento está totalmente calificada en Azure AD B2C?

azure-ad-b2c

Question

¿Por qué la URL de redireccionamiento tiene que coincidir completamente? ¿No sería suficiente la coincidencia a nivel de dominio para una seguridad adecuada?

¿Y si tuviera cientos de caminos?

ejemplo de URL:

1. https://myawesomesite.com
2. https://myawesomesite.com/account/profile
3. https://myawesomesite.com/games/fungame/points
4. https://www.myawesomesite.com/games/fungame/points

...

Tendría que ingresar las 4 URL de redireccionamiento anteriores en la configuración de mi aplicación B2C.

Answer 1

Es común (y más fácil) que todas las solicitudes de autenticación contengan dos URL de redireccionamiento:

1. Uno (a menudo conocido como la URL de respuesta ) que se pasa en el parámetro "redirect_uri", que debe registrarse con Azure AD B2C, al que se devuelven todas las respuestas de autenticación de Azure AD B2C a la aplicación del usuario de confianza. Un ejemplo de esto es https://www.myawesomesite.com/oidc-signin .
2. Otro (a menudo conocido como la URL de retorno ) que se redondea en el parámetro "estado", que no tiene que registrarse con Azure AD B2C, al que se devuelve el usuario final después de que la aplicación del usuario de confianza haya manejado la autenticación respuesta. Un ejemplo de esto es https://www.myawesomesite.com/games/fungame/points .

Un controlador de autenticación, como el middleware de autenticación ASP.NET Core , administra estas URL de redireccionamiento por usted.

Por ejemplo, cuando el controlador de autenticación crea la solicitud de autenticación, codifica la URL actualmente protegida (por ejemplo, https://www.myawesomesite.com/games/fungame/points ) en el parámetro de solicitud "estado".

Para garantizar que esta URL no se altere, el parámetro "estado" debe protegerse mediante cifrado o firma.

Cuando el controlador de autenticación procesa la respuesta de autenticación, suponiendo que sea una respuesta exitosa, crea una cookie de identidad y redirige al usuario final desde https://www.myawesomesite.com/oidc-signin a la URL originalmente protegida en el "estado" parámetro de respuesta

Answer 2

Esto se trata realmente en RFC 6819 "Modelo de amenaza OAuth 2.0 y consideraciones de seguridad" secciones 4.1.5 , 4.2.4 y 5.2.3.5 .

4.1.5. Amenaza: Redirectores abiertos en el cliente

Un redirector abierto es un punto final que utiliza un parámetro para redirigir automáticamente un agente de usuario a la ubicación especificada por el valor del parámetro sin ninguna validación. Si el servidor de autorización permite que el cliente registre solo una parte del URI de redireccionamiento, un atacante puede utilizar un redirector abierto operado por el cliente para construir un URI de redireccionamiento que pasará la validación del servidor de autorización pero enviará el "código" de autorización o el token de acceso a un punto final bajo el control del atacante.

Impacto: un atacante podría obtener acceso a "códigos" de autorización o tokens de acceso.

Contramedidas:

o Requerir que los clientes registren el URI de redireccionamiento completo ( 5.2.3.5 ) ".

5.2.3.5 habla sobre los casos en que esto puede ser demasiado restrictivo y los propósitos de soluciones alternativas.

Muchas veces, el parámetro de state también se puede utilizar para redirigir determinísticamente como lo sugiere Chris. Sin embargo, debe asegurarse de que dicha solución tampoco termine siendo un redirector abierto, por lo que el parámetro de state deberá protegerse (por ejemplo, encriptarse / firmarse) o utilizarse junto con cookies.