OAuth chega ao AWS MCP Server
A AWS anunciou suporte a OAuth no AWS MCP Server, abrindo um caminho mais simples e seguro para conectar agentes de Inteligência Artificial às ferramentas e serviços da plataforma. A novidade permite que desenvolvedores autorizem o acesso de agentes usando os mesmos métodos de autenticação já conhecidos — seja pelo Console AWS ou pela Interface de Linha de Comando AWS (AWS CLI) — por meio de um fluxo baseado em navegador e amparado pelo padrão OAuth.
O novo fluxo de autenticação é compatível com federação do Gerenciamento de Identidade e Acesso AWS (IAM), AWS IAM Identity Center e usuários root ou IAM convencionais. Junto com essa integração, a AWS também disponibilizou um conjunto de ferramentas de segurança e governança, incluindo:
- Novas chaves de condição globais para OAuth
- Introspecção e revogação de tokens
- Registro dinâmico de clientes (DCR)
- Novos elementos no AWS CloudTrail
- Nova API para conectividade OAuth sem interface (headless)
Tudo isso é compatível com a configuração IAM existente — permissões, roles, acesso federado — sem exigir mudanças estruturais.
Como conectar um agente ao AWS MCP Server
O passo a passo descrito pela AWS utiliza o Claude Code como exemplo, mas o mesmo processo se aplica a qualquer agente compatível com o Protocolo de Contexto de Modelo (MCP), como Kiro, Codex e Gemini. A documentação completa de configuração está disponível em Configurando o AWS MCP Server.
Permissões necessárias
Para conectar um agente ao AWS MCP Server, é preciso ter as permissões IAM necessárias para o fluxo OAuth. O comando abaixo adiciona uma política gerenciada com as permissões exigidas à role IAM desejada (substitua <MyRole> pelo nome da sua role):
aws iam attach-role-policy \
--role-name <MyRole> \
--policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy
Passo 1: Configurar o AWS MCP Server no agente
Execute o comando abaixo para adicionar o endpoint do AWS MCP Server à configuração do agente:
claude mcp add --transport http aws-mcp https://aws-mcp.us-east-1.api.aws/mcp
Passo 2: Revisar a solicitação de autorização
Na primeira vez que o agente precisar acessar o AWS MCP Server, um navegador será aberto e o usuário será redirecionado para a página de autenticação do AWS Sign-In. Basta autenticar normalmente — como no console ou na CLI —, revisar a solicitação de autorização e aprovar o acesso. Uma mensagem de confirmação será exibida ao final.

