Uso de OpenID Connect para ampliar OAuth 2.0

Un token de identidad es un token protegido por integridad y autónomo (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 JWT de token de identidad 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 en 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 en función de 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 las sesiones autenticadas y los usuarios finales. Consulte OpenID Connect para obtener más información.

¿Por qué validamos 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. Cuando se utiliza la identidad basada en reclamaciones, se subcontrata ese trabajo a un proveedor de identidad.

La responsabilidad pasa de verificar las credenciales raw a verificar que el solicitante haya pasado por su proveedor de identidad preferido y se haya autenticado correctamente. El proveedor de identidad representa una autenticación correcta mediante la emisión de un token. Antes de poder utilizar la información o confiar en ella como afirmación de que el usuario se 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 los 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 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, información de usuario 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 Connect OpenID para recuperar información de perfil sobre la identidad que se ha autenticado. 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 Connect 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, no se utiliza el ámbito email), 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. En el siguiente ejemplo se 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":""
}

Antes de que la aplicación cliente pueda confiar en los valores devueltos desde el punto final UserInfo (por ejemplo, como una comprobación del ataque de sustitución de token), el cliente debe verificar que la reclamación sub devuelta desde la solicitud de punto final UserInfo coincide 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 luego 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 que tienen 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 solicitudes y respuestas del Cliente Confidencial que se han tratado anteriormente.

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

2. Solicitar 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 de 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 secuencias de comandos 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 símbolo 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 (en función de 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 de API de negocio.

Los clientes deben admitir tanto las solicitudes y respuestas basadas en explorador como las solicitudes y respuestas programáticas/de canal posterior 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

El flujo híbrido consta de cuatro pasos 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 (en función de 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: