OpenID Connect - Capa de identidad sobre OAuth 2.0
Lectura de 2 min aprox.
OpenID Connect (OIDC) es un protocolo que añade una capa de autenticación sobre el marco de autorización OAuth 2.0. Establecido por la OpenID Foundation en 2014, se ha adoptado ampliamente como base técnica del inicio de sesión social, como «Iniciar sesión con Google» o «Iniciar sesión con Apple». Mientras que OAuth 2.0 gestiona «a qué se puede acceder (autorización)», la característica más destacada de OIDC es que estandariza «quién eres (autenticación)».
La diferencia entre OAuth 2.0 (autorización) y OIDC (autenticación)
OAuth 2.0 y OIDC se confunden con facilidad, pero los problemas que resuelven son fundamentalmente distintos. OAuth 2.0 es un mecanismo de autorización, como «conceder a esta app acceso a mi carpeta de fotos», y no tiene la capacidad de demostrar quién es el usuario. OIDC subsana esta carencia añadiendo información de autenticación llamada token de ID al flujo de OAuth 2.0.
| Aspecto | OAuth 2.0 | OIDC |
|---|---|---|
| Propósito | Autorización (conceder acceso a recursos) | Autenticación (verificar la identidad del usuario) |
| Tokens emitidos | Token de acceso | Token de ID + token de acceso |
| Información del usuario | No estandarizada | Estandarizada mediante el endpoint UserInfo |
| Analogía | La llave de una habitación de hotel (te deja entrar) | Un pasaporte (demuestra quién eres) |
Nuestro artículo sobre los riesgos de los permisos de OAuth explica en detalle los problemas de seguridad que surgen al confundir la autorización con la autenticación.
El papel del token de ID (JWT)
El núcleo de OIDC es el token de ID. Se emite en formato JWT (JSON Web Token) y contiene afirmaciones (claims) como el identificador del usuario (subject), el emisor, la caducidad y la hora de autenticación. El SP (Relying Party) verifica la firma del token de ID para confirmar que el token no ha sido manipulado y que fue emitido por un IdP de confianza.
El endpoint Discovery
Un proveedor de OIDC publica su información de configuración en una URL estandarizada llamada <code>.well-known/openid-configuration</code>. Este endpoint describe, en formato JSON, el endpoint de autorización, el endpoint de tokens, la ubicación para obtener las claves públicas (la URI JWKS), los ámbitos (scopes) admitidos y más. Al recuperar esta información automáticamente, un SP puede integrarse con el IdP sin ninguna configuración manual.
Uso en el inicio de sesión de Google y Apple
«Iniciar sesión con Google» e «Iniciar sesión con Apple» son implementaciones representativas de OIDC. Los usuarios solo se autentican con su cuenta de Google o Apple, sin necesidad de crear una contraseña nueva para cada servicio. En el caso de Apple, la opción «Ocultar mi correo» también ofrece una función para proteger la privacidad. Nuestro artículo sobre la protección de cuentas en redes sociales explica las medidas de seguridad al usar el inicio de sesión social.
Comparación con SAML
SAML es un protocolo de autenticación orientado a empresas que se estableció antes que OIDC. Ambos resuelven el mismo problema (la autenticación federada), pero sus enfoques técnicos difieren considerablemente.
| Aspecto | OIDC | SAML |
|---|---|---|
| Formato de datos | JSON / JWT | XML |
| Uso principal | Aplicaciones web y móviles | SSO empresarial |
| Complejidad de implementación | Relativamente simple | Compleja (procesamiento de firmas XML) |
| Compatibilidad móvil | Compatibilidad nativa | Dependiente del navegador |
Conceptos erróneos comunes
Existe el concepto erróneo de que «OIDC reemplaza a OAuth 2.0», pero OIDC no reemplaza a OAuth 2.0; es una extensión construida sobre él. Los tokens de acceso de OAuth 2.0 se siguen usando para el acceso a recursos, mientras que los tokens de ID de OIDC se usan solo para la autenticación. Ambos son complementarios, y muchas implementaciones usan OAuth 2.0 y OIDC a la vez. Consulta también nuestra guía de ajustes de privacidad para gestionar la privacidad al integrar servicios que usan OIDC.libros sobre OAuth y autenticación (Amazon) también son una referencia útil.
Casos de uso reales
«Migramos la infraestructura de autenticación de nuestro SaaS de una implementación propia a OIDC. Al admitir los IdP de Google y Microsoft, redujimos enormemente la barrera de adopción para los clientes empresariales, y nuestra tasa de conversión de prueba a contrato mejoró 1,5 veces. Realmente siento que la compatibilidad con SSO se ha vuelto un requisito esencial para el SaaS B2B.»
¿Te resultó útil este artículo?