Tipos de otorgamiento

Editar en línea

El tipo de concesión indica el mecanismo de autorización que utiliza el cliente para obtener el token de identificación y el token de acceso de Verify. Puedes elegir entre código de autorización, implícito, código de autorización e implícito, flujo de dispositivo, credenciales del propietario del recurso, JWT, autorización basada en el contexto, token de actualización e intercambio de tokens.

Consulte las tablas siguientes para ver una comparación de los tipos de otorgamiento admitidos y determinar qué tipo de otorgamiento establecer para la aplicación.
Tabla 1. Tipos de subvenciones
Características Código preautorizado Código de autorización Implícito Código de autorización e implícito
Descripción /preauth El punto final de preautorización devuelve un código de preautorización. El código preautorizado se canjea por un token de acceso. /tokenEs necesario que el cliente se autentique para obtener un token de acceso a través del punto final de tokens.

El punto final de autorización /authorize devuelve un código de autorización. El código de autorización se puede intercambiar después por una señal de ID, señal de acceso o señal de renovación.

La autenticación de cliente es obligatoria y utiliza un ID de cliente y secreto para recuperar la señal de ID o la señal de acceso del punto final de señal /token.

Es el flujo más usado.

El punto final de autorización /authorize directamente devuelve una señal de ID o una señal de acceso.

No utiliza un código de autorización o un punto final de señal /token.

Permite al front-end y back-end del cliente recibir señales con independencia del otro.

El cliente obtiene un código de autorización y señales del punto final de autorización /authorize. Algunas se solicitan desde el punto final de señal /token.
Caso práctico Se utiliza en situaciones de emisión de credenciales en las que:
  • La autenticación y la autorización de los usuarios las lleva a cabo el emisor de las credenciales.
  • Las credenciales emitidas no requieren un alto nivel de seguridad, como, por ejemplo, al comprar una entrada de cine.

Lo utilizan los clientes que pueden mantener de forma segura un secreto de cliente como aplicaciones web y aplicaciones móviles nativas.

Su objetivo es autenticar al usuario y al cliente.

Lo utilizan los clientes que no pueden mantener un secreto de cliente como los navegadores o las aplicaciones basadas en JavaScript.

Tiene por objetivo autenticar al usuario.
Lo utilizan los clientes que:
  • Pueden mantener de forma segura un secreto de cliente como aplicaciones web y aplicaciones móviles nativas.
  • Necesitan acceso inmediato a la señal de ID para información de identidad.
  • Necesitan señales más duraderas mediante el uso de señales de renovación.
Valor de tipo de respuesta No aplicable 
code
 
id_token
token
id_token token
 
code id_token
code token
code id_token token
Todas las señales se devuelven desde el punto final de autorización. No aplicable No Sí No
Todas las señales se devuelven desde el punto final de señal. Sí Sí No No
Las señales no se descubren para el agente de usuario. Sí Sí No No
La aplicación cliente se puede autenticar. Sí Sí No Sí
Generar señales de renovación. Sí Sí No Sí
Comunicación en un viaje de ida y vuelta No No Sí No
La mayoría de las comunicaciones de servidor a servidor Sí Sí No varía
Sugerencia de inicio de sesión (login_hint) No Sí
Este valor podría ser el nombre de usuario como cadena, por ejemplo, john@ibm.com, o un JSON, por ejemplo,
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Cuando se utiliza un valor JSON, el dominio representa el dominio de origen de identidad.
 Sí
Este valor podría ser el nombre de usuario como cadena, por ejemplo, john@ibm.com, o un JSON, por ejemplo,
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Cuando se utiliza un valor JSON, el dominio representa el dominio de origen de identidad.
 Sí
