OpenID Connect u OIDC es un protocolo de identidad que utiliza los mecanismos de autorización y autenticación de OAuth 2.0. La especificación final de OIDC se publicó el 26 de febrero de 2014, y ahora es ampliamente adoptada por muchos proveedores de identidad en Internet.

OIDC fue desarrollado por la Fundación OpenID, que incluye empresas como Google y Microsoft. Mientras que OAuth 2.0 es un protocolo de autorización, OIDC es un protocolo de autenticación de identidad y puede utilizarse para verificar la identidad de un usuario ante un servicio de cliente, también llamado Parte de confianza. Además, las declaraciones de los usuarios, por ejemplo, el nombre, la dirección de correo electrónico, etc., también pueden ser compartidas a petición.

Una amplia variedad de clientes pueden utilizar OpenID Connect (OIDC) para identificar a los usuarios, desde aplicaciones de una sola página (SPA) hasta aplicaciones nativas y móviles. También puede utilizarse para el inicio de sesión único (SSO) entre aplicaciones. OIDC utiliza JSON Web Tokens (JWT), flujos HTTP y evita compartir las credenciales del usuario con los servicios.

OpenID Connect tiene el consentimiento incorporado. Esto es importante, ya que OIDC se utiliza a menudo en los servicios orientados al consumidor (por ejemplo, una parte de confianza), donde el intercambio de datos personales requiere el consentimiento explícito del usuario.

Estas características, junto con la simplicidad de la implementación, hacen de OpenID Connect un protocolo útil cuando se requiere la identidad de un usuario y una poderosa alternativa a la más compleja SAML 2.0. También es especialmente adecuado para las aplicaciones móviles.

OIDC utiliza OAuth 2.0 como protocolo subyacente. Las principales extensiones son un valor del ámbito especial (“openid”), el uso de un token adicional (el Token de ID, que encapsula las reclamaciones de identidad en formato JSON), y el énfasis en la autenticación en lugar de la autorización. Además, en OIDC, el término “flujo” se utiliza en lugar de “concesión” de OAuth2

El proveedor de OIDC (generalmente llamado proveedor de OpenID o proveedor de identidad o IdP) realiza la autenticación del usuario, el consentimiento del usuario y la emisión de tokens. El cliente o servicio que solicita la identidad de un usuario se denomina normalmente Parte de confianza (RP). Puede ser, por ejemplo, una aplicación web, pero también una aplicación JavaScript o una aplicación móvil.

Al estar construido sobre OAuth 2.0, OpenID Connect utiliza tokens para proporcionar una capa de identidad simple integrada con el marco de autorización subyacente. Esta integración implica el uso de los siguientes tipos de token:

Token de ID: Específicamente para OIDC, el uso principal de este token en formato JWT es proporcionar información sobre el resultado de la operación de autenticación. Mediante previa solicitud, puede proporcionar los datos de identidad que describen un perfil de usuario. Los datos sobre el resultado de la autenticación y la información del perfil del usuario se denominan reclamaciones. Las reivindicaciones del perfil del usuario pueden ser cualquier dato que sea pertinente para la Parte de confianza a efectos de identificación, como un ID persistente, una dirección de correo electrónico, un nombre, etc.

Token de acceso: Definido en OAuth2, este token (opcional) de corta duración proporciona acceso a recursos específicos del usuario, tal y como se define en los valores del ámbito en la solicitud al servidor de autorización.

Token de actualización: Según las especificaciones de OAuth2, este token suele ser de larga duración y puede usarse para obtener nuevos tokens de acceso.

Los tokens deben estar firmados digitalmente para evitar su manipulación. También pueden estar cifrados para proporcionar privacidad adicional, aunque, en muchos casos, la seguridad de la capa de transporte (HTTPS) es suficiente. Para las SPA y las aplicaciones móviles, el cifrado del token de ID no es útil, ya que la clave de descifrado puede descubrirse fácilmente.

La elección del flujo de OpenID Connect depende del tipo de aplicación y de sus requisitos de seguridad. Hay tres flujos comunes:

• Flujo implícito: En este flujo, comúnmente utilizado por las SPA, los tokens son devueltos directamente a la RP en un URI de redirección.

• Flujo del código de autorización: Este flujo es más seguro que el implícito, ya que los tokens no se devuelven directamente. En el caso de las aplicaciones nativas/móviles y SPA, la seguridad puede mejorarse utilizando la Clave de prueba para el intercambio de códigos.

• Flujo híbrido: Combinando los flujos implícito y del código de autorización, aquí, el token de ID se devuelve directamente a la RP, pero el token de acceso no. En su lugar, se devuelve un código de autorización que se intercambia por un token de acceso.

El proveedor de OpenID determina los métodos de autenticación disponibles para autenticar a los usuarios cuando inician sesión en su cuenta de IdP y posiblemente dan su consentimiento para liberar sus datos de identidad a la RP. Las especificaciones de OIDC no dicen nada sobre la mecánica de la autenticación del usuario en sí. El IdP puede ofrecer uno o varios factores, por ejemplo:

• Nombre de usuario/contraseña
• Código de uso único entregado fuera de banda, por ejemplo, por SMS o correo electrónico
• Código generado por la aplicación (OATH, TOTP o HOTP)
• Biometría a través de la aplicación
• Federada (por ejemplo, Facebook, GoogleID)
• La RP también puede opinar sobre la autenticación del IdP. Por ejemplo, se puede solicitar la autenticación multifactor. Sin embargo, la forma en que un IdP autentica a los usuarios está fuera del ámbito de OIDC.

Siga leyendo en nuestra página de Introducción a IAM para explorar más temas en torno a la gestión de identidades y accesos.