¿Qué es OIDC: Desde por qué lo necesitamos hasta cómo funciona

Definición de OpenID Connect (OIDC)#

OpenID Connect (OIDC) es un protocolo de autenticación de identidad construido sobre OAuth 2.0. Mientras que OAuth 2.0 solo proporciona autorización, OIDC añade capacidades de autenticación, ofreciendo una solución más estandarizada para escenarios de autorización y autenticación de usuarios.

En pocas palabras: OIDC = Protocolo de Autorización + Autenticación de Identidad.

¿Por qué es necesario OIDC?#

Para entender por qué OIDC es necesario, exploremos primero los conceptos básicos y el flujo de trabajo de OAuth 2.0, y sus limitaciones en aplicaciones prácticas. A través del análisis de escenarios específicos, veremos por qué necesitamos OIDC sobre OAuth 2.0.

Conceptos clave y flujo de autorización de OAuth 2.0#

OAuth 2.0 (Open Authorization) es un protocolo de autorización que permite a los usuarios otorgar a aplicaciones de terceros acceso a sus recursos sin compartir sus credenciales, como nombres de usuario y contraseñas. Involucra cuatro roles principales:

• Propietario del Recurso: El usuario que posee los recursos
• Servidor de Recursos: El servidor que almacena los recursos del usuario
• Cliente: La aplicación de terceros que solicita acceso a los recursos del usuario
• Servidor de Autorización: El servidor que verifica la identidad del usuario y emite tokens de acceso

Un flujo típico de autorización de OAuth 2.0 funciona así:

Como se muestra, OAuth 2.0 maneja principalmente la emisión de tokens de acceso para que los clientes de terceros accedan a los recursos del usuario.

La limitación de OAuth 2.0#

El protocolo OAuth 2.0 solo se centra en emitir tokens de acceso. El servidor de recursos valida estos tokens y devuelve los recursos autorizados. Sin embargo, el servidor de recursos no sabe cuál es la identidad del usuario.

Esto no era un problema significativo en el ecosistema de internet temprano.

Sin embargo, a medida que plataformas como Google, Facebook, Twitter y Github evolucionaron, comenzaron a ofrecer recursos de usuario ricos que se volvieron valiosos para aplicaciones de terceros.

Si bien OAuth 2.0 sobresale en la autorización de acceso de terceros a los recursos del usuario, tiene limitaciones. Un escenario típico es: dado que la información del usuario también es un recurso, cuando las aplicaciones de terceros necesitan acceder a la información básica del usuario, diferentes plataformas (como Google, Facebook, Twitter) devuelven la información del usuario en diferentes formatos, creando desafíos para los desarrolladores.

OIDC fue creado para abordar estos desafíos.

Roles en OIDC#

Para habilitar la autenticación de usuario en la parte superior de OAuth 2.0 y abordar sus limitaciones, OIDC introdujo tres roles:

• Usuario Final (EU): El usuario final, correspondiente al Propietario del Recurso de OAuth 2.0
• Parte Dependiente (RP): La parte dependiente, correspondiente al Cliente de OAuth 2.0
• Proveedor de OpenID (OP): El proveedor de servicios de autenticación de identidad, correspondiente al Servidor de Autorización y Servidor de Recursos de OAuth 2.0

El OP es el rol central, proporcionando tanto la funcionalidad de autorización de OAuth 2.0 como tratando la información del usuario como un recurso separado.

¿Cómo funciona OIDC?#

El proceso de autenticación de OIDC es similar a OAuth 2.0, pero dado que el OP combina los roles de Servidor de Autorización y Servidor de Recursos, devuelve tanto un Token de Acceso como un Token de ID. El Token de ID contiene información de identidad del usuario, y el RP puede verificar la identidad del usuario validando el Token de ID.

Un flujo de trabajo típico se ve así:

Esto estandariza cómo se obtiene la información del usuario a través de diferentes plataformas, eliminando la necesidad de que las aplicaciones de terceros manejen diferencias específicas de la plataforma.