Este valor podría ser el nombre de usuario como cadena, por ejemplo, john@ibm.com, o un JSON, por ejemplo,
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Cuando se utiliza un valor JSON, el dominio representa el dominio de origen de identidad.
Antigüedad máxima de autenticación (max_age) No aplicable Este valor es el tiempo permitido transcurrido, en segundos, desde la última vez que el usuario se ha autenticado activamente. Este atributo se aplica sólo a las sesiones de inicio de sesión de Cloud Directory. Este valor es el tiempo permitido transcurrido, en segundos, desde la última vez que el usuario se ha autenticado activamente. Este atributo se aplica sólo a las sesiones de inicio de sesión de Cloud Directory. Este valor es el tiempo permitido transcurrido, en segundos, desde la última vez que el usuario se ha autenticado activamente. Este atributo se aplica sólo a las sesiones de inicio de sesión de Cloud Directory.
Flujo de trabajo
  1. El emisor de credenciales autentica al usuario final y obtiene su autorización.
  2. El emisor de la credencial solicita el código preautorizado al servidor de autorización de Verify.
  3. El servidor de autorización de Verify genera el código de preautorización.
  4. El servidor de autorización de Verify envía, de forma opcional, el código de transacción al usuario final.
  5. El emisor de la credencial presenta el código preautorizado al monedero.
  6. La cartera solicita al usuario final que introduzca el código de transacción (si procede).
  7. El monedero sustituye el código preautorizado por un token de acceso.
  8. Wallet utiliza el token de acceso para recuperar la credencial del emisor de credenciales.
  1. El cliente prepara una solicitud de autenticación que contiene los parámetros de solicitud necesarios.
  2. El cliente envía la solicitud al servidor de Verify autorización.
  3. El Verify servidor de autorización autentica al usuario.
  4. El servidor de Verify autorización obtiene el consentimiento o la autorización del usuario.
  5. El Verify servidor de autorización devuelve al usuario al cliente con un código de autorización.
  6. El cliente solicita una respuesta de autenticación mediante el código de autorización en el punto final de señal.
  7. El cliente recibe una respuesta que contiene un ID de señal y una señal de acceso en el cuerpo de respuesta.
  8. El cliente valida la señal de ID y recupera el identificador de asunto del usuario.
  1. El cliente prepara una solicitud de autenticación que contiene los parámetros de solicitud necesarios.
  2. El cliente envía la solicitud al servidor de Verify autorización.
  3. El Verify servidor de autorización autentica al usuario.
  4. El servidor de Verify autorización obtiene el consentimiento o la autorización del usuario.
  5. El servidor de Verify autorización devuelve al usuario al cliente con un token de identificación y, si se solicita, un token de acceso.
  6. El cliente valida la señal de ID y recupera el identificador de asunto del usuario.
  1. El cliente prepara una solicitud de autenticación que contiene los parámetros de solicitud necesarios.
  2. El cliente envía la solicitud al servidor de Verify autorización.
  3. El Verify servidor de autorización autentica al usuario.
  4. El servidor de Verify autorización obtiene el consentimiento o la autorización del usuario.
  5. El servidor de Verify autorización devuelve al usuario al cliente con un código de autorización y, dependiendo del tipo de respuesta, uno o varios parámetros.
  6. El cliente solicita una respuesta mediante el código de autorización en el punto final de señal.
  7. El cliente recibe una respuesta que contiene un ID de señal y una señal de acceso en el cuerpo de respuesta.
  8. El cliente valida la señal de ID y recupera el identificador de asunto del usuario.
Tabla 2. Tipos de subvenciones (continuación)
Características Flujo de dispositivo Credenciales de contraseña del propietario del recurso JWT
Descripción Permite que el cliente reciba autorización utilizando un código QR o un código de usuario que se envía a un URL. La autenticación de cliente y usuario es necesaria por medio de un ID de cliente, un secreto de cliente, un nombre de usuario y una contraseña para recuperar la señal de acceso y la señal de ID del punto final de señal/señal. El nombre de usuario y la contraseña se valida contra Cloud Directory. Definido en RFC7523. Permite a un cliente presentar un JWT firmado o cifrado, o firmado y cifrado a cambio de un otorgamiento. El servidor de autorizaciones valida JWT y la identidad dentro del JWT se utiliza como sujeto del otorgamiento.
Caso práctico
Lo utilizan los clientes que:
  • No tienen un navegador para realizar un flujo OAuth basado en el agente de usuario.
  • Están limitados por la entrada hasta el punto de que exigir al usuario que entre mucho texto no es práctico.
