OpenID Connect (OIDC) es una capa de identidad desarrollada sobre OAuth 2.0 que permite a las aplicaciones autenticar a los usuarios y obtener su información de perfil. OAuth 2.0 maneja la autorización (a qué puede acceder un usuario), mientras que OIDC agrega la autenticación (quién es el usuario) mediante tokens de ID estandarizados.

Ejemplo: Cuando un usuario hace clic en “Continuar con Google” para iniciar sesión en Spotify, OIDC verifica su identidad con Google. Spotify recibe la información de perfil, como el nombre y el correo electrónico. La contraseña de Google nunca se comparte. Google emite un token de identificación que contiene datos de identidad, como el ID de usuario y la información de perfil. Algunos datos (como la verificación del correo electrónico) se marcan explícitamente como verificados.

OIDC se usa mucho para la autenticación moderna en sitios web y dispositivos móviles. Publicado en 2014 por OpenID Foundation, combina la autorización OAuth 2.0 con la verificación de identidad. Los principales proveedores de identidad son compatibles con OIDC, por lo que se usa comúnmente para el inicio de sesión único (SSO), el inicio de sesión social y las aplicaciones para consumidores.

Antes de OIDC, los desarrolladores se enfrentaban a tres grandes desafíos:

1. Ausencia de una capa de identidad estándar

   OAuth 2.0 ofrece autorización, pero no define un método de autenticación estandarizado o interoperable. Como resultado, los desarrolladores crearon soluciones personalizadas, lo cual generó problemas de interoperabilidad.

2. Alternativas complejas

   SAML 2.0 es compatible con la autenticación empresarial, pero usa XML muy detallado, requiere certificados y funciona mal en dispositivos móviles.

3. Riesgos de exposición de credenciales

   En el pasado, las aplicaciones solían almacenar las credenciales de los usuarios o exigían compartir contraseñas, lo que generaba riesgos de seguridad y una experiencia de usuario deficiente.

OIDC aborda todas estas cuestiones. Las aplicaciones reciben tokens de identificación firmados criptográficamente con información de identidad verificada. Ya no es necesario almacenar las credenciales, y la autenticación es uniforme en todas las plataformas. OIDC autentica a los usuarios, pero no gestiona los datos de usuario, los roles ni los permisos específicos de la aplicación.

OIDC se basa en los roles de OAuth 2.0 y en terminología específica de identidad.

• Usuario final: Es la persona cuya identidad se está verificando.
• Parte confiable (RP): Se trata de la aplicación que solicita la autenticación del usuario.
• Proveedor de OpenID (OP): Es el proveedor de identidad que autentica a los usuarios y emite tokens de ID. En OIDC, el OP funciona como el servidor de autorización OAuth 2.0.

Información de los tokens de ID

Los tokens de ID son tokens web JSON (JWT) que contienen información de identidad y deben validarse antes de usarse.

• sub: Identificador estable y único para el usuario dentro del emisor
• iss: Emisor del token (URL del proveedor de OpenID)
  aud: Aplicación prevista (ID de cliente)
• exp: Tiempo de caducidad (marca de tiempo Unix)
• iat: Horario de emisión (marca de tiempo Unix)
• auth_time: marca de tiempo de autenticación
• nonce: Previene ataques de repetición (obligatorio si se envía en la solicitud)

Ámbitos comunes de OIDC

Los ámbitos definen la información de usuario solicitada.

• openid: Obligatorio; activa OIDC
• profile: Nombre, foto e información básica del perfil
• email: Dirección de correo electrónico y verificación
• address: Dirección física
• phone: Número de teléfono y verificación

Dado que OIDC extiende OAuth 2.0, el flujo es similar al flujo de código de autorización de OAuth con incorporaciones específicas de OIDC.

El flujo de autenticación de OIDC

1. Solicitud de autenticación. La RP redirige al usuario al OP con el ID de cliente, la URI de redirección, response_type=code y el ámbito (incluido openid).
2. Autenticación y consentimiento del usuario. El OP autentica al usuario con contraseña, MFA o datos biométricos. La pantalla de consentimiento muestra los datos solicitados.
3. Respuesta de autorización. El OP hace un nuevo redireccionamiento con un código de autorización y un parámetro de estado.
   Solicitud de token. La RP intercambia un código por tres tokens: un token de ID, un token de acceso y un token de actualización opcional. Los clientes confidenciales realizan esta operación de servidor a servidor. Los clientes públicos emplean PKCE.
