OpenID Connect (OIDC)

OpenID Connect es una capa de identidad ligera construida sobre OAuth 2.0. OAuth responde a qué puede hacer esta aplicación; OIDC responde a quién es el usuario.

• Estandariza la forma en que los clientes autentican a los usuarios y reciben claims de identidad verificados.
• Introduce el ID token como una aserción de autenticación firmada criptográficamente.

Antes de OIDC, los desarrolladores utilizaban indebidamente los tokens de acceso de OAuth para iniciar sesión, lo que provocaba vulnerabilidades de tipo confused deputy y suplantación de identidad.

El artefacto distintivo de OIDC es el ID token, un JWT firmado que describe el evento de autenticación.

• Contiene claims sobre quién inició sesión y cuándo.
• Está destinado a que lo consuma el cliente, no el servidor de recursos.

Nunca envíe un ID token a una API como credencial de acceso ni acepte uno sin validar su firma y sus claims.

Validar un ID token implica comprobar claims específicos, no solo la firma.

• El emisor iss debe coincidir con el IdP esperado.
• La audiencia aud debe contener su client_id.
• El token exp / iat no debe haber expirado y debe haberse emitido recientemente.
• sub es un identificador de usuario estable y único.
• nonce debe coincidir con el valor enviado por su cliente.

OIDC reutiliza el flujo de código de autorización, pero añade el scope openid y un nonce.

• El cliente solicita el scope openid (además de profile y email, opcionales).
• El endpoint de tokens devuelve un ID token junto con el token de acceso.
• El nonce vincula el ID token con la solicitud original, lo que evita la reproducción.

Los proveedores de OIDC publican sus claves de firma en un endpoint JWKS, que se puede descubrir mediante el documento de configuración well-known.

• Obtenga las claves de jwks_uri y haga coincidir el encabezado kid del token.
• Verifique la firma con el algoritmo asimétrico indicado (RS256, ES256).

Rechace el algoritmo none y no confíe nunca en un valor de algoritmo proporcionado únicamente por el token.

El nonce cumple para los ID tokens la misma función que state para la redirección: es un valor de un solo uso que vincula la respuesta con la solicitud.

• El cliente genera un nonce aleatorio y lo almacena en la sesión.
• El IdP lo refleja dentro del ID token.
• Al recibirlo, el cliente verifica que el nonce coincida y que no se haya utilizado antes.

Esto bloquea la reproducción de tokens y la inyección de un token creado para una sesión diferente.

Para obtener datos de perfil adicionales a los del ID token, OIDC define el endpoint UserInfo.

• El cliente lo invoca con el token de acceso (no con el ID token).
• Devuelve claims como el nombre, el correo electrónico y la imagen del sujeto autenticado.

Compare siempre el sub devuelto con el sub del ID token para evitar la sustitución de claims.

OIDC estandariza el descubrimiento para que los clientes puedan configurar automáticamente los endpoints y las funciones compatibles.

• El documento /.well-known/openid-configuration enumera los endpoints, los scopes compatibles y los algoritmos.
• Fije o valide el emisor; no siga ciegamente el descubrimiento desde un host controlado por un atacante.

El descubrimiento simplifica la integración, pero el emisor sigue siendo un ancla de confianza que debe verificar.

La terminación de sesiones entre aplicaciones federadas se gestiona mediante las especificaciones de cierre de sesión de OIDC.

• El cierre de sesión por front-channel utiliza redirecciones o iframes del navegador para cerrar la sesión en cada parte confiante.
• El cierre de sesión por back-channel envía tokens de cierre de sesión de servidor a servidor; es más fiable, pero requiere endpoints.

Sin un cierre de sesión coordinado, un usuario puede cerrar sesión en una aplicación y seguir conectado en otras, lo que supone un riesgo real para la gestión de sesiones.

Los errores de identidad suelen deberse a que se omiten pasos de validación.

• Aceptar tokens sin comprobar aud (el token estaba destinado a otro cliente).
• Ignorar iss, lo que permite la suplantación del IdP.
• No validar la firma o aceptar alg: none.
• Confundir los ID tokens con los tokens de acceso.
• Omitir las comprobaciones de nonce, lo que permite la reproducción.

Si su objetivo es el inicio de sesión, utilice OIDC, no OAuth puro.

• Los tokens de acceso de OAuth son opacos para el cliente y no demuestran nada sobre la identidad.
• Un token de acceso puede ser válido para otro usuario o aplicación, lo que provoca suplantación si se utiliza para iniciar sesión.
• Los ID tokens de OIDC son aserciones de identidad vinculadas explícitamente a una audiencia.

Esta distinción evita el clásico fallo de autenticación de tipo confused deputy.

Conclusiones principales:

• OIDC añade una capa de identidad a OAuth 2.0; el ID token es un JWT firmado que demuestra la autenticación.
• Valide siempre iss, aud, exp, firma (mediante JWKS) y nonce.
• Los ID tokens son para el cliente; los tokens de acceso son para las API; nunca intercambie sus funciones.
• Utilice nonce frente a la reproducción y state frente a CSRF.
• Utilice OIDC, no OAuth puro, cuando necesite autenticar usuarios.