Protocoles d’authentification dans les agents

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 en plusieurs étapes où le blueprint d’identité de l’agent emprunte 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 ID SDK Auth (sidecar), 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 SDK approuvés, tels que Microsoft.Identity.Web et les bibliothèques Microsoft Entra ID Auth SDK (sidecar), pour mettre en œuvre 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.

Types d’octroi pris en charge

Voici les types d’autorisation pris en charge pour les applications d’agent.

Blueprint d’identité de l’agent

Les blueprints d’identité de l’agent prennent en charge le flux client_credentials, permettant une acquisition sécurisée de jetons pour des scénarios d’emprunt d’identité. Le type d’autorisation jwt-bearer facilite les échanges de jetons dans les scénarios On-Behalf Of, permettant des modèles de délégation. Les autorisations refresh_token permettent des opérations en arrière-plan avec le contexte utilisateur, prenant en charge des processus de longue durée qui conservent l’autorisation de l’utilisateur.

Identité de l’agent

Les identités d’agent utilisent client_credentials pour les opérations autonomes uniquement pour l’application, permettant un fonctionnement indépendant sans contexte utilisateur, ainsi que l’emprunt de l’identité d’un agent utilisateur. Le type d’autorisation jwt-bearer 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. Les autorisations refresh_token facilitent les opérations en arrière-plan déléguées par l’utilisateur, permettant aux identités d’agent de maintenir le contexte 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 agents ne sont pas pris en charge pour les flux interactifs (/authorize), ce qui garantit que toutes les authentifications se produisent par programmation.
  • Les fonctionnalités des clients publics ne sont pas disponibles, ce qui oblige tous les agents à fonctionner en tant que clients confidentiels.
  • Un URI de redirection web peut être configuré sur un blueprint pour les flux de consentement uniquement (response_type=none), mais ne peut pas être utilisé pour l’acquisition de jetons interactifs. La fonctionnalité d’URI de redirection complète est configurée sur l’application cliente.

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 On-Behalf-Of classique.
  • 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 pour les agents :

Diagramme présentant le flux OAuth pour les agents.

  • 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 de compte utilisateur de l’agent : agents qui opèrent pour leur propre compte à l’aide de principaux d’utilisateur créés spécifiquement pour eux.

Contenu connexe

  • Last updated on