Autenticar e autorizar com Autenticação de Entrada e Autenticação de Saída
Esta seção mostra como implementar autenticação e autorização para o tempo de execução do seu agente usando tokens portadores OAuth e JWT com Identity. AgentCore Você aprenderá a configurar grupos de usuários do Cognito, configurar o tempo de execução do agente para autenticação JWT (Autenticação de Entrada) e implementar o OAuth-based acesso a recursos de terceiros (Autenticação de saída).
Para obter um exemplo completo, consultehttps://github.com/awslabs/amazon-bedrock-agentcore-samples/
Para obter informações sobre como usar o OAuth com um servidor MCP, consulte Implantar servidores MCP no Runtime. AgentCore
O tempo de AgentCore execução do Amazon Bedrock fornece dois mecanismos de autenticação para agentes hospedados:
- Autenticação IAM SigV4
-
O mecanismo padrão de autenticação e autorização que funciona automaticamente sem configuração adicional, semelhante a outras AWS APIs.
X-Amzn-Bedrock-AgentCore-Runtime-User-Id Cabeçalho
Se sua solução exigir que o agente hospedado recupere tokens OAuth em nome dos usuários finais (usando Authorization Code Grant), você poderá especificar o identificador do usuário incluindo o
X-Amzn-Bedrock-AgentCore-Runtime-User-Idcabeçalho em suas solicitações. Esse cabeçalho usa oGetWorkloadAccessTokenForUserIdcaminho internamente.nota
A invocação InvokeAgentRuntime com o
X-Amzn-Bedrock-AgentCore-Runtime-User-Id headerexigirá uma nova ação do IAM:bedrock-agentcore:InvokeAgentRuntimeForUser, além dabedrock-agentcore:InvokeAgentRuntimeação existente.Quando usar esse cabeçalho versus a autenticação do JWT Bearer Token
Esse cabeçalho foi projetado para os seguintes casos de uso:
-
Clientes corporativos com identificadores de usuário gerenciados pelo cliente — Organizações que mantêm suas próprias cadeias de caracteres de identidade de usuário e precisam passá-las à AgentCore Identity para vinculação de credenciais.
-
Cenários de desenvolvimento e início rápido — criadores que ainda não têm um token de IdP disponível e precisam de um caminho rápido para testar fluxos de credenciais com escopo de usuário.
Para implantações de produção em que você tem um provedor de identidade configurado, use a autenticação JWT Bearer Token em vez disso. O JWT path (
GetWorkloadAccessTokenForJWT) valida o emissor, a assinatura e a expiração do token, fornecendo prova criptográfica da identidade do usuário. O caminho doX-Amzn-Bedrock-AgentCore-Runtime-User-Idcabeçalho não verifica o ID do usuário em relação a uma identidade autenticada do usuário final. Ele depende da carga de trabalho de chamada para transmitir o valor correto e de suas políticas do IAM para restringir quem pode fornecê-lo.Melhores práticas de segurança para X-Amzn-Bedrock-AgentCore-Runtime-User-Id cabeçalho
dica
Para obter uma visão consolidada de todas as recomendações de segurança do Runtime, consulte Melhores práticas de segurança para o AgentCore Runtime.
Como AgentCore trata o valor do cabeçalho como um identificador opaco sem verificá-lo em relação a uma identidade autenticada, você deve aplicar os seguintes controles para manter o limite de segurança:
-
Restrinja a permissão do IAM — Somente diretores confiáveis devem ter a
bedrock-agentcore:InvokeAgentRuntimeForUserpermissão. Defina essa permissão para recursos de tempo de execução específicos usando condições de recursos do IAM. Não o conceda amplamente por meio de políticas gerenciadas ou declarações de recursos curingas. -
Derive o ID do usuário do principal autenticado — O valor do ID do usuário deve ser derivado do contexto do principal autenticado (por exemplo, identidade do chamador do IAM ou declarações de token do usuário) em vez de aceitar valores arbitrários fornecidos pelo cliente. Isso impede que um usuário autenticado se faça passar por outro usuário especificando manualmente um diferente.
user-id -
Implemente o registro de auditoria — registre a relação entre o principal autenticado do IAM (do contexto SigV4) e o
user-idvalor que está sendo passado. Use AWS CloudTrail para monitorarInvokeAgentRuntimechamadas que incluem oruntimeUserIdparâmetro. -
Negue o cabeçalho em contextos não confiáveis — Para tempos de execução em que a delegação de ID de usuário não é necessária, negue explicitamente a
bedrock-agentcore:InvokeAgentRuntimeForUseração nas políticas do IAM para evitar que o cabeçalho seja aceito:{ "Statement": [ { "Sid": "DenyUserIdDelegation", "Effect": "Deny", "Action": "bedrock-agentcore:InvokeAgentRuntimeForUser", "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*" } ] }
-
- Autenticação de token JWT Bearer
-
Você pode configurar o tempo de execução do agente para aceitar tokens portadores do JWT fornecendo a configuração do autorizador durante a criação do agente.
Essa configuração inclui:
-
URL de descoberta - Uma string que deve corresponder ao padrão dos URLs
^.+/\.well-known/openid-configuration$de descoberta do OpenID Connect -
Públicos permitidos - Uma lista de públicos permitidos que serão validados em relação à reivindicação de auxílio no token JWT
-
Clientes permitidos - Uma lista de identificadores de clientes permitidos que serão validados em relação à declaração client_id no token JWT
-
Escopos permitidos - Uma lista de escopos permitidos que serão validados em relação à declaração de escopo no token JWT. O campo de
allowedScopesautorização será configurado como uma lista de sequências de caracteres. -
Declarações personalizadas obrigatórias - Uma lista das reivindicações obrigatórias que serão validadas em relação ao nome e valor da declaração contidos no token JWT recebido. Para obter detalhes sobre a configuração do autorizador, consulte Configurar o autorizador JWT de entrada
-
nota
Um AgentCore Runtime pode suportar a autenticação de entrada baseada em IAM SigV4 ou JWT Bearer Token, mas não ambas simultaneamente. Você sempre pode criar versões diferentes do seu AgentCore Runtime e configurá-las para diferentes tipos de autorização de entrada. Quando você cria um tempo de execução com o Amazon Bedrock AgentCore, uma identidade de carga de trabalho é criada automaticamente para seu tempo de execução com o serviço AgentCore Identity.
Tópicos
Restrinja a invocação de entrada do IAM (SigV4) ao seu gateway
Exemplo de autorização de entrada JWT e acesso de saída OAuth
Etapa 2: configurar AWS Grupo de usuários do Cognito e adição de um usuário
Etapa 3 (opcional): inicie seu tempo de execução com um AgentCore gateway
Etapa 6: configurar seu agente para acessar as ferramentas usando o OAuth
Etapa 7: (opcional) propagar um token JWT para o Runtime AgentCore
Restrinja a invocação de entrada do IAM (SigV4) ao seu gateway
Você pode usar um AgentCore gateway em seu AgentCore Runtime para que o gateway se torne o único ponto de entrada controlado para o tempo de execução, oferecendo autorização baseada em políticas, Amazon Bedrock Guardrails, interceptores de solicitações e respostas e observabilidade unificada, tudo aplicado fora do próprio ambiente do agente. Para obter a justificativa completa e como configurar isso, consulte Enfrente seu tempo de execução com um AgentCore gateway.
Mas isso só é útil se os chamadores não conseguirem acessar o tempo de execução diretamente ignorando o gateway. Se seu tempo de execução usa a autorização de entrada padrão do IAM (SigV4), você pode restringir a invocação ao gateway para que o tráfego chegue ao tempo de execução somente por meio dele. Para conseguir isso, anexe uma política baseada em recursos ao tempo de execução que restringe a invocação à função de execução do seu gateway. O gateway assume sua função de serviço para assinar solicitações no tempo de execução, portanto, a função de gateway é a principal que invoca o tempo de execução. Permita essa função e adicione um explícito Deny para cada outro principal para que nenhuma outra identidade possa invocar o tempo de execução, mesmo com uma política permissiva baseada em identidade. Para obter mais informações sobre políticas baseadas em recursos em tempos de execução, consulte as políticas do Amazon Resource-based Bedrock. AgentCore
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOnlyGatewayRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/MyGatewayExecutionRole" }, "Action": "bedrock-agentcore:InvokeAgentRuntime", "Resource": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID" }, { "Sid": "DenyOtherPrincipals", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "bedrock-agentcore:InvokeAgentRuntime", "Resource": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::111122223333:role/MyGatewayExecutionRole" } } } ] }
dica
Um explícito Deny sempre substitui qualquer políticaAllow, inclusive com base em identidade, na mesma conta. Ao digitar “Denyon”, você aws:PrincipalArn garante que somente a função de execução do gateway possa invocar o tempo de execução, independentemente de quais outras permissões existam em sua conta.
Importante
Restringir o tempo de execução à função de execução do gateway é tão forte quanto os controles sobre quem pode assumir essa função. Qualquer principal que possa assumir a função de execução do gateway pode invocar o tempo de execução como se fosse o gateway. Bloqueie a função adicionando aws:SourceArn aws:SourceAccount condições à política de confiança da função de execução do gateway para que somente seu gateway possa assumi-la. A orientação de prevenção do Confused Deputy mostra a mesma técnica aplicada à função de execução de um tempo de execução; aplique o mesmo padrão aqui, mas defina a política de confiança na função de execução do gateway e no escopo aws:SourceArn do ARN do gateway.
Exemplo de autorização de entrada JWT e acesso de saída OAuth
Este guia mostra o processo de configuração do tempo de execução do agente para ser invocado com um token de acesso compatível com OAuth usando o formato JWT. O agente de amostra será autorizado usando tokens de acesso do AWS Cognito. Posteriormente, você também aprenderá como o código do agente pode buscar tokens do Google em nome do usuário para verificar o Google Drive e buscar conteúdo.
O que você aprenderá
Neste guia, você aprenderá como:
-
Configure o grupo de usuários do Cognito, adicione um usuário e obtenha um token de portador para o usuário
-
Configure o tempo de execução do seu agente para usar o grupo de usuários do Cognito para autorização
-
Configure seu código de agente para buscar tokens OAuth em nome do usuário para chamar ferramentas
Pré-requisitos
Antes de começar, você deve ter o seguinte:
-
Uma AWS conta com as permissões apropriadas
-
Compreensão básica da programação em Python
-
Familiaridade com contêineres Docker (para implantação avançada)
-
Configure um agente básico com tempo de execução bem-sucedido
-
A AWS CLI mais recente e instalada
jq -
Compreensão básica da autorização do OAuth, principalmente tokens portadores do JWT, reivindicações e os vários fluxos de concessão
Etapa 1: criar seu projeto de agente
Use o agentcore create comando para configurar um projeto de agente esqueleto com a estrutura de sua escolha:
agentcore create
O comando solicitará que você:
-
Escolha uma estrutura (escolha Strands Agents para este tutorial)
-
Forneça um nome de projeto
-
Configurar opções adicionais
Isso gera:
-
Código do agente com sua estrutura selecionada
-
Arquivo de configuração
agentcore/agentcore.json -
requirements.txtcom as dependências necessárias
nota
O código do agente gerado servirá como base para a implementação da autenticação OAuth nas etapas a seguir.
Etapa 2: configurar AWS Grupo de usuários do Cognito e adição de um usuário
Para configurar um grupo de usuários do Cognito e criar um usuário, você usará um script de shell que automatiza o processo.
Para obter mais informações, consulte Etapa 2: Importar módulos de identidade e autenticação.
Para configurar o grupo de usuários do Cognito e criar um usuário
-
Crie um arquivo chamado
setup_cognito.shcom o seguinte conteúdo:#!/bin/bash # Create User Pool and capture Pool ID directly export POOL_ID=$(aws cognito-idp create-user-pool \ --pool-name "MyUserPool" \ --policies '{"PasswordPolicy":{"MinimumLength":8}}' \ --region $REGION | jq -r '.UserPool.Id') # Create App Client and capture Client ID directly export CLIENT_ID=$(aws cognito-idp create-user-pool-client \ --user-pool-id $POOL_ID \ --client-name "MyClient" \ --no-generate-secret \ --explicit-auth-flows "ALLOW_USER_PASSWORD_AUTH" "ALLOW_REFRESH_TOKEN_AUTH" \ --region $REGION | jq -r '.UserPoolClient.ClientId') # Create User aws cognito-idp admin-create-user \ --user-pool-id $POOL_ID \ --username $USERNAME \ --region $REGION \ --message-action SUPPRESS > /dev/null # Set Permanent Password aws cognito-idp admin-set-user-password \ --user-pool-id $POOL_ID \ --username $USERNAME \ --password $PASSWORD \ --region $REGION \ --permanent > /dev/null # Authenticate User and capture Access Token export BEARER_TOKEN=$(aws cognito-idp initiate-auth \ --client-id "$CLIENT_ID" \ --auth-flow USER_PASSWORD_AUTH \ --auth-parameters USERNAME=$USERNAME,PASSWORD=$PASSWORD \ --region $REGION | jq -r '.AuthenticationResult.AccessToken') # Output the required values echo "Pool id: $POOL_ID" echo "Discovery URL: https://cognito-idp.$REGION.amazonaws.com/$POOL_ID/.well-known/openid-configuration" echo "Client ID: $CLIENT_ID" echo "Bearer Token: $BEARER_TOKEN"Abra uma janela de terminal e defina as seguintes variáveis de ambiente:
-
REGION— a AWS região que você deseja usar -
USERNAME— o nome de usuário do novo usuário -
PASSWORD— a senha do novo usuárioexport REGION=us-east-1 // set your desired Region export USERNAME=USER NAME export PASSWORD=PASSWORDNa janela do terminal, execute o script:
source setup_cognito.shObserve a saída do script. Você precisará desses valores nas próximas etapas.
-
Esse script cria um grupo de usuários do Cognito, um cliente de grupo de usuários, adiciona um usuário e gera um token de portador para o usuário. Por padrão, o token é válido por 60 minutos.
Etapa 3 (opcional): inicie seu tempo de execução com um AgentCore gateway
Você pode usar um AgentCore gateway em seu AgentCore Runtime para que o gateway se torne o único ponto de entrada controlado para o tempo de execução, oferecendo autorização baseada em políticas, Amazon Bedrock Guardrails, interceptores de solicitações e respostas e observabilidade unificada, tudo aplicado fora do próprio ambiente do agente. Para obter a justificativa completa e como configurar isso, consulte Enfrente seu tempo de execução com um AgentCore gateway.
Se você quiser encarar esse tempo de execução, crie o gateway agora, antes de implantá-lo na próxima etapa. Depois de implantar, você adicionará o tempo de execução como destino do gateway.
Para garantir que os chamadores não possam ignorar o gateway, restrinja o tempo de execução para aceitar invocações somente desse gateway. Você configura isso na próxima etapa, como parte do autorizador, usando allowedWorkloadConfiguration (consulte permitidoWorkloadConfiguration: restringir a invocação ao seu gateway).
Etapa 4: implantar seu agente
Importante
A partir de 13 de outubro de 2025, o Amazon Bedrock AgentCore usa uma Service-Linked função (SLR) para permissões de identidade de carga de trabalho em vez de exigir a configuração manual da política do IAM para novos agentes.
Os detalhes da Service-Linked função:
-
Nome:
AWSServiceRoleForBedrockAgentCoreRuntimeIdentity -
Diretor de serviço:
runtime-identity.bedrock-agentcore.amazonaws.com -
Objetivo: gerencia tokens de acesso à identidade da carga de trabalho e credenciais OAuth
Certifique-se de que a função que você usa para invocar as APIs de AgentCore controle tenha permissão para criar a Service-Linked função:
{ "Sid": "CreateBedrockAgentCoreIdentityServiceLinkedRolePermissions", "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/runtime-identity.bedrock-agentcore.amazonaws.com/AWSServiceRoleForBedrockAgentCoreRuntimeIdentity", "Condition": { "StringEquals": { "iam:AWSServiceName": "runtime-identity.bedrock-agentcore.amazonaws.com" } } }
Benefício: a Service-Linked função fornece automaticamente as permissões necessárias para o acesso à identidade da carga de trabalho sem exigir a configuração manual da política.
Para obter informações detalhadas sobre a função vinculada ao serviço, consulte Função vinculada ao serviço de identidade.
Agora, você implantará seu agente com autorização do JWT usando o grupo de usuários do Cognito que você criou. Você precisará criar um agente com a configuração do autorizador. A tabela a seguir representa os vários parâmetros de configuração do autorizador e como os usamos para validar o token de entrada.
| configuração_do_autorizador | reivindicação em token decodificado | Observações |
|---|---|---|
|
url de descoberta → emissor |
iss |
O URL de descoberta deve apontar para um URL do emissor. Isso deve corresponder à afirmação iss no token decodificado. |
|
Clientes permitidos |
client_id |
client_id no token deve corresponder a um dos clientes permitidos especificados no autorizador |
|
Público permitido |
aud |
Um dos valores na reivindicação de aud do token deve corresponder a um dos públicos permitidos especificados no autorizador |
|
permitido WorkloadConfiguration |
|
Opcional. No lançamento, usado para permitir que somente seu AgentCore Gateway invoque o tempo de execução. Consulte Restringir a invocação ao seu gateway. |
Se client_id e aud forem fornecidos, o autorizador de tempo de execução do agente verificará ambos.
permitidoWorkloadConfiguration: restrinja a invocação ao seu gateway
O allowedWorkloadConfiguration campo no customJWTAuthorizer restringe quais cargas de trabalho na cadeia de identidade da solicitação podem invocar o tempo de execução. Defina a carga de trabalho permitida em seu gateway para que o tempo de execução aceite uma solicitação somente quando sua cadeia de identidade incluir esse gateway. É assim que um tempo de execução do OAuth (JWT) impõe que o tráfego chegue somente pelo gateway que você configurou na Etapa 3.
Você fornece as cargas de trabalho permitidas usando um dos campos a seguir. Você pode especificar uma ou ambas — uma solicitação é aceita se sua cadeia de identidade corresponder a uma entrada em qualquer um dos campos, então você não precisa fornecer ambas.
-
HostingEnvironments — Uma lista de ambientes de hospedagem cujas cargas de trabalho podem invocar o destino. Cada entrada é um objeto com um
arn. No lançamento, o único ambiente de hospedagem compatível é o AgentCore Gateway, portanto, cada umarndeve ser um ARN do AgentCore Gateway. -
WorkloadIdentities — Uma lista de nomes de identidade de carga de trabalho que podem invocar o destino. O nome da identidade da carga de trabalho não é um ARN. É o segmento final do ARN de identidade da carga de trabalho do gateway, que você pode encontrar no campo
workloadIdentityDetailsdaGetGatewayresposta. Por exemplo, seworkloadIdentityDetails.workloadIdentityArnforarn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default/workload-identity/my-gateway-workload-identity, o nome da identidade da carga de trabalho serámy-gateway-workload-identity.
O exemplo a seguir cria um tempo de execução do agente que restringe a invocação a um AgentCore gateway específico por seu ARN. Especificar hostingEnvironments sozinho é a maneira mais simples de permitir um gateway:
{ "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_example/.well-known/openid-configuration", "allowedClients": ["your-client-id"], "allowedWorkloadConfiguration": { "hostingEnvironments": [ { "arn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway-id" } ] } } } }
Como alternativa, você pode identificar o gateway pelo nome de identidade da carga de trabalho ou especificar os dois campos. Quando ambos estão presentes, uma solicitação é permitida se corresponder a uma entrada em qualquer um dos campos. O allowedWorkloadConfiguration trecho a seguir permite dois gateways diferentes — um identificado pelo ARN e outro pelo nome da identidade da carga de trabalho:
"allowedWorkloadConfiguration": { "hostingEnvironments": [ { "arn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway-1-id" } ], "workloadIdentities": [ "my-gateway-2-workload-identity" ] }
nota
No lançamento, allowedWorkloadConfiguration é compatível somente com destinos de AgentCore tempo de execução, e as cargas de trabalho permitidas são AgentCore Gateways.
Crie e implante o tempo de execução do agente
Com a configuração do autorizador pronta, crie e implante o tempo de execução do agente. Os exemplos a seguir mostram como fazer isso com a AgentCore CLI ou o AWS SDK for Python (Boto3). Observe o ARN de tempo de execução do agente na saída — você precisará dele para invocar o agente na próxima etapa.
exemplo
Etapa 5: use o token do portador para invocar seu agente
Agora que seu agente foi implantado com autorização do JWT, você pode invocá-lo usando o token portador.
nota
Se você iniciou seu tempo de execução com um gateway na Etapa 3, adicione o tempo de execução implantado como um destino de gateway antes de invocar — consulte Destinos de tempo de AgentCore execução — e, em seguida, invoque por meio do endpoint do gateway mostrado nos exemplos a seguir, em vez do endpoint de tempo de execução.
Importante
Importante para os usuários existentes: os agentes criados antes de 13 de outubro de 2025 continuarão usando a função de execução do agente para obter permissões de identidade e exigirão que a política anterior seja anexada à função de execução do agente.
Novos agentes: para agentes criados em ou após 13 de outubro de 2025, essa política não é necessária, pois as permissões são gerenciadas automaticamente pela Service-Linked função.
{ "Sid": "GetAgentAccessToken", "Effect": "Allow", "Action": [ "bedrock-agentcore:GetWorkloadAccessToken", "bedrock-agentcore:GetWorkloadAccessTokenForJWT", "bedrock-agentcore:GetWorkloadAccessTokenForUserId" ], # point to the workload identity for the runtime; the workload identity can be found in # the GetAgentRuntime response and has your agent name in it. "Resource": [ "arn:aws:bedrock-agentcore:region:account-id:workload-identity-directory/default", "arn:aws:bedrock-agentcore:region:account-id:workload-identity-directory/default/workload-identity/agentname-*" ] }
Invocar o agente
Obtenha um token de portador para o usuário que você criou com o Amazon Cognito.
# use the password and other details used when you created the cognito user export TOKEN=$(aws cognito-idp initiate-auth \ --client-id "$CLIENT_ID" \ --auth-flow USER_PASSWORD_AUTH \ --auth-parameters USERNAME='testuser',PASSWORD='PASSWORD' \ --region us-east-1 | jq -r '.AuthenticationResult.AccessToken')
Prossiga com a invocação do agente com o restante das instruções a seguir.
Invoque o agente com o OAuth.
exemplo
Respostas de erro do OAuth
OAuth-configured os agentes seguem os padrões de autenticação RFC 6749 (OAuth 2.0
401 Não autorizado - Autenticação ausente
Quando nenhum token de portador é fornecido no cabeçalho de autorização, a resposta é:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{ESCAPED_ARN}/invocations/.well-known/oauth-protected-resource?qualifier={QUALIFIER}"
O resource_metadata URL no WWW-Authenticate cabeçalho aponta para a API de metadados de recursos protegidos (PRM). A API PRM permite que os clientes descubram quais servidores de autorização protegem esse agente e seus URLs de endpoint OAuth.
nota
Você deve pré-registrar seu cliente OAuth no Cognito (via Console AWS ou CLI) para obter um antes de usar os endpoints descobertos. client_id O Amazon Cognito não é compatível com o Registro Dinâmico de Clientes (RFC 7591).
Etapa 6: configurar seu agente para acessar as ferramentas usando o OAuth
Nesta seção, você aprenderá como conectar seu código de agente aos provedores de AgentCore credenciais para acesso seguro a recursos externos usando a autenticação OAuth2.
O exemplo a seguir demonstra como seu agente em execução no Agent Runtime pode solicitar o consentimento do OAuth dos usuários, permitindo que eles se autentiquem com a conta do Google e autorizem o agente a acessar o conteúdo do Google Drive.
Para obter mais informações sobre como configurar a identidade, consulte Introdução à AgentCore identidade.
Etapa 6.1: Configurar provedores de credenciais
Para configurar um provedor de credenciais do Google, você precisa:
-
Registre seu aplicativo no Google para obter o ID e o segredo do cliente
-
Crie um provedor de credenciais OAuth usando a CLI. AWS Substitua
your-client-ideyour-client-secretpor seu ID de cliente e segredo do cliente reais do Google OAuth2:OAUTH2_CREDENTIAL_PROVIDER_RESPONSE=$(aws bedrock-agentcore-control create-oauth2-credential-provider \ --name "google-provider" \ --credential-provider-vendor "GoogleOauth2" \ --oauth2-provider-config-input '{ "googleOauth2ProviderConfig": { "clientId": "your-client-id", "clientSecret": "your-client-secret" } }' \ --output json) OAUTH2_CALLBACK_URL=$(echo $OAUTH2_CREDENTIAL_PROVIDER_RESPONSE | jq -r '.callbackUrl') echo "OAuth2 Callback URL: $OAUTH2_CALLBACK_URL"nota
Obtenha o
callbackUrlda CreateOauth2CredentialProviderresposta e adicione o URI à lista de URI de redirecionamento do seu aplicativo do Google. O URL de retorno de chamada deve ser semelhante a: https://bedrock-agentcore.us-east-1.amazonaws.com/identities/oauth2/callback/ ********-****-****************
Certifique-se de que sua função de invocação tenha as permissões necessárias para acessar o provedor de credenciais.
Etapa 6.2: permitir que o agente leia o conteúdo do Google Drive
Crie uma ferramenta com anotações do SDK principal do agente, conforme mostrado no exemplo a seguir, para iniciar automaticamente o processo OAuth de três etapas. Quando seu agente invoca essa ferramenta, os usuários serão solicitados a abrir o URL de autorização no navegador e conceder consentimento para que o agente acesse o Google Drive.
import asyncio from bedrock_agentcore.identity.auth import requires_access_token, requires_api_key # This annotation helps agent developer to obtain access tokens from external applications @requires_access_token( provider_name="google-provider", scopes=["https://www.googleapis.com/auth/drive.metadata.readonly"], # Google OAuth2 scopes auth_flow="USER_FEDERATION", # 3LO flow on_auth_url=lambda x: print("Copy and paste this authorization url to your browser: ", x), # prints authorization URL to console force_authentication=True, callback_url='insert_oauth2_callback_url_for_session_binding' ) async def read_from_google_drive(*, access_token: str): print(access_token) #You can see the access_token # Make API calls... main(access_token) asyncio.run(read_from_google_drive(access_token=""))
nota
Para obter um exemplo de implementação de servidor de retorno de chamada local para lidar com a vinculação de sessão, consulte https://github.com/awslabs/amazon-bedrock-agentcore-samples/blob/main/01-tutorials/03-AgentCore-identity/05-Outbound_Auth_3lo/oauth2_callback_server.py
O que acontece nos bastidores
Quando esse código é executado, ocorre o seguinte processo:
-
O Agent Runtime autoriza o token de entrada de acordo com o autorizador configurado.
-
O Agent Runtime troca esse token por um token de acesso à carga de trabalho via
bedrock-agentcore:GetWorkloadAccessTokenForJWTAPI e o entrega ao código do seu agente por meio do cabeçalho da carga útil.WorkloadAccessToken -
Durante a invocação da ferramenta, seu agente usa esse token de acesso à carga de trabalho para chamar a API do Token Vault
bedrock-agentcore:GetResourceOauth2Tokene gerar uma URL de autenticação 3LO. -
Seu agente envia essa URL para o aplicativo cliente conforme especificado no
on_auth_urlmétodo. -
O aplicativo cliente apresenta esse URL ao usuário, que autoriza o agente a acessar o Google Drive.
-
AgentCore O serviço de identidade recebe e armazena em cache com segurança o token de acesso do Google até que ele expire, permitindo que solicitações subsequentes do usuário usem esse token sem precisar que o usuário forneça consentimento para cada solicitação.
nota
AgentCore O Identity Service armazena o token de acesso do Google no AgentCore Token Vault usando a identidade da carga de trabalho do agente e o ID do usuário (do token JWT de entrada, como o token Cognito) como chave vinculativa, eliminando solicitações de consentimento repetidas AWS até que o token do Google expire.
Etapa 7: (opcional) propagar um token JWT para o Runtime AgentCore
Opcionalmente, você pode passar um cabeçalho de autorização para um AgentCore Runtime para extrair declarações. Isso pode ser feito usando a configuração da lista de permissões do cabeçalho da solicitação. Para obter mais informações, consulte RequestHeaderConfiguration.
Etapa 7.1: Modifique o código do seu agente para ler os cabeçalhos
Nesta etapa, você faz alterações no código do seu agente para poder decodificar e extrair declarações de um token JWT usando a biblioteca PyJWT.
requirements.txt
Adicione a dependência do PyJWT ao requirements.txt arquivo em seu projeto gerado.
PyJWT
Atualize seu código de agente
Modifique o arquivo do agente principal em seu projeto gerado (normalmente src/main.py ou similar, dependendo da sua escolha de estrutura) conforme mostrado no código a seguir. Você pode pular a validação da assinatura do token aqui, pois ela já foi validada pelo AgentCore Runtime quando a autorização de entrada foi concluída.
import jwt import json .... @app.entrypoint def invoke(payload, context): auth_header = context.request_headers.get('Authorization') if not auth_header: return None # Remove "Bearer " prefix if present token = auth_header.replace('Bearer ', '') if auth_header.startswith('Bearer ') else auth_header try: # Skip signature validation as agent runtime has validated the token already. claims = jwt.decode(token, options={"verify_signature": False}) app.logger.info("Claims: %s", json.dumps(claims)) except jwt.InvalidTokenError as e: app.logger.exception("Invalid JWT token: %s", e) .....
Etapa 7.2: Criar o agente com a lista de permissões do cabeçalho da solicitação
Use a AgentCore CLI para configurar o agente com a lista de permissões do cabeçalho da solicitação. Navegue até o diretório do projeto gerado e execute:
agentcore create --name HelloAgent --framework Strands --model-provider Bedrock --memory none # Now deploy the agent runtime agentcore deploy
nota
A AgentCore CLI cria a estrutura do projeto e os arquivos de configuração. Ajuste a configuração do agente agentcore/agentcore.json conforme necessário para sua escolha de estrutura.
Etapa 7.3: Invoque seu agente
Invoque seu agente usando o OAuth e você deverá ver as reivindicações nos registros do seu agente em Logs. CloudWatch
Solução de problemas
Como depurar problemas relacionados ao token
Se você encontrar problemas com a autenticação do token, poderá decodificar o token para inspecionar seu conteúdo:
echo "$TOKEN" | cut -d '.' -f2 | tr '_-' '/+' | awk '{ l=4 - length($0)%4; if (l<4) printf "%s", $0; for (i=0; i<l; i++) printf "="; print "" }' | base64 -D | jq
Isso produzirá a carga útil do token, que é semelhante a:
{ "sub": "subid", "iss": "https://cognito-idp.us-east-1.amazonaws.com/userpoolid", "client_id": "clientid", "origin_jti": "originjti", "event_id": "eventid", "token_use": "access", "scope": "aws.cognito.signin.user.admin", "auth_time": 1752275688, "exp": 1752279288, "iat": 1752275688, "jti": "jti", "username": "username" }
Ao solucionar problemas de token, verifique o seguinte:
-
O URL do emissor apontado pelo URL de descoberta no agente autorizador deve corresponder à reivindicação do emissor no token. Faça o seguinte para confirmar se eles coincidem:
-
Selecione o URL de descoberta que você forneceu na configuração do autorizador ao criar o agente, por exemplo:
https://cognito-idp.us-east-1.amazonaws.com/us-east-1_nnnnnnnnn/.well-known/openid-configuration-
Verifique o URL do emissor -
"issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_12345566". Isso deve corresponder ao valor da declaração iss no token.
-
-
-
client_ida declaração no token deve corresponder a uma das entradas do autorizador AllowedClients, se fornecida-
Anote o ID do cliente que você forneceu ao criar o agente
-
Confirme se isso corresponde à declaração client_id no token decodificado
-
-
auda reivindicação no token deve corresponder a uma dasallowedAudienceentradas do autorizador, se fornecida-
Anote a lista de públicos que você forneceu quando criou o agente
-
Confirme se isso corresponde à
audafirmação no token decodificado
-
-
Os tokens são válidos apenas por alguns minutos (a expiração padrão do Amazon Cognito é de 60 minutos). Obtenha um novo token conforme necessário.