Vale destacar que, se já houver uma sessão ativa no AWS Sign-In (por exemplo, porque o usuário se autenticou no console mais cedo), ela pode ser reutilizada sem necessidade de novo login.
Passo 3: Começar a usar as ferramentas AWS
Após a conexão, é possível verificar se o agente está devidamente conectado ao AWS MCP Server executando o comando /mcp dentro do Claude Code. O comando lista os servidores MCP configurados e confirma o status da conexão.
Com a conexão estabelecida, o agente já pode invocar as ferramentas disponíveis no servidor. Por exemplo, ao enviar o prompt:
Deploy a sample serverless web application into my development AWS account
O Claude Code utiliza o AWS MCP Server para identificar a conta AWS ativa, confirmar a conta de destino e descrever o que será implantado antes de acionar qualquer serviço.
Modelos de autorização disponíveis
O AWS Sign-In suporta dois modelos de autorização para conectar agentes ao AWS MCP Server:
- Autorização interativa: voltada para agentes de IA usados por desenvolvedores, com autenticação via navegador.
- Autorização não-interativa (headless): para aplicações e agentes que já possuem credenciais AWS e não têm acesso a um navegador.
Um ponto importante: autorizar um agente permite que ele acesse o AWS MCP Server em nome do usuário, mas não concede permissões AWS adicionais. Cada requisição ainda é avaliada pelas políticas IAM existentes, SCPs, RCPs, limites de permissão e demais controles organizacionais.
Acesso interativo
No fluxo interativo, o agente primeiro descobre o servidor OAuth do AWS Sign-In e se registra como cliente OAuth via Registro Dinâmico de Cliente (DCR). Em seguida, o usuário é redirecionado para autenticação e autorização. Após a aprovação, o AWS Sign-In emite tokens de acesso de curta duração e tokens de atualização. O gerenciamento automático desses tokens permite que o agente continue operando sem que o usuário precise se autenticar repetidamente.
Esse modelo suporta três métodos de autenticação: credenciais IAM nativas para desenvolvedores individuais, acesso gerenciado via AWS IAM Identity Center para empresas, e acesso federado por provedores terceiros como Okta e Ping Identity para organizações maiores.
Metadados OAuth e DCR
Antes de solicitar autorização, o agente precisa descobrir os endpoints OAuth do AWS Sign-In e se registrar como cliente. O AWS Sign-In suporta descoberta de metadados OAuth e DCR, permitindo que agentes compatíveis se configurem automaticamente — sem que desenvolvedores precisem provisionar manualmente IDs e segredos de cliente OAuth.
Quando um agente se conecta ao AWS MCP Server pela primeira vez, ele recupera os metadados do recurso protegido (RFC 9728) e os metadados OAuth do AWS Sign-In (RFC 8414). Em seguida, usa a RFC 7591 para se registrar, obter um client ID e iniciar o fluxo padrão de código de autorização OAuth. A lista de agentes e ambientes suportados está disponível em URIs de redirecionamento suportados para o AWS MCP Server.
Acesso não-interativo (headless)
Para agentes e aplicações que operam sem navegador ou interação humana, o AWS Sign-In oferece o fluxo de credenciais de cliente OAuth. Aplicações que já possuem credenciais AWS podem obter tokens de acesso OAuth diretamente. Veja um exemplo de como obter um token de acesso:
aws signin create-oauth2-token-with-iam \
--grant-type client_credentials \
--resource aws-mcp.amazonaws.com \
--region us-east-1
{
"accessToken": "ASOA****************************************...",
"tokenType": "Bearer",
"expiresIn": 3600
}
Nesse modelo, a autenticação no endpoint de token do AWS Sign-In é feita com credenciais SigV4, e o retorno é um token OAuth de curta duração. Pode ser necessário atualizar o SDK e a AWS CLI — consulte o guia da CLI para mais detalhes.
Gerenciando o acesso OAuth
O AWS Sign-In estende o modelo de autorização IAM com controles específicos para OAuth. Administradores podem combinar políticas IAM convencionais com novas condições voltadas para OAuth.
Concedendo permissões OAuth
O acesso OAuth é controlado via políticas IAM e requer duas ações específicas:
signin:AuthorizeOAuth2Access— permite autenticação interativa pelo fluxo de código de autorização OAuthsignin:CreateOAuth2Token— permite que aplicações obtenham tokens OAuth trocando códigos de autorização, tokens de atualização ou usando credenciais de cliente
Quando uma aplicação solicita acesso, o AWS Sign-In cria uma concessão de autorização OAuth entre o agente e o AWS MCP Server. Essa concessão é representada como um recurso IAM:
arn:aws:signin:us-east-1:012345678910:service-principal/aws-mcp.amazonaws.com
Governança do acesso OAuth
O AWS Sign-In introduz chaves de condição específicas para OAuth, permitindo controle granular sobre como os agentes obtêm autorização. A seguir, dois exemplos de padrões comuns de governança.
Restringir OAuth ao localhost: a política abaixo permite apenas os fluxos de código de autorização e token de atualização para o AWS MCP Server, e restringe a entrega de tokens ao localhost:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"signin:AuthorizeOAuth2Access",
"signin:CreateOAuth2Token"
],
"Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com",
"Condition": {
"StringLike": {
"signin:OAuthRedirectUri": "http://localhost:*"
},
"StringEquals": {
"signin:OAuthGrantType": [
"authorization_code",
"refresh_token"
]
}
}
}
]
}
Negar acesso para uma sessão OAuth específica: use a chave de condição global aws:SignInSessionArn para bloquear uma sessão suspeita ou comprometida sem afetar outras sessões ativas:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:SignInSessionArn": "arn:aws:signin:us-east-1:111122223333:session/abc123-example-session-id"
}
}
}
]
}
Exemplos adicionais de políticas IAM e SCP estão disponíveis na referência de chaves de condição do AWS Sign-In.
Revogando tokens OAuth
O AWS Sign-In oferece APIs de introspecção e revogação de tokens, permitindo que administradores construam ferramentas personalizadas para validação e revogação. O acesso a essas APIs é controlado pelas permissões signin:IntrospectOAuth2Token e signin:RevokeOAuth2Token.
A API de introspecção verifica se um token está ativo e retorna informações sobre a autorização associada. Já a API de revogação permite invalidar tokens de atualização individuais sem afetar outras sessões ativas — útil quando é preciso revogar o acesso de uma autorização específica sem impactar o restante da organização.
Monitorando a atividade OAuth com CloudTrail
Todas as atividades relacionadas ao OAuth são registradas no AWS CloudTrail, incluindo solicitações de autorização, emissão de tokens, revogações e eventos de introspecção. Os logs capturam detalhes como o cliente OAuth, o AWS MCP Server de destino, a URI de redirecionamento, o fluxo de autorização e a sessão de autenticação associada.
Além disso, chamadas de API feitas com tokens de acesso OAuth incluem o contexto aws:SignInSessionArn, permitindo correlacionar a atividade de API com a sessão OAuth de origem. Isso facilita o monitoramento, a investigação de comportamentos anômalos e a integração com fluxos de auditoria, conformidade e resposta a incidentes.
Abaixo, um exemplo de evento AuthorizeOAuth2Access no CloudTrail:
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATJHQDX737YZP****:testuser",
"arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser",
"accountId": "111111111111",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA2IRT4N5U4RDHM2LG4",
"arn": "arn:aws:iam::111111111111:role/Admin",
"accountId": "111111111111",
"userName": "Admin"
},
"attributes": {
"creationDate": "2026-06-09T05:06:39Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2026-06-09T05:09:00Z",
"eventSource": "signin.amazonaws.com",
"eventName": "AuthorizeOAuth2Access",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.0.2",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36",
"requestParameters": {
"resource": "https://aws-mcp.us-west-2.api.aws/mcp",
"redirect_uri": "http://127.0.0.1:60432/oauth/callback",
"code_challenge_method": "S256",
"client_id": "arn:aws:signin:us-west-2::external-client/dcr/609544da-aasa-49a4-ab11-c2r457fa999"
},
"responseElements": null,
"additionalEventData": {
"success": "true"
},
"requestID": "4fb4ff7b-6yu7-9090-78i9-9c0088a65134",
"eventID": "bb05b222-31ec-4237-b8e7-8eb26d4fd48b",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111111111111",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-west-2.oauth.signin.aws"
}
}
E um exemplo de evento CreateOAuth2Token:
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATJHQDX737YZP7****:testuser",
"arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser",
"accountId": "111111111111",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA2IRT4N5U4RDHM****",
"arn": "arn:aws:iam::111111111111:role/Admin",
"accountId": "111111111111",
"userName": "Admin"
},
"attributes": {
"creationDate": "2026-06-09T05:06:39Z",
"mfaAuthenticated": "false"
},
"signInSessionArn":""
}
},
"eventTime": "2026-06-09T05:10:04Z",
"eventSource": "signin.amazonaws.com",
"eventName": "CreateOAuth2Token",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.0.2",
"userAgent": "curl/8.7.1",
"requestParameters": {
"resource": "https://aws-mcp.us-west-2.api.aws/mcp",
"client_id": "arn:aws:signin:us-west-2::external-client/dcr/609544da-b3dd-49a4-ab11-c2e98d7fa999"
},
"responseElements": null,
"additionalEventData": {
"signInSessionArn": "arn:aws:signin:us-west-2:111111111111:session/daff060f-7871-5tg6-67yu-a07bbdabe61a",
"grant_type": "refresh_token",
"success": "true"
},
"requestID": "44d6d7ce-e4r5-4cbf-0909-bfb8a8295a76",
"eventID": "f79cc63f-b383-4e3c-a1e5-97c7db1ab833",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111111111111",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-west-2.oauth.signin.aws"
}
}
Detalhes adicionais sobre eventos de auditoria para chamadas feitas via tokens OAuth ao AWS MCP Server estão documentados em Registrando chamadas de API do AWS MCP Server com o AWS CloudTrail.
Conclusão
O suporte a OAuth no AWS Sign-In representa um avanço importante para quem trabalha com agentes de IA integrados à AWS. A novidade simplifica a conexão de aplicações e agentes à plataforma, mantendo toda a estrutura de IAM, governança e auditoria já existente. Para aprofundar o conhecimento, a AWS disponibiliza a documentação de Autenticação com OAuth 2.0 no Guia do Usuário do AWS Sign-In e o guia de Configuração do AWS MCP Server no Guia do Usuário do Agent Toolkit para AWS.
Fonte
Introducing OAuth Support for AWS MCP Server (https://aws.amazon.com/blogs/security/introducing-oauth-support-for-aws-mcp-server/)
Leave a Reply