OpenID Connect es la capa de autenticación que se monta sobre OAuth 2.0 para verificar la identidad de los usuarios. Si ya entendiste cómo funciona OAuth, vas a captar este protocolo casi sin esfuerzo, porque reutiliza los mismos flujos y agrega piezas muy concretas. Esta lectura te sirve si construyes aplicaciones que necesitan login federado con proveedores como GitHub, Google o Auth0.

¿Qué es OpenID Connect y en qué se diferencia de OAuth 2.0?

Piénsalo como un pastel en capas. La base es HTTPS, porque todas las peticiones deben viajar sobre una transacción segura. Encima va OAuth 2.0, que se encarga de la autorización, es decir, de entregar access tokens para acceder a recursos de una API. Y arriba de todo se apoya OpenID Connect, una capa pequeña que añade autenticación, o sea, la acción de verificar quién es el usuario.

La diferencia conceptual es directa: OAuth 2.0 autoriza, OpenID Connect autentica. Por eso, cuando una aplicación necesita saber quién entró (no solo qué puede hacer), entra en juego este protocolo.

¿OpenID Connect reemplaza a OAuth 2.0? No. Es una capa que funciona encima de OAuth 2.0. Reutiliza sus flujos y añade un id token y un endpoint de información del usuario.

¿Cómo funciona el flujo de OpenID Connect con un ejemplo?

Imagina un login con GitHub. El cliente arranca con un authorization request enviando su client id y la URL de redirección, igual que en cualquier flujo de OAuth. La diferencia está en los scopes.

Para activar OpenID Connect, el scope clave es openid. Ese es el que hace de disparador del protocolo. Junto a él suelen viajar profile y email, que también pertenecen a OpenID Connect, y puedes sumar otros scopes si necesitas que el access token acceda a endpoints de tu API.

El recorrido típico es así:

1. El usuario llega a la pantalla de sign in si no tiene sesión activa.
2. Si ya tiene sesión, salta directo al consent request para autorizar al cliente.
3. Tras aceptar, se genera un authorization grant, que en authorization code flow es un código.
4. La aplicación intercambia ese código por tokens, autenticándose con su client id (y client secret si es un cliente seguro).
5. La respuesta incluye dos tokens: un access token y un id token.

¿Qué es el id token y por qué es un JWT?

El id token es la pieza nueva que aporta OpenID Connect. A diferencia del access token, que puede ser un JSON Web Token o un token opaco (una cadena aleatoria sin estructura interna), el id token siempre tiene que ser un JSON Web Token.

¿Por qué la exigencia? Porque un JWT se puede decodificar para leer la información del usuario que pediste en los scopes. Con esto, tu cliente puede, por ejemplo, saludar al usuario con su nombre propio sin hacer otra llamada al servidor.

¿Cuál es la diferencia entre id token y access token? El id token contiene información de identidad del usuario y siempre es un JWT decodificable. El access token sirve para acceder a recursos protegidos de la API y puede ser JWT u opaco.

¿Para qué sirve el endpoint user info?

Cuando necesitas datos del usuario más allá de lo que viene en el id token, OpenID Connect define un endpoint obligatorio llamado user info. Lo implementa el authorization server.

Le envías el access token con los scopes adecuados y te devuelve información ampliada, como el correo electrónico o detalles de perfil. Así puedes construir, por ejemplo, una pantalla de profile completa sin meter datos sensibles dentro del propio token.

¿Qué flujos puedes usar con OpenID Connect?

Técnicamente, cualquier flujo de OAuth 2.0 puede usarse con OpenID Connect. Pero no todos son igual de recomendables. En la práctica, estos son los más usados:

• Authorization Code Flow: la opción más sólida para aplicaciones con backend.
• Authorization Code Flow con PKCE (Proof Key for Code Exchange): ideal para clientes públicos como apps móviles o SPAs.
• Implicit Flow con Form Post: existe, pero es complicado de implementar y se usa menos.
• Hybrid Flow: tiene casos de uso bastante escasos en la práctica.

Si tienes que elegir, los dos primeros cubren la inmensa mayoría de escenarios reales.

¿Qué piezas nuevas aporta OpenID Connect frente a OAuth?

Resumiendo lo que cambia respecto a OAuth puro:

• Añade el scope openid como disparador del protocolo.
• Devuelve un id token en formato JWT junto al access token.
• Define el endpoint user info para consultar datos ampliados del usuario.
• Mantiene los mismos flujos que ya conoces de OAuth 2.0.

Y ahora te toca a ti. ¿Por qué crees que es necesario usar OpenID Connect para autenticación en lugar de intentar resolverlo solo con OAuth 2.0? Déjalo en los comentarios y nos leemos en la próxima clase, donde implementaremos Implicit Flow with Form Post en Auth0.