Token de ID (token de identidad) en OIDC#

Cuando los usuarios autorizan aplicaciones de terceros, el OP devuelve tanto un Token de Acceso de OAuth 2.0 como un Token de ID en formato JWT. Este Token de ID contiene información de identidad del usuario como ID de usuario, nombre de usuario, correo electrónico y avatar. El RP puede confirmar la identidad del usuario validando el Token de ID.

Como JWT, el Token de ID contiene declaraciones estandarizadas, incluidas estas declaraciones principales requeridas:

• iss (Emisor): Identificador único del Proveedor de OpenID que emite el Token de ID
• sub (Sujeto): Identificador único del usuario
• aud (Audiencia): Identificador de la aplicación cliente que recibe el Token de ID
• exp (Tiempo de expiración): Cuándo expira el Token de ID
• iat (Emitido en): Cuándo se emitió el Token de ID

Para información detallada sobre los tokens de ID, por favor consulte: Token de ID.

Endpoint de información del usuario#

El Endpoint de Información del Usuario es una API HTTP estandarizada proporcionada por el OP para obtener detalles del usuario autenticado. Al enviar solicitudes GET o POST con un Token de Acceso a este endpoint, puedes recibir información del usuario en formato JSON. Los datos devueltos incluyen campos estandarizados como ID de usuario único (sub), nombre de usuario (name), correo electrónico y foto.

El proceso de obtener información del usuario sigue el mismo patrón que el acceso a recursos protegidos en OAuth 2.0. Usualmente, la información del usuario obtenida desde el endpoint de información del usuario es más completa que la contenida en el token de ID, ya que el token de ID se utiliza principalmente para la autenticación de identidad e información básica del usuario.

Para información detallada sobre el endpoint de información del usuario, por favor consulte: Endpoint de información del usuario.

Ten en cuenta que la información del usuario que recibes desde el endpoint de información del usuario depende de los alcances solicitados y los permisos otorgados durante la autorización.

Alcances en OIDC#

Los alcances en OIDC definen qué información del usuario puede acceder el RP. OIDC define alcances estándar, siendo el alcance openid obligatorio en los flujos de autenticación de OIDC.

Los alcances estándar comunes incluyen:

• openid: Indica una solicitud de autenticación OIDC
• profile: Información básica del usuario como nombre y avatar
• email: Información del correo electrónico del usuario
• phone: Número de teléfono del usuario
• address: Información de la dirección del usuario

Diferentes alcances devuelven diferente información del usuario. Por ejemplo, solicitar openid profile email devuelve información básica del usuario y correo electrónico en el Token de ID y en la información del usuario, mientras que openid profile email phone address incluye información de número de teléfono y dirección también.

Gestión de identidad basada en OIDC#

OIDC no es solo un protocolo de autenticación; es una herramienta poderosa para construir sistemas de gestión de identidad flexibles y escalables. Al añadir una capa de autenticación a OAuth 2.0, estandarizar los recursos de información del usuario y sentar las bases para características de gestión de identidad extendidas, OIDC habilita diversos escenarios de gestión de identidad:

• Inicio de sesión único (SSO): OIDC naturalmente soporta SSO a través de información de sesión de usuario extendida, permitiendo la gestión unificada del estado de inicio de sesión y el intercambio de identidad entre aplicaciones
• Gestión de estructura organizacional: La información de organización del usuario extendida puede gestionar estructuras organizacionales complejas, incluyendo jerarquías de departamento y relaciones de grupos de usuarios
• Gestión de permisos: Los atributos de permiso del usuario extendidos permiten un control de acceso a recursos granulado, incluyendo información de roles y configuración de políticas de permiso

La flexibilidad de OIDC se adapta a las necesidades cambiantes de la gestión de identidad. Muchos sistemas de gestión de identidad están construidos sobre OIDC, como Logto, que proporciona características de SSO, gestión de organización y gestión de permisos.