OpenID Connect (OIDC) es una capa de identidad que se construye sobre el protocolo OAuth 2.0 y permite a las aplicaciones autenticar usuarios sin tener que gestionar ni almacenar sus credenciales. AWS Application Load Balancer (ALB) se integra con los proveedores de identidad (IdPs) sociales más comunes, con identidades corporativas y con cualquier IdP que cumpla con OIDC. Esta integración simplifica el proceso de autenticación y refuerza la seguridad, ya que delega la gestión de las sesiones y los tokens de autenticación en un proveedor externo de confianza.
Aunque el inicio de sesión es transparente para el usuario final, detectar la causa de un problema puede volverse complicado cuando la autenticación falla por los saltos adicionales que existen entre el usuario y la aplicación a la que intenta acceder.
Este artículo busca dar visibilidad sobre cómo lucen las transacciones HTTP desde distintas perspectivas durante el flujo del código de autorización.
Si te interesa aprender a configurar la autenticación de usuarios en tu ALB, te recomiendo leer la documentación oficial de AWS. AWS también ofrece un sitio de demostración donde puedes probar la funcionalidad.
**Desglosemos el flujo de autenticación paso a paso —**
El logging es clave para mantener la salud, la seguridad y la eficiencia de las aplicaciones en la nube. Aporta la visibilidad necesaria para monitorear y diagnosticar las aplicaciones, de modo que funcionen de forma fluida y segura.
Para profundizar en el flujo de autenticación, recopilé los siguientes logs:
- Archivo HAR del navegador del usuario.
- Logs de acceso de los endpoints del IdP (Auth, Token, User-Info), del ALB y de la aplicación de destino.
Antes de revisar las transacciones HTTP, te recomiendo familiarizarte con los distintos componentes de OIDC y sus funciones.
Requisitos previos —
- El IdP está configurado para ejecutar el flujo Authorisation code grant con los scopes deseados. También se generaron un Client ID y un client secret.
- El ALB está configurado con una regla de listener que dispara la acción "authenticate" cuando la ruta HTTP coincide con
/auth*. Define los parámetros de la solicitud de autenticación: client ID, client secret, endpoint de autorización, endpoint de token y endpoint de información de usuario. El ALB usa estos parámetros para comunicarse con el IdP.
Paso 1 — El usuario envía una solicitud HTTP a tu aplicación detrás de un ALB con autenticación habilitada.
Navegador redirigido al endpoint Auth del IdP.
Logs de acceso del ALB para esa misma transacción —
h2 2024–07–11T18:47:52.382721Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302–359 657 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" arn:aws:elasticloadbalancing:eu-west-1:21112316:targetgroup/TG/1a24c5faad770fb2 "Root=1–669028d8–653487fd74af592f498329f8" "authenticate"
- La acción de autenticación se dispara cuando el usuario envía una solicitud HTTP GET al ALB.
- Si en los headers de la solicitud HTTP no hay una cookie de sesión de autenticación, el ALB devuelve una respuesta HTTP 302 y redirige al usuario a la URL indicada en el header location (el endpoint de autorización del IdP).
- El
redirect_uries la ubicación a la que se redirige al navegador una vez que el IdP otorga el código de autorización.
Paso 2 — El usuario es redirigido al endpoint de autorización del IdP.
Solicitud HTTP al endpoint auth.
- El usuario envía una solicitud HTTP al endpoint de autorización del IdP.
- El endpoint de autorización del IdP redirige al usuario al endpoint de login del IdP (
/login). - El endpoint de login se encarga de autenticar al usuario.
Paso 3 — El usuario accede al endpoint de login.
Solicitud HTTP al endpoint de login.
- El usuario envía una solicitud HTTP al endpoint de login.
- Se carga la página de login con los campos de usuario y contraseña.
Paso 4 — El usuario se autentica.
El usuario ingresa su nombre de usuario y contraseña.
- El usuario ingresa sus credenciales en la página de login del IdP.
- Tras una autenticación exitosa, se redirige al usuario nuevamente al endpoint de autorización del IdP.
Ejemplo del payload de la solicitud POST —
csrf=izvsVKMB-GxnSvAK6McnPw6uNcZVCqqWxjeU&challenge=cbcab3062ca041399178171a4078d30b&email=user%40name.com&password=complex&submit=Log+in
Paso 5 — El usuario obtiene el código de autorización del IdP.
Código de autorización otorgado.
- El endpoint de autorización del IdP redirige al usuario de regreso a la aplicación cliente con un código de autorización.
- Los valores originales del parámetro
statese conservan para mantener una relación 1:1 entre la solicitud y el callback.
Paso 6 — El usuario regresa al ALB con el código de autorización.
El usuario es redirigido a /auth con la cookie de autenticación.
Logs de acceso del ALB para esa misma transacción —
h2 2024-07-11T18:48:27.805659Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302 - 423 847 "GET https://demo.aws.doit.com:443/oauth2/idpresponse?code=ory_ac_9j6SCghDyFOexN03pTRP_GSJ5RHduhCLE-L74D2IlSs.zMsOhvXLbIrs0WQLtb43tkUnRZm0lWoI5T0IlNjnoO0&scope=openid&state=Y06EN0RLaODTpBbHGEpfK29AZJcLIpftyWwbyQN8EeiFyOtbN07H2nTXTGUa3DDYX5UgeMDsqP9psViZhPy41Y%2FVkNoJc5%2B6jb8po%2BLXQtcgxRgk9s5T0LgWt53mOEOjxL4nBVQ9Z9X1Sm%2BcZNO%2BFAIlh%2B6t99WKKj3vz1bekHiwdLWp18GUo9cp3eUkPWXbSBXprXOUHk2QlPK9xd7sG3AHyj4urRv3lc97AR4DRrVIECUMOsNP5BlYW6%2FGAg%3D%3D HTTP/2.0" "Root=1-669028fb-6e750f6c5c7fdde45853b7f6" "authenticate"
- El usuario presenta el código de autorización al ALB.
- El ALB responde con un código HTTP 302 y redirige al usuario al URI original:
https://demo.aws.doit.com/auth.html. - Antes de generar la respuesta, el ALB realiza llamadas backchannel a los siguientes endpoints:
Endpoint Token del IdP, para canjear el código por un IdToken.
Solicitud POST al endpoint Token.
Endpoint UserInfo, para canjear el access token por los claims del usuario.
Solicitud al endpoint UserInfo.
Los claims del usuario, el access token y el refresh token se codifican en base64 y se cifran dentro de la cookie AWSELBAuthSessionCookie.
Paso 7 — El usuario solicita el URI original con la cookie AWSELBAuthSessionCookie ya establecida.
El ALB autentica al usuario y la solicitud llega al backend.
Logs de acceso del ALB para esa misma transacción —
h2 2024-07-11T18:48:27.824183Z app/demo/25be909a3f190764 109.78.96.82:54871 172.31.11.119:80 0.007 0.001 0.000 200 200 596 3307 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" "arn:aws:elasticloadbalancing:eu-west-1:211125377316:targetgroup/healthyTG/1a24c5faad770fb2 "Root=1-669028fb-156c503c2fe1fcdb60e4a5ad" 2024-07-11T18:48:27.815000Z "authenticate,forward" "172.31.11.119:80" "200"
- Se cumplen las condiciones de la regla del ALB para la acción "authenticate" y, además, la cookie de autenticación está presente.
- El ALB valida la cookie y reenvía la información del usuario a los targets mediante los headers HTTP
X-AMZN-OIDC-*.
Headers X-AMZN_OIDC* vistos en el target —
Headers X-AMZN_OIDC*.
x-amzn-oidc-accesstoken- El access token proveniente del endpoint Token.
x-amzn-oidc-identity- El campo subject (sub) proveniente del endpoint UserInfo.
x-amzn-oidc-data- Los claims del usuario, en formato JSON Web Tokens (JWT).
Los claims del usuario en formato JWT incluyen un header, un payload y una firma codificados en base64 URL. El ALB usa ES256 (ECDSA con P-256 y SHA256) para generar la firma del JWT.
JWT decodificado —
El header del JWT es un objeto JSON que incluye al emisor, los detalles del firmante y el ID de la clave. El payload del JWT es un objeto JSON con los claims del usuario que llegan desde el endpoint UserInfo del IdP.
El target (Apache) autoriza correctamente al usuario a partir de los claims y devuelve una respuesta HTTP 200 OK al usuario a través del ALB.
Conclusión —
Este artículo ofrece una mirada a fondo a cómo se desarrollan las transacciones HTTP durante el flujo del código de autorización OIDC al usar AWS Application Load Balancer (ALB). Recorre cada paso, desde la solicitud HTTP inicial del usuario hasta la autenticación y autorización finales, y resalta las interacciones HTTP clave y los detalles de logging que resultan esenciales para diagnosticar problemas y entender el proceso.
Si quieres saber más o te interesan nuestros servicios, no dudes en escribirnos. Puedes contactarnos aquí.