Algunos ejemplos son: televisores inteligentes, consolas de distintos soportes, marcos de imagen digital e impresoras.
 Este tipo de otorgamiento puede estar habilitado, pero utilícelo si no hay ningún otro flujo disponible. Puede utilizarse para:
  • Propietarios de recursos que tienen una relación de confianza con el cliente, por ejemplo, el sistema operativo del dispositivo o una aplicación con muchos privilegios.
  • Los clientes que pueden obtener las credenciales del propietario del recurso (nombre de usuario y contraseña) utilizando un formato interactivo.
  • La migración de los clientes existentes que utilizan esquemas de autenticación directa, como HTTP Básica o autenticación resumen para OAuth convirtiendo la credenciales almacenadas en una señal de acceso.
 Existe una relación de confianza establecida entre el servidor de autorización (Verify) y una entidad, que emite JWT. El cliente obtiene un JWT de la entidad emisora de JWT y lo presenta al servidor de autorizaciones a cambio de un otorgamiento. La entidad emisora de JWT puede tener sus propios requisitos, que deben cumplirse antes de que se emita un JWT (como, por ejemplo, una autenticación alternativa y comprobaciones de autorización).
Valor de tipo de respuesta No aplicable No aplicable No aplicable
Todas las señales se devuelven desde el punto final de autorización. No No No
Todas las señales se devuelven desde el punto final de señal. Sí Sí Sí
Las señales no se descubren para el agente de usuario. Sí Sí Sí
La aplicación cliente se puede autenticar. Sí Sí Sí
Generar señales de renovación. Sí Sí Sí
Comunicación en un viaje de ida y vuelta
La mayoría de las comunicaciones de servidor a servidor
Sugerencia de inicio de sesión (login_hint) No No No
Antigüedad máxima de autenticación (max_age) No aplicable
Flujo de trabajo
  1. Los usuarios inician el flujo enviando el ID de cliente desde el dispositivo para solicitar un código de usuario y un código de dispositivo.
  2. Si el ID de cliente es válido, se devuelve el URI de verificación, el código de usuario y el código de dispositivo.
  3. El dispositivo visualiza el URI de verificación y el código de usuario para que el usuario escriba en un navegador o muestra un código QR para que el usuario lo escanee.
  4. El dispositivo trata continuamente de intercambiar el código de dispositivo por una señal.
  5. El usuario escanea o especifica el URI de verificación y el código de usuario manualmente para enviar el código de usuario al servicio OIDC.
  6. Si el código de usuario es válido, se envía un mensaje de éxito y se intercambia el código de dispositivo por una señal de acceso.
  1. El usuario escribe su nombre de usuario y contraseña en un formulario en la entidad de confianza.
  2. El cliente envía el nombre de usuario, contraseña, ID de cliente y el secreto de cliente al punto final de señal.
  3. El nombre de usuario y la contraseña se valida contra Cloud Directory.
  4. El cliente recibe una respuesta que contiene una señal de ID y señal de acceso en el cuerpo de la respuesta.
  1. El cliente obtiene un JWT (por cualquier medio externo) y lo presenta al punto final.
  2. Se valida el JWT y se extraen el sujeto y los atributos adicionales.
  3. El cliente recibe una respuesta que contiene una señal de ID y una señal de acceso en el cuerpo de respuesta.
