# Amazon Bedrock rattache les consentements OAuth aux utilisateurs

> Amazon Bedrock AgentCore propose un portail géré pour authentifier les utilisateurs et associer leurs consentements OAuth aux agents et services connectés.

Type : Actualité IA · Catégorie : Outils · Publié le 2026-09-18 · Signal IA - Order & Chaos · Secteur : Cybersécurité
Source : https://www.orderchaos.eu/signal-ia/actu/amazon-bedrock-agentcore-automatise-les-consentements-oauth
Tags : amazon bedrock, agents ia, oauth, sécurité, mcp

---

## En résumé

- Amazon Bedrock AgentCore fournit un portail géré pour le consentement OAuth des utilisateurs.
- Le portail associe chaque autorisation aux utilisateurs et conserve les jetons dans un coffre dédié.
- Les agents peuvent connecter séparément GitHub et Slack avant leurs appels depuis un IDE ou un client MCP.

**Le signal :** Amazon Bedrock AgentCore automatise désormais le portail de consentement OAuth et le rattachement des jetons à chaque utilisateur.

**Amazon Bedrock AgentCore** propose désormais un portail géré pour le consentement OAuth des agents. Cette fonctionnalité associe chaque autorisation à l’utilisateur qui l’a accordée. Elle concerne les agents qui accèdent à GitHub, Slack ou d’autres services au nom d’une personne. Avant toute action, l’utilisateur s’authentifie auprès du fournisseur et approuve les accès demandés. AgentCore Identity conserve ensuite les jetons dans son coffre de jetons. La fonctionnalité est disponible avec Amazon Bedrock AgentCore Identity et AgentCore Gateway. Elle cible notamment les agents utilisés depuis des environnements de développement intégrés et des clients MCP. AWS présente le parcours avec un assistant logiciel de développement comme exemple.

**Une infrastructure auparavant requise** devait être développée et hébergée par les clients utilisant un flux d’autorisation par code. Elle comprenait l’affichage de l’URL d’autorisation, un rappel HTTPS public et l’authentification de l’utilisateur de retour. L’application devait aussi gérer les sessions du navigateur et appeler CompleteResourceTokenAuth. Le portail de consentement regroupe désormais l’expérience web et le point de terminaison de liaison de session pour AgentCore Gateway. L’administrateur crée un portail pour une passerelle, puis partage son URL. L’utilisateur se connecte avec le fournisseur d’identité de l’organisation, consulte les services proposés et accorde séparément les autorisations nécessaires. [Voir la présentation AWS](https://aws.amazon.com/blogs/machine-learning/manage-end-user-oauth-consent-for-ai-agents-with-amazon-bedrock-agentcore/).

## Le portail relie utilisateurs et passerelles

**Example Corp** configure un assistant de développement avec deux cibles AgentCore Gateway. La première cible GitHub peut lister les dépôts et créer des problèmes. La seconde cible Slack peut lister les canaux publics et publier des messages. L’entreprise utilise son fournisseur d’identité interne pour authentifier ses employés. Chaque autorisation OAuth GitHub ou Slack reste associée à l’employé qui l’a approuvée. Les développeurs peuvent connecter les deux fournisseurs indépendamment, puis retourner dans leur environnement de développement sans nouvelle demande pour une connexion déjà établie. L’exemple prévoit un client IDE ou MCP configuré avec la même passerelle que celle rattachée au portail de consentement.

**La configuration administrateur** exige un compte AWS accessible à Amazon Bedrock AgentCore et une passerelle configurée avec une autorisation entrante JWT. L’organisation doit disposer d’un fournisseur d’identité administrable, d’une application OAuth GitHub et d’une application Slack pour un environnement de développement ou de test. Elle doit aussi pouvoir enregistrer l’URL de rappel d’AgentCore Identity auprès de chaque fournisseur. L’administrateur crée une application web OpenID Connect, active le flux d’autorisation par code et conserve son identifiant client avec son secret. Il crée ensuite un fournisseur OAuth2 dans AgentCore Identity. Les secrets GitHub et Slack sont stockés dans AWS Secrets Manager. [Documentation GitHub](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app) et [documentation Slack](https://docs.slack.dev/authentication/installing-with-oauth/).

## Les connexions restent indépendantes

**Le portail actif** affiche une URL suivant le modèle `https://<gateway-name>.consent-portal.bedrock-agentcore.<region>.amazonaws.com`. L’administrateur remplace alors le rappel temporaire du fournisseur d’identité par l’URL du portail suivie de /callback. Il définit aussi /connect/callback comme URL de retour par défaut pour chaque cible utilisant le flux d’autorisation par code. Les applications GitHub et Slack conservent, elles, l’URL de rappel unique fournie par AgentCore Identity. Après connexion, l’utilisateur ouvre le portail, s’authentifie auprès de l’identité d’entreprise et consulte l’état des cibles. Il sélectionne Connect pour GitHub, examine les portées, puis approuve l’accès.

**Le parcours utilisateur** montre que GitHub peut apparaître comme connecté tandis que Slack reste non connecté. L’utilisateur peut ensuite connecter Slack séparément, choisir un espace de travail et approuver les permissions demandées. Il retourne enfin dans son IDE ou son client MCP, puis relance l’appel d’outil concerné par la même passerelle AgentCore Gateway. Les appels suivants peuvent utiliser le jeton déjà conservé pour cet utilisateur. Le portail utilise son rôle d’exécution IAM pour découvrir les cibles configurées de la passerelle et présenter leurs connexions. AWS indique également que l’activité obtenue peut être examinée dans AWS CloudTrail après le parcours de configuration.
Pour aller plus loin, consultez notre guide sur [déployer un agent IA en PME sans développeur](/signal-ia/guides/agents-ia-pme-sans-developpeur-2026).
