View a markdown version of this page

Padrões de autenticação compatíveis - Base da Amazônia AgentCore

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Padrões de autenticação compatíveis

AgentCore O Identity oferece suporte a dois padrões de autenticação primários que abordam diferentes casos de uso de agentes. Entender esses padrões ajudará você a escolher a abordagem certa para a implementação específica de seu agente.

Para exemplos detalhados de como esses padrões se aplicam a setores e tipos de agentes específicos, consulte Exemplos de casos de uso.

User-delegated acesso (concessão do código de autorização OAuth 2.0)

O fluxo de concessão do código de autorização do OAuth 2.0 permite que os agentes acessem dados específicos do usuário com o consentimento explícito do usuário. Esse padrão é essencial quando os agentes precisam acessar dados pessoais ou realizar ações em nome de usuários específicos. O fluxo inclui uma etapa de consentimento do usuário em que o proprietário do recurso (usuário) autoriza explicitamente o agente a acessar seus dados dentro de escopos específicos.

Características principais

  • Requer o consentimento explícito do usuário por meio de uma solicitação de autorização

  • Fornece acesso a dados e recursos específicos do usuário

  • Mantém uma separação clara entre a identidade do agente e a autorização do usuário

  • Suporta escopos refinados que limitam quais dados o agente pode acessar

Exemplo de cenário: um agente de produtividade precisa acessar o Google Agenda de um usuário para agendar reuniões, o Gmail para enviar e-mails e o Google Drive para armazenar documentos. O agente usa a concessão do código de autorização OAuth 2.0 para obter o consentimento do usuário para cada serviço, com escopos específicos que limitam o acesso somente aos dados necessários. O usuário autoriza explicitamente o agente por meio da tela de consentimento do Google, e o AgentCore Identity armazena com segurança as credenciais resultantes para uso futuro.

Esse padrão é ideal para agentes assistentes pessoais, agentes de atendimento ao cliente e qualquer cenário em que os agentes precisem acessar dados específicos do usuário em vários serviços. Para exemplos detalhados específicos do setor, consulte Agentes assistentes pessoais e agentes de atendimento ao cliente.

Machine-to-machine autenticação (concessão de credenciais do cliente OAuth 2.0)

O fluxo de concessão de credenciais do cliente OAuth 2.0 permite a autenticação direta entre sistemas sem a interação do usuário. Esse padrão é apropriado quando os agentes precisam acessar recursos que não são específicos do usuário ou quando os agentes agem sozinhos com o consentimento pré-autorizado do usuário.

Características principais

  • Nenhuma interação ou consentimento do usuário é necessário

  • O agente se autentica diretamente com servidores de recursos usando suas próprias credenciais

  • Adequado para processos em segundo plano, tarefas agendadas e operações em nível de sistema

  • As permissões são definidas no nível do agente e não por usuário

Cenário de exemplo: um agente de processamento de dados corporativo precisa coletar dados de vários sistemas internos, processá-los e armazenar os resultados em um data warehouse. O agente usa a concessão de credenciais do cliente OAuth 2.0 para se autenticar diretamente em cada sistema usando sua própria identidade e permissões pré-configuradas. Nenhuma interação do usuário é necessária, e o agente pode operar quando os agentes agem sozinhos com o consentimento pré-autorizado do usuário em intervalos programados.

Esse padrão é ideal para agentes de automação corporativa, fluxos de trabalho de processamento de dados e DevOps automação. Para exemplos detalhados específicos do setor, consulte Agentes de automação corporativa, Agentes de processamento e análise de dados e Agentes de desenvolvimento. DevOps

On-behalf-of troca de tokens (troca de tokens OAuth 2.0)

On-behalf-of A troca de tokens (OBO) permite que os agentes acessem servidores de recursos downstream em nome de um usuário já autenticado. O agente troca o token do usuário de entrada por um novo token de acesso com escopo de público por meio de um provedor de credenciais de saída, vinculando a identidade do usuário e a identidade do agente ao token resultante. Os serviços downstream podem então tomar decisões de autorização com base nas duas identidades, sem exigir que o usuário passe por outro fluxo de consentimento.

Características principais

  • Sem consentimento adicional do usuário — o token do usuário de entrada é trocado diretamente por um token de acesso downstream

  • Propaga a identidade do usuário e a identidade do agente (ou da carga de trabalho) em vários saltos, dando a cada serviço downstream o contexto para tomar suas próprias decisões de autorização

  • Suporta troca de token padrão (RFC 8693) ou concessão de autorização JWT (RFC 7523), dependendo do provedor de identidade

