OpenID Connect (OIDC)

OIDC reutiliza el flujo de código de autorización de OAuth y añade tres cosas. Un scope openid que pide identidad. Un ID token, un JWT firmado que contiene afirmaciones como el identificador del sujeto, el emisor, la audiencia, el momento de la autenticación y un nonce. Y un documento de descubrimiento en una ruta conocida que publica los endpoints y las claves de firma del emisor, para que un cliente pueda validar tokens sin configuración manual. Es el protocolo que hay detrás de la mayoría de las integraciones modernas de single sign-on.

La validación es todo el modelo de seguridad y es una lista de comprobación, no una preferencia: verificar la firma contra las claves publicadas, confirmar que el emisor es el que esperas, confirmar que la audiencia es tu identificador de cliente, confirmar que el token no ha caducado, y confirmar que el nonce coincide con el que mandaste. Un token que falle cualquiera de estas no es una afirmación de identidad.

La audiencia se salta. Una aplicación que valida la firma y el emisor pero no la audiencia aceptará un token que ese mismo emisor acuñó para una aplicación completamente distinta, lo que significa que cualquier otro cliente de ese proveedor de identidad puede iniciar sesión como cualquier usuario. En una plataforma de identidad grande con muchas aplicaciones registradas, ese es un camino real y alcanzable.

El segundo es usar el access token donde corresponde el ID token. Un access token es opaco para el cliente por diseño y está pensado para el servidor de recursos; tratar su contenido como identidad es el mismo error de categoría que usar OAuth para autenticar, un nivel más abajo.

El tercero es fiarse de una afirmación mutable como clave de la cuenta. Enlazar cuentas por dirección de correo en vez de por el identificador inmutable del sujeto significa que cualquiera que pueda cambiar o reclamar una dirección de correo en el proveedor puede quedarse con la cuenta local correspondiente, y los proveedores que permiten direcciones sin verificar lo vuelven trivial. El cuarto es aceptar un token cuyo emisor se lee del propio token, que es validación solo de nombre.

Probamos la validación, no el flujo: presentamos un token bien formado de otra audiencia, uno con un emisor inesperado, uno con el algoritmo de firma modificado y uno caducado, y registramos cuáles acepta la aplicación. El hallazgo nombra la comprobación que faltaba y enseña la sesión obtenida con ella. Revisamos además cómo se enlazan las cuentas y si el proveedor verifica las afirmaciones que se usan para enlazarlas. Esto forma parte de cómo probamos la autenticación federada en una API.