Modèles d'authentification pris en charge
AgentCore Identity prend en charge deux modèles d'authentification principaux qui répondent à différents cas d'utilisation des agents. La compréhension de ces modèles vous aidera à choisir la bonne approche pour la mise en œuvre de votre agent spécifique.
Pour des exemples détaillés de la façon dont ces modèles s'appliquent à des secteurs d'activité et à des types d'agents spécifiques, voir Exemples de cas d'utilisation.
Rubriques
User-delegated accès (octroi du code d'autorisation OAuth 2.0)
Le flux d'octroi du code d'autorisation OAuth 2.0 permet aux agents d'accéder aux données spécifiques à l'utilisateur avec le consentement explicite de l'utilisateur. Ce modèle est essentiel lorsque les agents ont besoin d'accéder à des données personnelles ou d'effectuer des actions pour le compte d'utilisateurs spécifiques. Le flux comprend une étape de consentement de l'utilisateur au cours de laquelle le propriétaire de la ressource (utilisateur) autorise explicitement l'agent à accéder à ses données dans des limites spécifiques.
Principales caractéristiques
-
Nécessite le consentement explicite de l'utilisateur par le biais d'une invite d'autorisation
-
Permet d'accéder à des données et à des ressources spécifiques à l'utilisateur
-
Maintient une séparation claire entre l'identité de l'agent et l'autorisation de l'utilisateur
-
Supporte des étendues précises qui limitent les données auxquelles l'agent peut accéder
Exemple de scénario : un agent de productivité doit accéder à l'agenda Google d'un utilisateur pour planifier des réunions, à Gmail pour envoyer des e-mails et à Google Drive pour stocker des documents. L'agent utilise le code d'autorisation OAuth 2.0 pour obtenir le consentement de l'utilisateur pour chaque service, avec des étendues spécifiques qui limitent l'accès aux seules données nécessaires. L'utilisateur autorise explicitement l'agent via l'écran de consentement de Google, et AgentCore Identity stocke en toute sécurité les informations d'identification obtenues pour une utilisation future.
Ce modèle est idéal pour les agents assistants personnels, les agents du service client et pour tous les scénarios dans lesquels les agents ont besoin d'accéder à des données spécifiques à l'utilisateur via plusieurs services. Pour des exemples détaillés spécifiques à un secteur d'activité, voir Agents assistants personnels et Agents du service client.
Machine-to-machine authentification (octroi des informations d'identification du client OAuth 2.0)
Le flux d'octroi des informations d'identification du client OAuth 2.0 permet une authentification directe entre les systèmes sans interaction de l'utilisateur. Ce modèle est approprié lorsque les agents ont besoin d'accéder à des ressources qui ne sont pas spécifiques à l'utilisateur ou lorsqu'ils agissent eux-mêmes avec le consentement préautorisé de l'utilisateur.
Principales caractéristiques
-
Aucune interaction ou consentement de l'utilisateur requis
-
L'agent s'authentifie directement auprès des serveurs de ressources à l'aide de ses propres informations d'identification
-
Convient aux processus d'arrière-plan, aux tâches planifiées et aux opérations au niveau du système
-
Les autorisations sont définies au niveau de l'agent plutôt que par utilisateur
Exemple de scénario — Un agent de traitement des données d'entreprise doit collecter des données provenant de plusieurs systèmes internes, les traiter et stocker les résultats dans un entrepôt de données. L'agent utilise les informations d'identification du client OAuth 2.0 pour s'authentifier directement auprès de chaque système en utilisant sa propre identité et des autorisations préconfigurées. Aucune interaction avec l'utilisateur n'est requise, et l'agent peut agir lorsque les agents agissent eux-mêmes avec le consentement préautorisé de l'utilisateur à des intervalles réguliers.
Ce modèle est idéal pour les agents d'automatisation d'entreprise, les flux de travail de traitement des données et DevOps l'automatisation. Pour des exemples détaillés spécifiques au secteur, voir Agents d'automatisation d'entreprise, Agents de traitement et d'analyse des données, et Développement et DevOps agents.
On-behalf-of échange de jetons (échange de jetons OAuth 2.0)
On-behalf-of L'échange de jetons (OBO) permet aux agents d'accéder aux serveurs de ressources en aval pour le compte d'un utilisateur déjà authentifié. L'agent échange le jeton utilisateur entrant contre un nouveau jeton d'accès adapté au public par l'intermédiaire d'un fournisseur d'informations d'identification sortant, liant à la fois l'identité de l'utilisateur et celle de l'agent au jeton obtenu. Les services en aval peuvent ensuite prendre des décisions d'autorisation en fonction des deux identités, sans que l'utilisateur n'ait à passer par un autre flux de consentement.
Principales caractéristiques
-
Aucun consentement supplémentaire de l'utilisateur : le jeton utilisateur entrant est échangé directement contre un jeton d'accès en aval
-
Propage à la fois l'identité de l'utilisateur et celle de l'agent (ou de la charge de travail) sur plusieurs sauts, donnant à chaque service en aval le contexte nécessaire pour prendre ses propres décisions d'autorisation
-
Supporte l'échange de jetons standard (RFC 8693
) ou l'octroi d'autorisation JWT (RFC 7523 ), selon le fournisseur d'identité
Exemple de scénario : accès à une application métier par utilisateur — Une entreprise dispose d'une application RH interne qui applique le contrôle d'accès par utilisateur — chaque employé ne peut voir que ses propres données de rémunération et d'avantages sociaux. L'entreprise souhaite permettre aux employés d'interroger cette application par le biais d'un agent d'intelligence artificielle, sans assouplir les politiques d'accès existantes.
-
Mike (administrateur des identités) configure l'application RH en tant que fournisseur d'informations d'identification OAuth dans AgentCore Identity, y compris le mode d'échange de jetons OBO. Une fois configuré, aucun provisionnement par utilisateur n'est nécessaire : tout employé capable de s'authentifier auprès de l'agent peut accéder à l'application RH par le biais de celui-ci.
-
Bob (agent développeur) ajoute un outil qui appelle l'application RH. Il n'écrit aucune logique d'échange de jetons et ne gère pas les secrets des clients. Il appelle
GetResourceOauth2Tokenavec le jeton d'accès à la charge de travail, et AgentCore Identity renvoie un jeton délimité en aval. Bob se concentre sur ce que l'agent fait avec les données, et non sur la manière dont elles sont autorisées. -
Sarah (utilisateur final) se connecte à l'agent et lui demande de récupérer le résumé de ses avantages. Elle n'est pas invitée à se connecter une deuxième fois. Dans les coulisses, AgentCore Identity échange le jeton entrant de Sarah contre un jeton d'accès en aval portant son identité. L'application RH applique ses politiques d'accès existantes et ne renvoie que les données de Sarah, les mêmes données qu'elle verrait si elle accédait directement à l'application.
Ce modèle est idéal pour les agents d'entreprise qui utilisent plusieurs services sensibles à l'identité dans un seul domaine de confiance. Pour en savoir plus sur les types de subventions, la configuration et les fournisseurs d'identité pris en charge, consultez la section échange de On-behalf-of jetons.
Choisir le bon modèle d'authentification
Lors de la conception de votre stratégie d'authentification des agents, tenez compte des facteurs suivants pour déterminer le modèle le plus approprié :
| Factor | User-delegated accès (octroi du code d'autorisation OAuth 2.0) | Machine-to-machine authentification (octroi des informations d'identification du client OAuth 2.0) | On-behalf-of échange de jetons (échange de jetons OAuth 2.0) |
|---|---|---|---|
|
Propriété des données |
User-specific données (e-mails, documents, calendriers personnels) |
Données appartenant au système ou à l'organisation (analyses, journaux, ressources partagées) |
User-specific données, où l'utilisateur est déjà authentifié auprès de l'agent |
|
Interaction avec l'utilisateur |
L'utilisateur est présent et peut donner son consentement |
Aucune interaction utilisateur requise ou disponible |
L'utilisateur est déjà authentifié auprès de l'agent ; aucune nouvelle demande de consentement |
|
Chronologie de l'opération |
Opérations interactives en temps réel |
Opérations en arrière-plan, planifiées ou par lots |
Opérations interactives en temps réel initiées par un utilisateur authentifié |
|
Étendue de l'autorisation |
Les autorisations varient en fonction de l'utilisateur et de ses choix en matière de consentement |
Autorisations cohérentes définies au niveau de l'agent |
Autorisations dérivées du jeton utilisateur entrant et de la politique du fournisseur en aval |
De nombreuses implémentations d'agents nécessiteront tous les modèles pour différents aspects de leurs fonctionnalités. Par exemple, un agent du service client peut utiliser l'accès délégué par l'utilisateur pour récupérer les données d'un client spécifique tout en utilisant l'authentification machine à machine pour accéder aux bases de connaissances et aux systèmes internes de l'entreprise. Le même agent peut également utiliser l'échange de jetons au nom de l'utilisateur pour propager l'identité de l'utilisateur aux services en aval qui appliquent l'autorisation par utilisateur, sans le demander à nouveau à l'utilisateur. AgentCore Identity prend en charge tous les modèles simultanément, ce qui permet aux agents d'utiliser le mécanisme d'authentification le plus approprié pour chaque ressource à laquelle ils doivent accéder.
Tous les modèles d'authentification bénéficient des fonctionnalités de base d' AgentCore Identity :
-
Stockage sécurisé des informations d'identification sans exposer les secrets au code de l'agent
-
Interfaces d'authentification cohérentes pour plusieurs types de ressources
-
Journalisation complète des audits pour la sécurité et la conformité
-
Fine-grained contrôles d'accès basés sur l'identité et le contexte
-
Intégration simplifiée via le AgentCore SDK
