Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les agents utilisent des protocoles OAuth 2.0 avec des modèles d’échange de jetons spécialisés activés par les informations d’identification d’identité fédérée (FIC). Tous les flux d’authentification de l’agent impliquent des échanges de jetons à plusieurs étapes où le schéma d’identité de l’agent imite l’identité de l’agent pour effectuer des opérations. Cet article explique les protocoles d’authentification et les flux de jetons utilisés par les agents. Il couvre les scénarios de délégation, les opérations autonomes et les modèles d’informations d’identification d’identité fédérée. Microsoft vous recommande d’utiliser nos kits SDK tels que microsoft Entra SDK pour l’ID de l’agent , car l’implémentation de ces étapes de protocole n’est pas facile.
Toutes les entités d’agent sont des clients confidentiels qui peuvent également servir d’API pour les scénarios On-Behalf-Of. Les flux interactifs ne sont pris en charge pour aucun type d’entité d’agent, ce qui garantit que toutes les authentifications se produisent via des échanges de jetons programmatiques plutôt que des flux d’interaction utilisateur.
Avertissement
Microsoft recommande d’utiliser les kits SDK approuvés tels que les bibliothèques sdk Microsoft.Identity.Web et Microsoft Agent ID pour implémenter ces protocoles. L’implémentation manuelle de ces protocoles est complexe et sujette aux erreurs, et l’utilisation des kits SDK permet de garantir la sécurité et la conformité avec les meilleures pratiques.
Prerequisites
Si vous n’êtes pas familiarisé déjà, passez par la documentation de protocole suivante.
- Plate-forme d'identité Microsoft et flux OAuth 2.0 On-Behalf-Of
- Plateforme d'identités Microsoft et le flux d’informations d’identification du client OAuth 2.0
Types d’octroi pris en charge
Voici les types d’octroi pris en charge pour les applications d’agent.
Blueprint d’identité de l’agent
Les blueprints d’identité de l’agent permettent client_credentials l’activation de l’acquisition de jetons sécurisés pour les scénarios d’usurpation d’identité. Le jwt-bearer type d’octroi facilite les échanges de jetons dans les scénarios On-Behalf Of, ce qui permet des modèles de délégation.
refresh_token accorde l’activation d’opérations en arrière-plan avec le contexte utilisateur, prenant en charge les processus de longue durée qui conservent l’autorisation utilisateur.
Identité de l’agent
Les identités d’agent utilisent client_credentials pour les opérations autonomes uniquement pour l'application, ce qui permet une fonctionnalité indépendante sans contexte utilisateur et l’usurpation d'identité pour une identité d’agent utilisateur. Le jwt-bearer type d’octroi prend en charge le flux d’informations d’identification du client et le flux OBO (On-Behalf Of) offrant une flexibilité dans les modèles de délégation.
refresh_token les autorisations facilitent les opérations en arrière-plan déléguées par l'utilisateur, ce qui permet aux identités d'agent de maintenir le contexte de l'utilisateur dans les opérations étendues.
Flux non pris en charge
Le modèle d’application de l’agent exclut explicitement certains modèles d’authentification pour maintenir les limites de sécurité. Les flux OBO utilisant le /authorize point de terminaison ne sont pas pris en charge pour toute entité d’agent, ce qui garantit que toutes les authentifications sont effectuées par programmation.
Les fonctionnalités des clients publics ne sont pas disponibles, ce qui oblige tous les agents à fonctionner en tant que clients confidentiels. Les URL de redirection ne sont pas prises en charge.
Modèles de protocole principaux
Les agents peuvent fonctionner en trois modes principaux :
- Agents fonctionnant pour le compte d’utilisateurs réguliers dans Microsoft Entra ID (agents interactifs). Il s’agit d’un flux de délégation régulier.
- Les agents fonctionnant en leur propre nom à l’aide de principaux de service créés pour les agents (autonomes).
- Les agents agissant en leur propre nom en utilisant des identités utilisateur créées spécifiquement pour cet agent (par exemple, les agents ayant leur propre boîte aux lettres).
Intégration des identités managées
Les identités managées sont le type d’informations d’identification préféré. Dans cette configuration, le jeton d’identité managée sert d’informations d’identification pour le blueprint d’identité de l’agent parent, tandis que les protocoles MSI standard s’appliquent à l’acquisition d’informations d’identification. Cette intégration permet à l’ID de l’agent de recevoir les avantages complets de la sécurité et de la gestion MSI, notamment la rotation automatique des informations d’identification et le stockage sécurisé.
Avertissement
Les secrets client ne doivent pas être utilisés comme informations d’identification client dans des environnements de production pour les blueprints d’identité de l’agent en raison des risques de sécurité. Utilisez plutôt des méthodes d’authentification plus sécurisées telles que les informations d’identification d’identité fédérée (FIC) avec des identités managées ou des certificats clients. Ces méthodes offrent une sécurité renforcée en éliminant la nécessité de stocker des secrets sensibles directement dans la configuration de votre application.
Protocoles OAuth
Il existe trois flux OAuth :
- Agent au nom du flux : agents qui opèrent pour le compte d’utilisateurs réguliers (agents interactifs).
- Flux d’application autonome : les opérations d’application uniquement permettent aux identités d’agent d’agir de manière autonome sans contexte utilisateur.
- Flux utilisateur de l’agent : les agents qui fonctionnent pour leur propre compte à l’aide de principaux d’utilisateur créés spécifiquement pour les agents.