Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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 spécifique de votre agent.
Pour des exemples détaillés de la manière dont ces modèles s'appliquent à des secteurs 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 à des données spécifiques à l'utilisateur avec le consentement explicite de l'utilisateur. Ce modèle est essentiel lorsque les agents doivent accéder à des données personnelles ou 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 au calendrier Google d'un utilisateur pour planifier des réunions, à son compte Gmail pour envoyer des e-mails et à son compte 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 qui en résultent pour une utilisation future.
Ce modèle est idéal pour les assistants personnels, les agents du service client et tous les scénarios dans lesquels les agents ont besoin d'accéder à des données spécifiques à l'utilisateur sur plusieurs services. Pour des exemples détaillés spécifiques à un secteur d'activité, consultez les sections 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 doivent accéder à des ressources qui ne sont pas spécifiques à l'utilisateur ou lorsque les agents agissent eux-mêmes avec le consentement préautorisé de l'utilisateur.
Principales caractéristiques
-
Aucune interaction ou consentement de l'utilisateur n'est requis
-
L'agent s'authentifie directement auprès des serveurs de ressources à l'aide de ses propres informations d'identification
-
Convient aux processus en 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 ses autorisations préconfigurées. Aucune interaction de l'utilisateur n'est requise et l'agent peut fonctionner lorsque les agents agissent eux-mêmes avec le consentement préautorisé de l'utilisateur à des intervalles planifiés.
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 à un secteur, consultez les rubriques Agents d'automatisation d'entreprise, Agents de traitement et d'analyse des Agents de traitement et d'analyse des données données et DevOps Agents de développement.
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 d'utilisateur entrant contre un nouveau jeton d'accès destiné 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 dans le jeton obtenu. Les services en aval peuvent ensuite prendre des décisions d'autorisation sur la base des deux identités, sans que l'utilisateur ait à passer par un autre flux de consentement.
Principales caractéristiques
-
Aucun consentement supplémentaire de l'utilisateur : le jeton d'utilisateur entrant est échangé directement contre un jeton d'accès en aval
-
Propage à la fois l'identité de l'utilisateur et l'identité 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 via un agent d'IA, sans assouplir les politiques d'accès existantes.
-
Mike (administrateur d'identité) configure l'application HR 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é pouvant s'authentifier auprès de l'agent peut accéder à l'application RH via celui-ci.
-
Bob (développeur d'agents) 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 en aval délimité. Bob se concentre sur ce que l'agent fait avec les données, et non sur la manière dont il est autorisé. -
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 qui porte 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 d'autorisations, 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 |
|
Calendrier des opérations |
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 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 les différents aspects de leurs fonctionnalités. Par exemple, un agent du service client peut utiliser un 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. 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 ont besoin d'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 de 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 grâce au AgentCore SDK