Cenário de exemplo: Acessando um aplicativo de negócios por usuário — Uma empresa tem um aplicativo interno de RH que impõe o controle de acesso por usuário — cada funcionário só pode ver seus próprios dados de remuneração e benefícios. A empresa quer permitir que os funcionários consultem esse aplicativo por meio de um agente de IA, sem relaxar nenhuma das políticas de acesso existentes.

  1. Mike (administrador de identidade) configura o aplicativo de RH como um provedor de credenciais OAuth no AgentCore Identity, incluindo o modo de troca de tokens OBO. Depois de configurado, nenhum provisionamento por usuário é necessário — qualquer funcionário que possa se autenticar no agente pode acessar o aplicativo de RH por meio dele.

  2. Bob (agente desenvolvedor) adiciona uma ferramenta que chama o aplicativo de RH. Ele não escreve nenhuma lógica de troca de tokens nem lida com segredos de clientes. Ele liga GetResourceOauth2Token com o token de acesso à carga de trabalho e o AgentCore Identity retorna um token downstream com escopo definido. Bob se concentra no que o agente faz com os dados, não em como eles são autorizados.

  3. Sarah (usuária final) entra no agente e pede que ele retire seu resumo de benefícios. Ela não é solicitada a fazer login pela segunda vez. Nos bastidores, a AgentCore Identity troca o token de entrada de Sarah por um token de acesso downstream que carrega sua identidade. O aplicativo de RH aplica suas políticas de acesso existentes e retorna somente os dados de Sarah — os mesmos dados que ela veria se acessasse o aplicativo diretamente.

Esse padrão é ideal para agentes corporativos que percorrem vários serviços com reconhecimento de identidade em um único domínio de confiança. Para saber mais sobre os tipos de concessão, a configuração e os provedores de identidade suportados, consulte troca de On-behalf-of tokens.

Escolhendo o padrão de autenticação correto

Ao criar sua estratégia de autenticação de agente, considere esses fatores para determinar qual padrão é mais apropriado:

Factor User-delegated acesso (concessão do código de autorização OAuth 2.0) Machine-to-machine autenticação (concessão de credenciais do cliente OAuth 2.0) On-behalf-of troca de tokens (troca de tokens OAuth 2.0)

Propriedade dos dados

User-specific dados (e-mails, documentos, calendários pessoais)

Dados de propriedade do sistema ou da organização (análises, registros, recursos compartilhados)

User-specific dados, em que o usuário já está autenticado no agente

Interação do usuário

O usuário está presente e pode fornecer consentimento

Nenhuma interação do usuário é necessária ou está disponível

O usuário já está autenticado no agente; nenhuma nova solicitação de consentimento

Tempo de operação

Operações interativas e em tempo real

Operações em segundo plano, programadas ou em lote

Operações interativas e em tempo real iniciadas por um usuário autenticado

Escopo de permissões

As permissões variam de acordo com o usuário e suas opções de consentimento

Permissões consistentes definidas no nível do agente

Permissões derivadas do token de usuário de entrada e da política do provedor downstream

Muitas implementações de agentes exigirão todos os padrões para diferentes aspectos de sua funcionalidade. Por exemplo, um agente de atendimento ao cliente pode usar o acesso delegado pelo usuário para recuperar os dados de um cliente específico enquanto usa a autenticação máquina a máquina para acessar as bases de conhecimento e os sistemas internos da empresa. O mesmo agente também pode usar a troca de tokens em nome da troca de tokens para propagar a identidade do usuário para serviços posteriores que impõem autorização por usuário, sem solicitar ao usuário novamente. AgentCore O Identity suporta todos os padrões simultaneamente, permitindo que os agentes usem o mecanismo de autenticação mais apropriado para cada recurso que precisam acessar.

Todos os padrões de autenticação se beneficiam dos principais recursos do AgentCore Identity:

  • Armazenamento seguro de credenciais sem expor segredos ao código do agente

  • Interfaces de autenticação consistentes em vários tipos de recursos

  • Registro de auditoria abrangente para segurança e conformidade

  • Fine-grained controles de acesso baseados em identidade e contexto

  • Integração simplificada por meio do AgentCore SDK