Uso de OpenID Connect to Extend OAuth 2.0

Un token de identidad es un token independiente y protegido por la integridad (en formato de token web JSON (JWT) que se define en el estándar OpenID Connect que contiene reclamaciones sobre el usuario final. El token de identidad es la extensión principal que OpenID Connect realiza en OAuth 2.0 para activar la autenticación en un dominio de identidad.

El token de identidad JWT consta de tres componentes, una cabecera, una carga útil y la firma digital. Siguiendo el estándar JWT, estas tres secciones están codificadas y separadas por puntos Base64URL.

OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0. Permite a una aplicación cliente de dominio de identidad de IAM (registrada como cliente OAuth 2 con ID de cliente y secreto de cliente) verificar la identidad del usuario final según la autenticación realizada por un servidor de autorización (AS) y obtener información de perfil básica sobre el usuario final de una manera interoperable y similar a REST. OpenID Connect permite a los clientes de todo tipo, incluidos los clientes basados en web, móviles y JavaScript, solicitar y recibir información sobre sesiones autenticadas y usuarios finales. Consulte OpenID Connect para obtener más información.

¿Por qué validamos los tokens? Cuando la aplicación web comprueba las credenciales directamente, verifica que el nombre de usuario y la contraseña que se presentan corresponden con lo que mantiene. Al utilizar la identidad basada en reclamaciones, subcontrata ese trabajo a un proveedor de identidad.

La responsabilidad pasa de verificar las credenciales raw a verificar que el solicitante ha pasado por el proveedor de identidad preferido y se ha autenticado correctamente. El proveedor de identidad representa una autenticación correcta mediante la emisión de un token. Para poder utilizar la información o confiar en ella como una afirmación que el usuario ha autenticado, debe validarla.

OpenID Documento de detección

El protocolo OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0 que requiere el uso de varios puntos finales para autenticar usuarios y para solicitar recursos que incluyen información de usuario, tokens y claves públicas. Para ayudar a detectar cuáles son estos puntos finales que debe utilizar, OpenID Connect le permite utilizar un documento de detección, que es un documento JSON que se encuentra en una ubicación conocida. Este documento de detección contiene pares de clave/valor que proporcionan detalles sobre la configuración del proveedor de Connect OpenID, incluidos los URI de los puntos finales de autorización, token, userinfo y claves públicas. Puede recuperar el documento de detección para el servicio de conexión OpenID del dominio de identidad de IAM desde: https://<domainURL>/.well-known/openid-configuration.

Una aplicación utiliza el punto final UserInfo de OpenID Connect para recuperar información de perfil sobre la identidad autenticada. Las aplicaciones pueden utilizar este punto final para recuperar información de perfil, preferencias y otra información específica del usuario.

El perfil de conexión OpenID consta de dos componentes:

• Reclamaciones que describen al usuario

• Punto final UserInfo que proporciona un mecanismo para recuperar estas reclamaciones

  Nota
  
  Las reclamaciones de usuario también se pueden presentar dentro del token de ID para eliminar una devolución de llamada durante el tiempo de autenticación.

Reclamaciones de perfil de usuario

El punto final UserInfo proporciona un juego de reclamaciones basado en los ámbitos OAuth2 presentados en la solicitud de autenticación. OpenID Connect define cinco valores de ámbito que se asignan a un juego específico de reclamaciones por defecto:

El cliente debe presentar sus credenciales y un token de acceso. El token de acceso presentado debe contener el ámbito openid.

Si se omite un ámbito (por ejemplo, el ámbito email no se utiliza), la reclamación (email) no estará presente en las reclamaciones devueltas.

Ejemplo de solicitud de punto final UserInfo

Después de que la aplicación cliente haya autenticado un usuario y tenga el token de acceso, el cliente puede realizar una solicitud al punto final UserInfo para recuperar los atributos solicitados sobre un usuario. El siguiente ejemplo muestra un ejemplo de solicitud.

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

Ejemplo de respuesta

Una respuesta correcta devuelve una respuesta HTTP 200 OK y las reclamaciones del usuario en formato JSON:

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

Para que la aplicación cliente pueda confiar en los valores devueltos del punto final UserInfo (por ejemplo, como ataque de comprobación de sustitución de token), el cliente debe verificar que la reclamación sub devuelta por la solicitud de punto final UserInfo coincida con el asunto del token de ID.

Utilice el flujo Código de autorización cuando tenga clientes que puedan mantener de forma segura un secreto de cliente entre ellos y el servidor de autorización. El flujo Código de autorización devuelve un Código de autorización al cliente, que puede intercambiar el código por un token de ID y un token de acceso directamente.

Esto le proporciona la ventaja de no exponer ningún token al agente de usuario (como un explorador web) y posiblemente a otras aplicaciones maliciosas con acceso al agente de usuario. El servidor de autorización también puede autenticar el cliente antes de intercambiar el código de autorización por un token de acceso. El flujo Código de autorización funciona tanto con clientes confidenciales como con clientes públicos.

Clientes Confidenciales

Clientes Públicos

Los clientes públicos no tienen credenciales, sino un identificador de cliente. Hay dos pasos en el flujo Código de autorización. Las solicitudes implican una solicitud GET basada en explorador y, a continuación, una solicitud POST de canal secundario para obtener el token de acceso.

1. Solicite el código de autorización.

   Ejemplo de solicitud

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   Ejemplo de respuesta

   Nota
   
   Estos ejemplos de solicitud y respuesta son similares a las respuestas y solicitudes del cliente confidencial tratadas anteriormente.

   https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

2. Solicite el token.

   Ejemplo de solicitud

   Nota
   
   Esta solicitud es diferente de la solicitud de cliente confidencial, donde el ID de cliente y el secreto de cliente se especifican en la cabecera Autenticación básica. En el flujo de cliente público, no hay ninguna cabecera de autenticación básica. El ID de cliente se especifica como parte de la carga útil de la solicitud.

      curl -i
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'   
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

   Ejemplo de respuesta

   {
   "access_token":"eyJ4NXQjUzI1???.xhtnbw",
   "token_type":"Bearer",
   "expires_in":27261,
   "id_token":"eyJ4NXQjUzI1???.._XLqUw"
   }
   

Utilice el flujo implícito cuando haya implantado un cliente basado en explorador mediante un lenguaje de script como JavaScript. El token de acceso y el token de ID se devuelven directamente al cliente, lo que puede exponer estos tokens al usuario y a las aplicaciones que tienen acceso al agente de usuario del usuario (como un explorador web).

Los siguientes valores response_type están soportados con el flujo implícito:

Obtención de un token de ID

Obtención de un token de acceso

Hay tres pasos en el flujo implícito para obtener un token de acceso:

1. Solicite el token de acceso.

   Ejemplo de solicitud

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

2. El usuario se conecta y da su consentimiento (según los ámbitos solicitados).

3. Respuesta con token de acceso

   Ejemplo de respuesta

   Nota
   
   Todos los parámetros de respuesta se agregan al componente de fragmento del URI de redirección.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

Obtención de un token de ID y un token de acceso

Utilice el flujo híbrido cuando desee obtener tokens por separado tanto del canal frontal como del canal posterior. Por ejemplo, tiene un componente de explorador como JavaScript y un componente de servidor de backend como Node.js. El componente del explorador obtiene el código de autorización y el token de ID y, a continuación, puede personalizar el contenido de la interfaz de usuario. El componente de backend obtiene el token de acceso para realizar llamadas a la API de negocio.

Los clientes deben admitir solicitudes y respuestas basadas en explorador, así como solicitudes y respuestas programáticas/de canal secundario para utilizar el flujo híbrido. El flujo híbrido funciona tanto con clientes confidenciales como con clientes públicos. Los siguientes valores response_type están soportados con el flujo híbrido:

Obtención de un token de ID

Obtención de un token de acceso

Hay cuatro pasos en el flujo híbrido para obtener el código de autorización y el token de acceso:

1. Solicite el código de autorización y el token de acceso.

   Ejemplo de solicitud

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

2. El usuario se conecta y da su consentimiento (según los ámbitos solicitados).

3. Respuesta con token de ID y código de autorización.

   Ejemplo de respuesta

   Nota
   
   Todos los parámetros de respuesta se agregan al componente de fragmento del URI de redirección.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

4. La aplicación cliente utiliza el código de autorización y realiza una solicitud de canal secundario para obtener un nuevo token de acceso.

   Ejemplo de solicitud

      curl -i
     -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
      -H 'Accept: */*''
      --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

   Ejemplo de respuesta

   {
   "access_token":"eyJ4NXQjUzI1....Tgs9LA",
   "token_type":"Bearer",
   "expires_in":3600
   }

Obtención de un token de ID y un token de acceso

Puede utilizar OpenID Connect para solicitudes de desconexión basadas en explorador.

Hay dos formas de solicitar una desconexión mediante OpenID Connect: