Flujos de OAuth del agente: flujo con derechos delegados

Los agentes (planos técnicos de identidad del agente) que funcionan en nombre de los usuarios con sesión iniciada normal usan el protocolo OAuth 2.0 estándar con todas sus funcionalidades. La delegación de usuarios permite que las identidades de los agentes actúen en nombre de los usuarios que han iniciado sesión, utilizando los flujos estándar con derechos delegados de OAuth 2.0 con suplantación de identidad específica del agente. A la identidad del agente se le asignan los permisos delegados necesarios para el acceso de OBO. Requiere el consentimiento de los usuarios para acceder a sus datos.

Los agentes tienen las funcionalidades de las aplicaciones de recursos (API) de Microsoft Entra ID y admiten los atributos de API necesarios para (OAuth2Permissions, AppURI). Los planos técnicos de identidad del agente no pueden iniciar flujos de autorización interactiva (/authorize) directamente. Deben recibir un token de usuario de una aplicación cliente y, a continuación, realizar un intercambio de tokens de OBO. Un URI de redirección web solo se puede configurar en un plano técnico para flujos de consentimiento (response_type=none), pero tiene una funcionalidad limitada en comparación con un URI de redirección en un registro de aplicaciones.

Integración de identidades administradas

Las identidades administradas son el tipo de credencial preferido. En esta configuración, el token de identidad administrada actúa como credencial para el plano técnico de identidad del agente primario, mientras que los protocolos MSI estándar se aplican para la adquisición de credenciales. Esta integración permite que el identificador del agente reciba las ventajas completas de la seguridad y administración de MSI, incluida la rotación automática de credenciales y el almacenamiento seguro.

Pasos del protocolo

Los agentes no son compatibles con los flujos interactivos (/authorize). Los tipos de concesión admitidos son client_credential, jwt-bearery refresh_token. El flujo implica el plano técnico de identidad del agente, la identidad del agente y una credencial de cliente. La credencial de cliente puede ser un secreto de cliente, un certificado de cliente o una credencial de identidad federada (FIC). Cuando sea posible, use una identidad administrada para obtener el FIC.

1. El usuario se autentica con el cliente y obtiene un token de acceso de usuario (token de cliente, Tc).

2. El cliente envía el token de acceso de usuario (Tc) al esquema de identidad del agente para actuar en nombre del usuario. Es el token que se usa para el intercambio de OBO para el plano técnico de identidad del agente.

3. El plano técnico de identidad del agente solicita un token de intercambio mediante la presentación de su credencial de cliente (secreto, certificado o token de identidad administrada (TUAMI). En este ejemplo, usamos una identidad administrada como FIC. Microsoft Entra ID devuelve el token T1 al agente.

   Advertencia

   Los secretos de cliente no se deben usar como credenciales de cliente en entornos de producción para planos técnicos de identidad del agente debido a riesgos de seguridad. En su lugar, use métodos de autenticación más seguros, como credenciales de identidad federada (FIC) con identidades administradas o certificados de cliente. Estos métodos proporcionan seguridad mejorada eliminando la necesidad de almacenar secretos confidenciales directamente dentro de la configuración de la aplicación.

   POST /oauth2/v2.0/token
   Content-Type: application/x-www-form-urlencoded
   
   client_id=AgentBlueprint
   &scope=api://AzureADTokenExchange/.default
   &fmi_path=AgentIdentity
   &client_assertion=TUAMI
   &grant_type=client_credentials
   

   • fmi_path: El identificador de cliente (identificador de aplicación) de la identidad del agente. Este parámetro indica Microsoft Entra ID la identidad del agente secundario que el plano técnico está suplantando durante el intercambio de tokens.

   Donde TUAMI es el token de identidad administrada para la identidad administrada asignada al usuario (UAMI). Este paso devuelve T1.

4. La identidad del agente, un elemento secundario del modelo de identidad del agente, envía una solicitud de intercambio de tokens de OBO. Esta solicitud incluye T1 y el token de acceso de usuario Tc. Tenga en cuenta que cambia del plano técnico (en el paso anterior) a la identidad del agente aquí, ya que client_id la identidad del agente es la entidad que realiza el intercambio de OBO.

   POST /oauth2/v2.0/token
   Content-Type: application/x-www-form-urlencoded
   
   client_id=AgentIdentity
   &scope=https://resource.example.com/scope1
   &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
   &client_assertion={T1}
   &grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
   &assertion={Tc(aud=AgentIdentity Blueprint, oid=User)}
   &requested_token_use=on_behalf_of
   

5. Microsoft Entra ID devuelve el token de recurso después de validar T1 y Tc. Se aplican los siguientes requisitos de audiencia y vinculación:

   • Tc (aud) == id. de cliente del plano técnico de identidad del agente. La aserción de usuario debe ser audiencia en el plano técnico; Se rechaza un token con audiencia a otro recurso (por ejemplo, Microsoft Graph) con AADSTS50013.
   • T1 se obtiene con scope=api://AzureADTokenExchange/.default, por lo que aud es el recurso de intercambio de tokens en lugar del plano técnico. Microsoft Entra ID valida que T1 está enlazado al plano técnico (su azp es el plano técnico) y que T1 (la ruta del sub FMI) se resuelve en la identidad del agente secundario que realiza el intercambio.

Diagrama de secuencia

El siguiente diagrama de secuencia muestra el flujo de OBO.

Compatibilidad con tokens de actualización

El token de actualización se puede usar para escenarios asincrónicos y procesos en segundo plano:

POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentIdentity
&scope=https://resource.example.com/scope1
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion={T1}
&grant_type=refresh_token
&refresh_token={AgentIdentityRefreshToken}

Herencia de permisos

Las identidades de los agentes pueden heredar permisos delegados de su modelo de identidad del agente padre cuando la propiedad InheritDelegatedPermissions está habilitada. Este mecanismo de herencia reduce la complejidad del consentimiento para escenarios de varias instancias al permitir que las identidades de agente usen permisos ya concedidos a su aplicación primaria. La funcionalidad de herencia se aplica específicamente cuando se utiliza la suplantación de identidad FIC y permite una gestión eficaz de los permisos en múltiples instancias. Sin embargo, la herencia solo funciona dentro de los límites del inquilino, lo que garantiza que el ámbito de permiso permanezca dentro de los límites apropiados de la organización.

Contenido relacionado

• Flujos de Oauth2.0 para agentes
• Flujo autónomo de apps en agentes
• Flujo de la cuenta de usuario del agente en agentes
• Configurar permisos heredables para planos de identidad del agente