Tabla 3. Tipos de subvenciones (continuación)
Características Autorización basada en contexto Renovar señal Intercambio de señal
Descripción Un flujo controlado por API en el que se realizan comprobaciones de autorización y autenticación adicionales. Antes de que se emita un otorgamiento al cliente, es posible que sea necesaria la autenticación de multifactores. Es necesario autenticar al cliente y al usuario mediante un ID de cliente, un secreto de cliente y un token de actualización para obtener un nuevo conjunto de token de acceso, token de identificación y token de actualización desde el punto final de tokens /token. El token de actualización debe pertenecer al mismo ID de cliente. Los valores de los atributos asociados al token no se actualizan durante este flujo. Definido en RFC8693. Permite a un cliente presentar un token para canjearlo por otro.
Caso práctico

  • El cliente debe estar equipado para manejar una respuesta de tipo de solicitud desde el servidor de autorización.

  • El cliente utiliza las API de factores de autenticación disponibles en Verify para obtener un JWT, que luego se presenta para continuar el proceso.
  • El cliente debe incluir información de contexto adicional en la solicitud mediante el parámetro `context`.
 Utiliza este tipo de autorización para obtener un nuevo conjunto de tokens de acceso, con una vigencia renovada. Esto permite que la vigencia del token de acceso sea breve, pero no obligará al usuario a volver a iniciar sesión para obtener un nuevo token de acceso.

  • Suplantación de identidad: cuando un cliente accede a un recurso haciéndose pasar por otra entidad.

  • Delegación: Cuando un cliente actúa en nombre de una entidad autorizada.
Valor de tipo de respuesta No aplicable No aplicable No aplicable
Todas las señales se devuelven desde el punto final de autorización. No No No
Todas las señales se devuelven desde el punto final de señal. Sí Sí Sí
Las señales no se descubren para el agente de usuario. Sí Sí Sí
La aplicación cliente se puede autenticar. Sí Sí Sí
Generar señales de renovación. Sí Sí Sí
Comunicación en un viaje de ida y vuelta Sí
La mayoría de las comunicaciones de servidor a servidor Sí
Sugerencia de inicio de sesión (login_hint) No No No
Antigüedad máxima de autenticación (max_age) No aplicable No
Flujo de trabajo
  1. El cliente inicia el flujo presentando un «contexto» mediante una solicitud que utiliza grant_type=Context-based authorization
  2. El cliente recibe un DENY (si no se debe permitir el acceso en este contexto) o una CHALLENGE (identificada a través del ámbito devuelto).
  3. El cliente utiliza la señal de acceso que se devuelve con la respuesta de solicitud para acceder a las API de factores de autenticación disponibles, incluido el distintivo para solicitar un JWT como resultado de completar un factor.
  4. El JWT devuelto del factor completado se presenta de nuevo en /token como una solicitud de otorgamiento de portador JWT (el contexto también se debe incluir) y se emiten señales.
Nota:
  • En función de la política configurada, después de que se ha realizado el primer factor, podrían ser necesarios factores adicionales. Es posible que estos factores requieran que se realice una segunda CHALLENGE (SOLICITUD) y un segundo factor de autenticación.
  • Este tipo de otorgamiento requiere que se cree y se adjunte una política de acceso personalizada a la aplicación. Esta política de acceso debe contener reglas para la autenticación de primer factor y, opcionalmente, cualquier requisito 2FA.
  1. El cliente detecta que el token de acceso está a punto de caducar o ya ha caducado, y desea obtener nuevos tokens de acceso.
  2. El cliente envía las credenciales del cliente y el token de actualización al punto final de tokens.
  3. Se validan el token de actualización y las credenciales del cliente.
  4. El cliente recibe una respuesta que contiene un token de identificación, un token de actualización y un token de acceso en el cuerpo de la respuesta.

  1. El cliente genera o recupera un token para utilizarlo como token de sujeto. Opcionalmente, también contará con una ficha de actor.

  2. Envía una solicitud al punto final de tokens del servidor de autorización con el token del sujeto y, opcionalmente, el token del actor.

  3. El servidor de autorización devuelve el token solicitado.