OIDC (OpenID Connect)

Definition

Este es el problema que OAuth 2.0 no resuelve: le dice a una app qué tienes permitido hacer, pero no quién eres. Si le das permiso a un sitio web para leer tus archivos de Google Drive, OAuth maneja eso - pero el sitio web todavía no sabe tu nombre, email, ni nada sobre ti. Tendrían que hacer llamadas API extra para obtener eso, y cada proveedor lo hace diferente. OpenID Connect (OIDC) arregla esto añadiendo una capa de identidad estandarizada encima de OAuth.

Cuando haces clic en “Iniciar sesión con Google,” estás usando OIDC, no solo OAuth. La magia está en el ID token - un JWT especial que contiene información verificada sobre ti: tu identificador único, email, nombre, foto de perfil, y cuándo te autenticaste. A diferencia de los access tokens (que son para acceder a APIs), los ID tokens son específicamente para probar identidad. La app no necesita llamar a la API de Google para saber quién eres; tu información de identidad llega junto con los tokens.

OIDC también estandariza el descubrimiento. En lugar de que cada proveedor tenga diferentes endpoints y formatos, los proveedores OIDC publican un documento .well-known/openid-configuration que le dice a tu app exactamente dónde encontrar todo. “Aquí está mi endpoint de autorización, aquí está mi endpoint de token, aquí es donde obtener mis claves de firma.” Esto significa que tu código puede funcionar con Google, Microsoft, Okta, o cualquier proveedor OIDC sin cambios. Es por eso que los botones de “Iniciar sesión con…” están en todas partes - OIDC hizo la identidad interoperable de una forma que nunca existió antes.

Example

OIDC es el estándar invisible que potencia la identidad en toda la web moderna:

Botones de Login Social: Cuando haces clic en “Iniciar sesión con Google,” “Acceder con Microsoft,” o “Continuar con Apple,” estás usando OIDC. La app no almacena tu contraseña - confía en Google/Microsoft/Apple para verificar tu identidad y proporcionar claims estandarizados en un ID token. Es por esto que ves estos botones en millones de sitios; todos hablan el mismo idioma OIDC.

Single Sign-On Empresarial: Cuando inicias sesión en tu portátil corporativo y de repente tienes acceso a Slack, Salesforce, y cientos de apps internas sin volver a iniciar sesión, eso es OIDC federando tu identidad desde tu directorio corporativo (Azure AD, Okta) a cada aplicación. A los administradores de IT les encanta esto porque hay un solo lugar para deshabilitar el acceso cuando alguien se va.

Autenticación en Apps Móviles: Cuando una app bancaria te permite “iniciar sesión con tu ID bancario,” está usando OIDC para obtener información de identidad verificada. La app recibe un ID token probando que eres el titular de la cuenta, incluyendo qué métodos de autenticación usaste (contraseña, huella digital, reconocimiento facial) - importante para operaciones sensibles de seguridad.

Plataformas de Desarrolladores: Cuando inicias sesión en GitHub con tu cuenta corporativa, o en AWS con el proveedor de identidad de tu organización, OIDC está conectando esos mundos. Tu identidad corporativa funciona a través de diferentes plataformas sin que cada una necesite almacenar tus credenciales.

Apps de Consumo: Apps como Spotify usando “Acceder con Facebook” se benefician de los claims estandarizados de OIDC. Inmediatamente saben tu nombre, email, y foto de perfil - suficiente para personalizar tu experiencia desde el primer segundo, sin pedirte que llenes un formulario de registro.

Analogía

El Sistema Universal de Pasaportes: Imagina si cada país tuviera su propio formato de pasaporte - algunos con fotos, algunos sin, algunos con huellas dactilares, algunos solo con un nombre. Los viajes internacionales serían un caos. OIDC es como el estándar internacional para pasaportes: cada “país” (proveedor de identidad) emite credenciales en el mismo formato, y cada “agente de frontera” (aplicación) sabe exactamente cómo leerlas. Presentas un pasaporte en todas partes.

