OpenID Connect: cómo OIDC convirtió OAuth 2.0 en un protocolo de identidad
Análisis del diseño de OpenID Connect, la capa de identidad que completa a OAuth 2.0, sus garantías criptográficas y los errores de integración que aparecen con mayor frecuencia.
OAuth 2.0 resolvió la delegación de acceso y, como efecto colateral, durante años se usó también como sucedáneo de autenticación, con resultados predecibles. OpenID Connect es la respuesta estandarizada a ese vacío: una capa de identidad bien definida sobre OAuth 2.0, con semántica criptográfica específica para responder “quién es este usuario”. Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
Por qué hizo falta una capa nueva
El argumento aparece con detalle en el artículo dedicado a OAuth 2.0, pero conviene recordarlo. Un access token de OAuth 2.0 es una prueba de autorización, no de identidad. Poseerlo significa “alguien autorizó al cliente a acceder a este recurso”; no significa que el portador sea una persona concreta ni que esa persona se haya autenticado recientemente. Extraer un sub del endpoint /me para decidir quién inicia sesión en una aplicación abre la puerta a ataques de sustitución: un token válido para otra aplicación, inyectado como si fuera propio.
OpenID Connect Core 1.0 se publicó en febrero de 2014 por la OpenID Foundation. Su propuesta es añadir un ID Token con formato JWT, audiencia explícita y semántica de autenticación, un conjunto de endpoints y scopes estandarizados, y un mecanismo de descubrimiento que permite a los clientes autoconfigurarse contra cualquier proveedor compatible. El resultado es un protocolo de identidad federado que, al apoyarse en OAuth 2.0, se integra con naturalidad en la infraestructura ya desplegada para autorización.
Dos tokens, dos significados
La distinción entre access token e ID token es la piedra angular de OIDC y el origen de la mayoría de errores.
El access token es lo que el cliente envía al Resource Server para operar sobre recursos. Su audiencia es la API. Puede ser opaco o un JWT. El cliente no lo inspecciona; lo transporta.
El ID token es un JWT que el Authorization Server entrega al cliente junto al access token cuando el scope openid está presente. Su audiencia es el propio cliente. Contiene claims de identidad (sub, iss, aud, exp, iat, auth_time, nonce, opcionalmente email, name, etc.) y debe ser validado criptográficamente por el cliente antes de confiar en su contenido. Es la prueba de que el usuario se autenticó ante el IdP.
El scope openid funciona como interruptor: su presencia convierte una petición OAuth 2.0 estándar en una petición OIDC y obliga al Authorization Server a emitir también un ID token. Omitirlo es pedir un flujo OAuth 2.0 puro sin identidad.
Descubrimiento, JWKS y UserInfo
Tres endpoints estructuran el protocolo.
El documento de descubrimiento
Publicado en /.well-known/openid-configuration, es un JSON que expone las URLs y capacidades del proveedor: authorization endpoint, token endpoint, userinfo endpoint, jwks_uri, algoritmos soportados, scopes, claims, response types, grant types. Un cliente bien escrito consume este documento al arrancar y se adapta sin hardcodear URLs. Rotar o migrar un IdP se vuelve tratable cuando toda la configuración nace aquí.
JWKS
El endpoint jwks_uri devuelve el conjunto de claves públicas con las que el IdP firma ID tokens (y, si son JWT, access tokens). El cliente cachea el JWKS respetando los headers de cache, selecciona la clave por kid y valida la firma. La rotación es transparente: el IdP publica la clave nueva antes de empezar a usarla y retira la vieja tras un margen prudente.
UserInfo
El endpoint userinfo acepta el access token y devuelve claims adicionales sobre el usuario autenticado. No todos los claims necesarios tienen que viajar en el ID token; de hecho, conviene que no lo hagan por tamaño. La regla operativa es: claims imprescindibles para decisiones inmediatas en el cliente, en el ID token; el resto, en UserInfo bajo demanda.
Flujos y cuál elegir
OIDC reutiliza los grant types de OAuth 2.0 y añade la variante hybrid. El parámetro response_type determina la combinación.
code es el flujo Authorization Code clásico, con intercambio back-channel. El cliente recibe un code, lo canjea en el token endpoint por access token, refresh token e ID token. Es el flujo canónico moderno para aplicaciones web, SPAs y móviles, siempre acompañado de PKCE.
id_token (implicit) entrega el ID token directamente en el redirect. Sirvió para SPAs antes de que PKCE estuviera universalmente soportado; hoy se desaconseja.
code id_token (hybrid) combina ambos: el ID token llega por el frontal y el access token por el trasero. Permite al cliente validar la identidad antes de completar el intercambio. Tiene nichos específicos, sobre todo en entornos federados con requisitos regulatorios, pero rara vez es la elección por defecto.
La recomendación actual, reforzada por OAuth 2.1 y las BCP de seguridad, es Authorization Code con PKCE para todo tipo de cliente.
El parámetro nonce y la prevención de replay
OIDC introduce un parámetro específico frente a OAuth 2.0: nonce. El cliente genera un valor aleatorio, lo envía en la petición de autorización y lo vincula al estado de sesión. El IdP incluye ese mismo valor como claim nonce en el ID token. Cuando el cliente recibe el token, verifica que el nonce coincide con el generado en la sesión actual.
La defensa es contra replay: un atacante que capture un ID token no puede reutilizarlo en otra sesión, porque el nonce no coincidirá. Junto al state (prevención de CSRF heredada de OAuth 2.0), ambos parámetros son no negociables en cualquier integración seria.
Validación del ID token
La validación es el punto donde más implementaciones fallan. Un ID token se considera válido únicamente si pasa todas estas comprobaciones.
La firma debe verificarse contra la clave pública del IdP, obtenida del JWKS y seleccionada por kid. El algoritmo debe estar en la lista blanca declarada por el cliente, nunca decidido por el propio token.
El issuer (iss) debe coincidir exactamente con el esperado para el IdP configurado. La audiencia (aud) debe contener el client_id del cliente; si hay múltiples audiencias, el claim azp indica el autorizado. La expiración (exp) debe ser futura, permitiendo un margen pequeño de clock skew. El iat debe ser razonable. El nonce debe coincidir con el enviado.
Saltarse cualquiera de estos pasos invalida las garantías del protocolo. Librerías maduras las hacen por defecto; implementaciones artesanales rara vez lo hacen bien.
Un patrón que aparece en auditorías: el cliente valida firma y
exp, pero noaudniiss. Un atacante con acceso a otra aplicación del mismo IdP puede usar sus ID tokens para autenticarse en la víctima.audno es opcional.
Claims agregados y distribuidos
En despliegues federados, no todos los claims del usuario viven en el IdP principal. OIDC define dos mecanismos: claims agregados, donde el IdP incluye los claims de terceros firmados por su emisor original dentro del ID token, y claims distribuidos, donde el IdP incluye referencias a endpoints externos desde los que el cliente recupera los claims con un access token específico. Son funciones avanzadas, poco usadas, pero útiles cuando la identidad de un usuario se compone de atributos mantenidos por autoridades distintas.
Gestión de sesión y logout
OIDC define especificaciones complementarias para el cierre de sesión. RP-Initiated Logout permite al cliente redirigir al usuario al endpoint de logout del IdP. Front-Channel Logout usa un iframe que carga una URL de logout en cada cliente cuando la sesión del IdP termina. Back-Channel Logout envía tokens de logout firmados directamente a los clientes por canal trasero, más fiable que el front-channel en navegadores modernos con restricciones de cookies de terceros.
La elección depende del perfil de despliegue. Para SSO clásico web, back-channel es la opción robusta. Para aplicaciones móviles, la revocación del refresh token en el IdP suele ser el punto de control efectivo.
OIDC en el ecosistema
Los IdPs comerciales y open source (ver Keycloak, Okta y el papel del IdP) soportan OIDC como protocolo de primera clase. La OpenID Foundation certifica implementaciones, y esa certificación es una señal fuerte a considerar en decisiones de compra. OIDC Federation (RFC 9678, octubre de 2024) formaliza la federación entre múltiples IdPs con cadenas de confianza explícitas, pensada para escenarios académicos y gubernamentales donde no basta con acuerdos bilaterales.
Cuándo elegir OIDC
La respuesta corta es: siempre que el problema sea autenticación de usuarios y exista un IdP compatible. Intentar construir autenticación sobre OAuth 2.0 puro es reinventar OIDC con menos garantías. Para flujos puramente máquina a máquina sin identidad de usuario, OAuth 2.0 con Client Credentials basta; OIDC no aporta ahí.
En arquitecturas con múltiples aplicaciones, SSO entre dominios y requisitos de federación con terceros, OIDC es la base sobre la que descansa todo lo demás. La inversión inicial en entender validación de tokens y gestión de descubrimiento se amortiza en cada nueva integración.
Artículos relacionados en esta serie
Referencias
- OpenID Connect Core 1.0 (febrero 2014). OpenID Foundation.
- OpenID Connect Discovery 1.0. OpenID Foundation.
- OpenID Connect Dynamic Client Registration 1.0. OpenID Foundation.
- OpenID Connect Session Management 1.0. OpenID Foundation.
- OpenID Connect Front-Channel Logout 1.0 / Back-Channel Logout 1.0.
- RFC 7519 (mayo 2015). JSON Web Token (JWT).
- RFC 8414 (junio 2018). OAuth 2.0 Authorization Server Metadata.
- RFC 9678 (octubre 2024). OpenID Federation 1.0.