OpenID Connect (OIDC): El Protocolo que Simplificó el Inicio de Sesión Único (SSO)

¿Por qué necesitas conocer OIDC?

¿Alguna vez has hecho clic en “Iniciar sesión con Google” o “Entrar con Microsoft” en una aplicación nueva? Si la respuesta es sí, ya has utilizado OpenID Connect (OIDC).

Durante años, cada aplicación exigía crear una cuenta y una contraseña propias. Esto resultaba ineficiente, difícil de administrar y, sobre todo, inseguro. OIDC surge para resolver este problema, es un protocolo estándar que permite a una aplicación delegar la verificación de identidad en un tercero de confianza (como Google o el sistema corporativo de tu empresa).

Es importante aclarar un punto clave desde el inicio:

"OIDC no es un sistema de almacenamiento de usuarios."

Es el lenguaje que utilizan dos sistemas para transferir identidad de forma segura.

Una buena analogía es la de un pasaporte digital estandarizado, un verificador de confianza valida quién eres y emite un documento que otros sistemas aceptan inmediatamente.

Las bases de OIDC: de OAuth 2.0 a la identidad

Para entender OIDC, primero hay que comprender su origen.

OAuth 2.0: Autorización (no identidad)

OIDC se construye sobre OAuth 2.0, un framework diseñado para autorización, no para autenticación.

Ejemplo práctico: Cuando una aplicación solicita permiso para “acceder a tu lista de contactos de Google”, eso es OAuth. Le estás concediendo acceso a un recurso específico, pero la aplicación no sabe realmente quién eres, solo sabe que tiene permiso para acceder a esos datos.

En resumen:

• OAuth 2.0 responde a la pregunta:
  • “¿A qué puede acceder esta aplicación?”

OpenID Connect: Autenticación (quién eres)

OIDC añade la capa que faltaba, la autenticación. Es decir, responder de forma estándar y verificable a la pregunta:

• “¿Quién es el usuario?”

Para lograrlo, OIDC define un token específico llamado ID Token, que actúa como el pasaporte digital del usuario.

Componentes principales del Protocolo OIDC

En cualquier flujo OIDC intervienen tres componentes fundamentales:

Usuario (Resource Owner)

Es la persona que intenta acceder a una aplicación o servicio.

Aplicación o Cliente (Relying Party)

Es el sistema que quiere autenticar al usuario (por ejemplo, una aplicación web, un panel de administración o un servicio SaaS). Se denomina Relying Party porque confía en la identidad que le proporciona un tercero.

Proveedor de Identidad (IdP)

Es el tercero de confianza que almacena y verifica la identidad del usuario. Es el único componente que conoce la contraseña.

Ejemplos comunes:

• Microsoft Entra ID (Azure AD)
• Google (Workspace / Cloud Identity)
• Okta, Auth0
• Keycloak (open source)

El flujo de autenticación OIDC: el Pasaporte Digital en Acción

El inicio de sesión con OIDC se basa normalmente en el Authorization Code Flow, un proceso rápido pero muy bien definido:

Paso 1: Redirección y solicitud

1. El usuario pulsa “Iniciar sesión con…” en la aplicación
2. La aplicación redirige el navegador al IdP (Proveedor de Identidad)
3. La solicitud incluye:
   • La URL de retorno (redirect URL)
   • Los scopes solicitados (Un scope define hasta dónde puede llegar. Mínimo: openid)

Paso 2: Verificación de identidad

1. El IdP solicita las credenciales del usuario
2. El usuario se autentica (normalmente con MFA)
3. El IdP emite un código temporal de un solo uso
4. El navegador es redirigido de vuelta a la aplicación con ese código

Paso 3: Intercambio seguro de tokens

1. La aplicación envía el código directamente al IdP (fuera del navegador)
2. Se autentica usando sus credenciales (client_id y client_secret)
3. El IdP devuelve los tokens:
   • Access Token: se usa para autorización contra APIs o recursos
   • ID Token: un JWT firmado que contiene los claims de identidad del usuario (nombre, correo, identificador único, etc.)

La aplicación valida la firma del ID Token y, al confiar en el IdP, concede acceso al usuario.

Implementaciones y fabricantes más comunes

OIDC, como ya hemos comentado, es un estándar, pero se materializa a través de productos concretos.

Actor	Rol	Implementaciones habituales
Proveedor de Identidad (IdP)	Autentica al usuario y emite tokens	Microsoft Entra ID, Google, Okta, Auth0, Keycloak, Ping Identity
Aplicación (Cliente)	Consume el ID Token	Proxmox VE, Kubernetes, AWS/GCP, aplicaciones web y SaaS, WordPress

Escenarios de uso más habituales

• SSO corporativo
  • OIDC se utiliza para centralizar el acceso a todas las herramientas de una organización. Un usuario puede ser habilitado o revocado desde un único directorio, impactando en todos los sistemas:
    • Plataformas de infraestructura (Proxmox, Kubernetes, paneles de cloud).
    • Herramientas internas y SaaS corporativos.
• Arquitecturas modernas y APIs
  • En microservicios, los sistemas no gestionan identidades directamente. Simplemente verifican la firma del token emitido por el IdP, lo que permite escalabilidad y desacoplamiento.
• Federación e inicio de sesión social
  • OIDC permite confiar en identidades externas:
    • Federación entre empresas y proveedores cloud (AWS, GCP).
    • Inicio de sesión social con Google, Microsoft o Facebook.

SSO, Seguridad y Estandarización

OpenID Connect resolvió de forma elegante el problema de la identidad en la web moderna. Al estandarizar el uso de ID Tokens (JWT), permitió que cualquier aplicación pudiera integrarse con cualquier proveedor de identidad compatible.

Los beneficios clave son claros:

• Mayor seguridad: la contraseña nunca se distribuye.
• Mejor experiencia de usuario: menos credenciales que recordar.
• Administración centralizada y control de acceso consistente.

La próxima vez que utilices SSO, sabrás que detrás hay un protocolo robusto, estandarizado y ampliamente adoptado asegurando tu identidad de forma transparente y eficiente.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!