El Sistema de Tarjeta Llave del Hotel: Cuando haces check-in en un hotel, pruebas tu identidad una vez en recepción (autenticación), y te dan una tarjeta llave (ID token). Esa tarjeta contiene información codificada sobre ti - tu número de habitación, fecha de check-out, acceso al gimnasio. No vuelves a probar tu identidad en cada puerta; solo presentas la tarjeta. OIDC funciona igual: autentícate una vez con Google, obtén un ID token, y úsalo para probar quién eres a múltiples aplicaciones.

La Credencial de Empleado: Tu credencial de empresa tiene tu foto, nombre, y departamento - eso es como un ID token. Prueba quién eres a los guardias de seguridad (partes confiantes). La credencial fue emitida por RRHH (el proveedor de identidad) quien verificó tu identidad cuando fuiste contratado. No necesitas que RRHH camine contigo a todas partes; la credencial lleva tu identidad verificada.

El Documento Notarizado: Cuando notarizas un documento, un tercero de confianza (notario/proveedor de identidad) lo sella para verificar que realmente es tuyo. Cualquiera que reciba ese documento puede confiar en su autenticidad sin llamarte directamente. Los ID tokens de OIDC funcionan similarmente - están firmados criptográficamente por el proveedor de identidad, así que las apps pueden confiar en los claims sin preguntarle al proveedor “¿es este realmente el usuario X?”

Diagrama

sequenceDiagram
    participant User as Usuario
    participant App as Aplicación Cliente
    participant Auth as Proveedor OIDC
    participant UserInfo as Endpoint UserInfo

    User->>App: 1. Clic "Iniciar sesión con Proveedor"
    App->>Auth: 2. Petición de autorización
(scope: openid email profile)
    Auth->>User: 3. Login + consentimiento
    User->>Auth: 4. Aprobar
    Auth->>App: 5. Código de autorización
    App->>Auth: 6. Intercambiar código por tokens

    Auth->>App: 7. Respuesta incluye:
- access_token
- refresh_token
- id_token (JWT)

    Note over App: ID Token contiene claims de identidad

    rect rgb(200, 230, 255)
        App->>App: 8. Validar y decodificar ID token
        Note over App: Claims en ID token:
sub: "user123"
email: "[email protected]"
name: "Juan Pérez"
picture: "https://..."
iat, exp, iss, aud, nonce
    end

    opt Información adicional del usuario necesaria
        App->>UserInfo: 9. GET /userinfo
(Bearer access_token)
        UserInfo->>App: 10. Claims extendidos del usuario
    end

Code Example

// Flujo de Autenticación OIDC
const { Issuer, generators } = require('openid-client');

// Descubrir configuración del proveedor OIDC
const issuer = await Issuer.discover('https://oauth.provider.com');

const client = new issuer.Client({
  client_id: 'your_client_id',
  client_secret: 'your_client_secret',
  redirect_uris: ['https://yourapp.com/callback'],
  response_types: ['code']
});

// Generar PKCE y nonce
const code_verifier = generators.codeVerifier();
const code_challenge = generators.codeChallenge(code_verifier);
const nonce = generators.nonce();

// Construir URL de autorización
const authUrl = client.authorizationUrl({
  scope: 'openid email profile',
  code_challenge,
  code_challenge_method: 'S256',
  nonce
});

// Manejar callback
const params = client.callbackParams(req);
const tokenSet = await client.callback(
  'https://yourapp.com/callback',
  params,
  { code_verifier, nonce }
);

// TokenSet contiene tanto access_token como id_token
const { id_token, access_token, refresh_token } = tokenSet;

// Verificar y decodificar ID token (ocurre automáticamente arriba)
const claims = tokenSet.claims();
console.log('Identidad del usuario:', {
  sub: claims.sub,        // ID del Usuario
  email: claims.email,
  name: claims.name,
  picture: claims.picture
});

// Opcionalmente obtener información adicional del usuario
const userinfo = await client.userinfo(access_token);

Notas de Seguridad

Estándares y RFCs