O que mudou no AgentCore Identity
A AWS anunciou que o Amazon Bedrock AgentCore Identity agora suporta autenticação de cliente via Token Web JSON (JWT) de Chave Privada — o chamado Private Key JWT. Essa novidade muda a forma como agentes de IA se autenticam perante provedores de identidade externos, eliminando a necessidade de compartilhar segredos OAuth 2.0.
Em vez de depender de um segredo de cliente compartilhado, o agente apresenta uma asserção JWT assinada digitalmente. A chave pública fica registrada no provedor de identidade, enquanto a chave privada correspondente permanece protegida dentro do AWS Key Management Service (KMS). O próprio AgentCore Identity solicita ao KMS que assine a asserção — sem que a chave privada precise sair do serviço em nenhum momento.
Como o fluxo de autenticação funciona
Para entender a mecânica, considere um agente de suporte ao cliente que precisa consultar o histórico de pedidos de um usuário em uma API interna protegida por um provedor de identidade. O fluxo acontece assim:
- O agente chama
GetResourceOauth2Tokenno AgentCore Identity para solicitar um token de acesso à API de pedidos. - O AgentCore Identity lê o ID do cliente, o ARN da chave KMS e o algoritmo de assinatura configurados no provedor de credenciais.
- O serviço monta uma asserção JWT de curta duração com os atributos (claims) necessários e chama
kms:Signusando o algoritmo configurado — RS256, PS256 ou ES256. - O KMS assina a asserção e devolve apenas a assinatura. A chave privada nunca sai do KMS.
- O AgentCore Identity envia a asserção assinada ao endpoint de token do provedor de identidade com
grant_type=client_credentialseclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer. - O provedor de identidade verifica a assinatura usando a chave pública registrada e retorna um token de acesso.
- O agente usa esse token para chamar a API de pedidos e receber os dados do cliente.
Fluxos de concessão suportados
A autenticação via Private Key JWT funciona com três modelos de fluxo OAuth diferentes, cobrindo os principais cenários de uso de agentes em produção.
Máquina para máquina (M2M)
Neste modelo, o agente age por conta própria, sem representar nenhum usuário humano. É o caso de jobs em background que sincronizam dados ou serviços que qualquer instância do agente pode acessar independentemente de quem o acionou. O token representa a identidade da aplicação ou do agente. Utiliza o fluxo client_credentials e o subject do token é o próprio cliente.
Em nome de um usuário (On-Behalf-Of — OBO)
Aqui, o agente age em nome de um usuário específico que já está autenticado. Existe um token de entrada do usuário, e o AgentCore Identity o troca por um token downstream que representa esse usuário — mantendo as permissões e a identidade dele na cadeia de chamadas. Dependendo do provedor de identidade, é possível usar a troca de token do RFC 8693 ou a concessão de autorização JWT do RFC 7523.
Acesso delegado pelo usuário
Neste cenário, não há token de entrada para trocar. O usuário passa por um fluxo interativo de login e consentimento — o fluxo de código de autorização OAuth de três pernas — aprovando explicitamente o que o agente pode fazer. Após o consentimento, o agente recebe um token que representa o usuário. Utiliza o fluxo authorization_code.
Pré-requisitos
Para seguir a configuração, a AWS indica que você precisa de:
- Uma conta AWS com acesso ao Console de Gerenciamento para o KMS, o AgentCore e o AWS CloudTrail.
- Um tenant no seu provedor de identidade onde seja possível registrar uma chave pública para uma aplicação.
- URL de descoberta e ID de cliente do provedor de identidade.
- Confirmação do algoritmo de assinatura exigido pelo provedor e verificação de que ele é suportado pelo KMS e pelo AgentCore Identity.
- Permissões IAM:
kms:CreateKeyekms:PutKeyPolicypara criar a chave;kms:GetPublicKeypara exportar a chave pública;bedrock-agentcore-control:CreateOauth2CredentialProviderpara criar o provedor de credenciais. Se o provedor de identidade gerar o par de chaves e fornecer o material da chave privada, também serão necessáriaskms:GetParametersForImportekms:ImportKeyMaterialpara importar a chave no KMS.
Passo a passo: configurando o Private Key JWT
Passo 1 — Criar a chave de assinatura no KMS e registrar a chave pública
O primeiro passo é criar uma chave KMS assimétrica que o AgentCore Identity usará para assinar as asserções JWT. Abra o console do AWS KMS na mesma região AWS do seu provedor de credenciais. Em Customer managed keys, escolha Create key e configure:
- Key type: Asymmetric
- Key usage: Sign and verify
- Key spec: compatível com o algoritmo de assinatura desejado (o exemplo da AWS usa
ECC_NIST_P256com o algoritmo ES256)
Na etapa de política da chave, adicione o seguinte statement para conceder ao AgentCore Identity permissão de uso — substituindo 111122223333 pelo ID da sua conta AWS e <region> pela região em uso. A condição kms:ViaService garante que a chave só pode ser usada quando a requisição vier do AgentCore Identity:
{
"Id": "BedrockAgentCoreIdentityPrivateKeyJwtAccess",
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"kms:Sign",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
},
"StringLike": {
"kms:ViaService": "bedrock-agentcore-identity.<region>.amazonaws.com"
}
}
}
]
}Após criar a chave, anote o ARN — ele será necessário na configuração do provedor de credenciais. Em seguida, acesse a aba Public key da chave e faça o download da chave pública. O KMS fornece a chave em formato DER. Converta-a para o formato exigido pelo seu provedor de identidade (por exemplo, um certificado X.509 para o Microsoft Entra ID ou uma JSON Web Key para o Okta) e registre-a na sua aplicação.
Passo 2 — Adicionar um cliente OAuth no AgentCore Identity
Abra o console do Amazon Bedrock AgentCore. No painel de navegação esquerdo, em Build, acesse Identity. Na seção Outbound Auth, escolha Add Outbound Auth e depois Add OAuth client.
Passo 3 — Selecionar Private Key JWT como método de autenticação
Na página de adição do cliente OAuth, na seção Provider configurations, configure o Configuration type como Discovery URL para que o AgentCore Identity recupere automaticamente a configuração do provedor. Em Client authentication method, selecione Private key JWT.
Passo 4 — Informar URL de descoberta, ID do cliente, chave KMS e algoritmo
- Discovery URL: a URL onde o provedor publica sua configuração OpenID Connect (terminando em
.well-known/openid-configuration). - Client ID: o identificador do cliente registrado no provedor de identidade.
- KMS key: o ARN da chave KMS assimétrica criada anteriormente. A chave deve ter sido criada com uso
SIGN_VERIFYe estar na mesma região. Também é possível usar uma chave de outra conta na mesma região informando o ARN diretamente — nesse caso, são necessárias permissões adicionais em ambas as contas. Veja a documentação sobre como permitir que usuários de outras contas usem uma chave KMS. - Signing algorithm: o algoritmo exigido pelo seu provedor de identidade, compatível com o key spec da chave KMS.
Passo 5 — (Opcional) Adicionar claims customizados
Se o seu provedor de identidade exigir claims adicionais na asserção JWT, é possível adicioná-los nesta etapa. Em Header claims, adicione claims de cabeçalho específicos do provedor (como um identificador de chave). As chaves reservadas alg e typ não podem ser definidas. Em Payload claims, adicione claims de payload específicos do provedor. As chaves reservadas iss, sub, jti, exp, iat e nbf não podem ser definidas. Por fim, clique em Add OAuth Client e confirme que o provedor de credenciais aparece na lista de Outbound Auth.
Auditoria com CloudTrail
Toda vez que um agente usa o provedor de credenciais para buscar um token, as operações ficam registradas no AWS CloudTrail. Os principais eventos que você verá são:
GetWorkloadAccessToken (fonte: bedrock-agentcore.amazonaws.com) — o agente obtém seu token de identidade de workload. O token retornado é ocultado por razões de segurança:
{
"eventSource": "bedrock-agentcore.amazonaws.com",
"eventName": "GetWorkloadAccessToken",
"requestParameters": {
"workloadName": "my-agent-workload"
},
"responseElements": {
"workloadAccessToken": "HIDDEN_DUE_TO_SECURITY_REASONS"
},
"resources": [
{
"accountId": "111122223333",
"type": "AWS::BedrockAgentCore::WorkloadIdentity",
"ARN": "arn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default/workload-identity/my-agent-workload"
}
]
}GetResourceOauth2Token (fonte: bedrock-agentcore.amazonaws.com) — o agente solicita um token de acesso para o recurso downstream. Os parâmetros mostram qual provedor de credenciais, escopos e fluxo OAuth foram usados:
{
"eventSource": "bedrock-agentcore.amazonaws.com",
"eventName": "GetResourceOauth2Token",
"requestParameters": {
"workloadIdentityToken": "HIDDEN_DUE_TO_SECURITY_REASONS",
"resourceCredentialProviderName": "my-private-key-jwt-provider",
"scopes": [
"https://graph.microsoft.com/.default"
],
"oauth2Flow": "M2M"
},
"resources": [
{
"accountId": "111122223333",
"type": "AWS::BedrockAgentCore::OAuth2CredentialProvider",
"ARN": "arn:aws:bedrock-agentcore:us-east-1:111122223333:token-vault/default/oauth2credentialprovider/my-private-key-jwt-provider"
}
]
}Sign (fonte: kms.amazonaws.com) — o AgentCore Identity assina a asserção JWT com a chave KMS. Este é o evento que comprova o funcionamento do Private Key JWT: os campos userIdentity.invokedBy, sourceIPAddress e userAgent são todos bedrock-agentcore.amazonaws.com, confirmando que foi o AgentCore Identity quem chamou o kms:Sign. Note que o evento registra o nome do algoritmo de assinatura do KMS, não o nome do algoritmo JWT configurado:
{
"eventSource": "kms.amazonaws.com",
"eventName": "Sign",
"userIdentity": {
"invokedBy": "bedrock-agentcore.amazonaws.com"
},
"sourceIPAddress": "bedrock-agentcore.amazonaws.com",
"userAgent": "bedrock-agentcore.amazonaws.com",
"requestParameters": {
"signingAlgorithm": "RSASSA_PKCS1_V1_5_SHA_256",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"messageType": "DIGEST"
},
"responseElements": null,
"readOnly": true,
"managementEvent": true,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
]
}Limpando os recursos criados
Para evitar cobranças desnecessárias e remover recursos que não serão mais usados, a AWS recomenda os seguintes passos:
Remover o provedor de credenciais OAuth
Abra o console do Amazon Bedrock AgentCore, acesse Identity no painel de navegação e localize o provedor criado na seção Outbound Auth. Selecione o provedor, escolha Delete e confirme a exclusão.
Agendar a exclusão da chave KMS
A exclusão de uma chave KMS é irreversível. Por isso, o KMS exige que você agende a exclusão com um período de espera em vez de excluir imediatamente. Antes de agendar, confirme que a chave não está mais referenciada por nenhum provedor de credenciais ou registro de provedor de identidade. Se não tiver certeza se a chave ainda está em uso, considere desativar a chave — o que impede seu uso mas mantém a possibilidade de recuperação.
Abra o console do AWS KMS na região onde a chave foi criada. Em Customer managed keys, selecione a chave assimétrica criada. Em Key actions, escolha Schedule key deletion e defina um período de espera entre 7 e 30 dias. Durante esse período, a chave fica desativada mas pode ser recuperada cancelando a exclusão agendada. Após o período, o KMS a exclui permanentemente. Lembre-se também de remover ou rotacionar a chave pública registrada no provedor de identidade.
Conclusão
Com o suporte a Private Key JWT no AgentCore Identity, a AWS oferece aos desenvolvedores uma forma sem segredos compartilhados e totalmente auditável de autenticar agentes em provedores de identidade externos. A chave privada permanece no KMS, cada operação de assinatura fica registrada no CloudTrail, e o mesmo provedor de credenciais cobre os fluxos M2M, on-behalf-of e de acesso delegado pelo usuário.
Para exemplos completos — incluindo registro em provedores como Entra e Okta, além de fluxos M2M e OBO — a AWS disponibilizou os samples do Amazon Bedrock AgentCore no GitHub.
Fonte
Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity (https://aws.amazon.com/blogs/machine-learning/authenticate-with-private-key-jwt-using-amazon-bedrock-agentcore-identity/)
Leave a Reply