4. Validación de tokens. La RP valida la firma, la fecha de caducidad, el emisor, el público y el valor de un solo uso (nonce) del token de ID con las claves públicas del proveedor (JWKS). El token de ID es exclusivo para la aplicación cliente y nunca se debe enviar a las API. En cambio, las API deben validar los tokens de acceso.
5. Acceso al perfil de usuario. Opcionalmente, la RP llama al extremo UserInfo con un token de acceso para recuperar información de perfil adicional.

Clave de prueba para intercambio de códigos (PKCE)

La PKCE evita ataques de interceptación de códigos de autorización. Los clientes públicos (aplicaciones móviles y SPA) usan la PKCE, ya que no pueden almacenar de forma segura secretos de cliente. Los clientes confidenciales suelen autenticarse con un secreto de cliente. Muchas implementaciones modernas también incorporan la PKCE para reforzar la seguridad.

¿Cómo decidir qué flujo usar?

Flujo	Caso de uso	Seguridad	Estado
Código de autorización con PKCE	Todas las aplicaciones modernas (web, móvil, SPA)	Máxima	Recomendado para todos los clientes
Flujo implícito	Ninguno	Baja	Obsoleto (RFC 8252)
Flujo híbrido	Empresa compleja	Media	Solo para sistemas heredados

• El uso de códigos de autorización con PKCE es la práctica recomendada, y se prevé que sea obligatorio en OAuth 2.1.
• El flujo implícito está obsoleto debido a problemas de seguridad.
• El flujo híbrido se usa principalmente en entornos empresariales heredados o especializados y, por lo general, no es necesario para la mayoría de las aplicaciones modernas.

Validación del token de ID

Los tokens de identificación se deben validar en términos de firma, fecha de caducidad, emisor, público y valor de un solo uso (nonce).

Pasos de validación:

• Verificar la firma usando claves de JWKS
• Verificar que el emisor coincida con el proveedor
• Verificar que el público coincida con el ID del cliente
• Confirmar que el token no caducó
• Validar que el valor de un solo uso (nonce) coincida con la solicitud

Práctica recomendada: Use bibliotecas de OIDC consolidadas que manejen la validación.

Manejo del nonce

El valor de un solo uso o nonce evita ataques de repetición. Un atacante podría reutilizar un token de identificación válido sin un nonce. Los nonces previsibles, reutilizados o no verificados son inseguros.

Práctica recomendada: Genere nonces criptográficamente aleatorios, almacénelos en el servidor con un TTL de 5 a 10 minutos y valide las coincidencias exactas.

Almacenamiento del token

Los tokens de ID contienen información confidencial. Nunca use localStorage ni sessionStorage debido a las vulnerabilidades de secuencias de comandos entre sitios (XSS).

Práctica recomendada: Use almacenamiento en memoria para las SPA o emplee cookies seguras y exclusivamente HTTP cuando use un patrón de backend para frontend (BFF). Las sesiones cifradas en el servidor son más seguras.

Solicitudes de ámbito

Solicite únicamente los ámbitos que su aplicación necesite. Evite proporcionar datos de perfil innecesarios.

Uso del extremo UserInfo

Solo llame a UserInfo si el token de ID no incluye la información necesaria. El extremo requiere un token de acceso y suele tener limitaciones de velocidad. Valide siempre los tokens de acceso y almacene en caché las respuestas si es necesario.

OIDC funciona mejor en aplicaciones orientadas al consumidor, aplicaciones móviles y autenticación web moderna. Elija OIDC para el inicio de sesión social, el SSO y situaciones en las que los usuarios se autentican con cuentas que ya tienen.

SAML 2.0 sigue siendo común en los sistemas empresariales y gubernamentales heredados, mientras que muchas organizaciones adoptan cada vez más OIDC para nuevas aplicaciones de gestión de personal. Muchas organizaciones emplean ambos: OIDC para aplicaciones modernas y SAML para la federación empresarial.

• Valide los tokens de ID por completo con claves JWKS. Verifique los siguiente: firma, exp, iss, aud y nonce. Los tokens de ID nunca deben enviarse a las API.
• Use HTTPS para todas las comunicaciones de producción. RFC 6749 permite excepciones para localhost únicamente durante el desarrollo.
• Implemente PKCE para todos los clientes (se prevé que sea obligatorio en OAuth 2.1).
• Proteja el almacenamiento de tokens con cookies HTTP o sesiones en el servidor.
• Valide las URI de redireccionamiento de forma explícita. Nunca use comodines.
• Implemente el parámetro de estado para evitar ataques CSRF.
• Use tokens de corta duración (de 15 a 60 minutos) y tokens de actualización con rotación.
• Respete el consentimiento del usuario y minimice la solicitud de datos de perfil.

Aspecto	OIDC	OAuth 2.0	SAML 2.0
Objetivo	Autenticación	Autorización	Autenticación y SSO
Tecnología	OAuth 2.0	Especificaciones OAuth de IETF	Estándares SAML basados en XML
Formato de token	JWT	Token portador (formato no especificado)	XML
Información de identidad	Estándar	No definida	Declaraciones de atributos
Compatibilidad con dispositivos móviles	Excelente	Excelente	Deficiente
Casos de uso	Autenticación de usuario, inicio de sesión social	Acceso a la API	SSO empresarial
Nivel de complejidad	Bajo	Bajo	Alto
Público objetivo	Aplicaciones modernas	API	Federación empresarial

OIDC y OAuth 2.0 se complementan. OIDC responde a la pregunta “¿quién es este usuario?” OAuth 2.0 responde a la pregunta “¿a qué puede acceder este usuario?” SAML se usa mucho para el SSO empresarial. OIDC es la opción preferida para aplicaciones modernas y compatibilidad con dispositivos móviles.

¿Cuál es la diferencia entre OAuth 2.0 y OpenID Connect?

OAuth 2.0 es para la autorización. OIDC agrega autenticación. OAuth responde a la pregunta: “¿a qué puede acceder esta aplicación?” OIDC responde a la pregunta: “¿quién es este usuario?”

¿Qué es un token de ID y por qué es importante?

Un token de ID es un JWT firmado que contiene información de identidad afirmada por el proveedor. Demuestra que la autenticación se produjo. A diferencia de los tokens de acceso, su propósito es que el cliente verifique la identidad del usuario. La firma permite la validación sin necesidad de contactarse con el proveedor. La información más común incluye el ID de usuario (sub), el correo electrónico y la hora de autenticación. Valide siempre los tokens de ID.

¿Puedo usar OIDC sin OAuth 2.0?

No. OIDC está basado en OAuth 2.0. Cada flujo de OIDC es un flujo de OAuth 2.0 con el ámbito openid y el token de ID agregados. OIDC amplía OAuth 2.0; no lo reemplaza.

¿Es OIDC más seguro que SAML?

Ambas opciones son seguras si se implementan correctamente. OIDC emplea una validación JWT más sencilla. SAML requiere firmas XML, que son de naturaleza más compleja. La mayoría de las vulnerabilidades surgen de errores de implementación, y no del protocolo en sí. El formato de token más sencillo de OIDC ayuda a reducir el riesgo relacionado con la implementación.

¿Qué es el extremo UserInfo?

El extremo UserInfo devuelve información adicional del perfil de usuario. Requiere un token de acceso válido, no el token de ID. Úselo únicamente si el token de ID no contiene las declaraciones necesarias. El extremo suele tener limitación de velocidad, por lo que se recomienda implementar el almacenamiento en caché para mejorar el rendimiento.

¿Necesito validar los tokens de ID de un proveedor de confianza?

Sí. Valide siempre la firma, el emisor, el público, la fecha de caducidad y el nonce. La validación garantiza que el token sea auténtico y que esté vigente y destinado a su aplicación. Incluso los tokens de proveedores de confianza deben ser validados para evitar la manipulación y los ataques de repetición.

¿OIDC puede funcionar sin HTTPS?

No. Se requiere HTTPS para la producción. Los atacantes pueden interceptar los tokens enviados por HTTP. Las excepciones de localhost solo están permitidas en la etapa de desarrollo.

Uso de las bibliotecas de OIDC

Las bibliotecas maduras gestionan la validación de tokens, la gestión de claves JWKS y los detalles del protocolo. Las bibliotecas pueden ayudar a reducir los errores, pero se deben entender los conceptos de OIDC.

Estas son algunas de las bibliotecas de código abierto más famosas:

• Node.js: openid-client
• Python: authlib
• Python: pyoidc
• Java: Spring Security OAuth

Uso de plataformas de identidad

Las plataformas de identidad ofrecen implementaciones de OIDC y OAuth 2.0 con seguridad integrada, inicio de sesión social y capacidades de traducción de protocolos. También pueden gestionar las actualizaciones, el cumplimiento normativo y la escalabilidad, lo que permite a los desarrolladores centrarse en la lógica de la aplicación.

Auth0 simplifica las implementaciones de OIDC y OAuth 2.0, lo que permite a los desarrolladores centrarse en crear aplicaciones mientras gestionan de forma segura la autenticación y la identidad.

Explore nuestra serie de Introducción a la IAM sobre la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.