Padrões de autenticação compatíveis
AgentCore O Identity oferece suporte a dois padrões de autenticação principais que tratam de casos de uso de agentes diferentes. A compreensão desses 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.
Tópicos
User-delegated acesso (concessão do código de autorização do 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 os dados que o agente pode acessar
Cenário de exemplo: 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ária
-
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 com o usuário é necessária, e o agente pode operar quando os próprios agentes agem 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 obter exemplos detalhados específicos do setor, consulte Agentes de automação corporativa, Agentes de processamento e análise de dados e Agentes de desenvolvimento e. 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 tanto a identidade do usuário quanto a identidade do agente ao token resultante. Os serviços downstream podem então tomar decisões de autorização com base em ambas as 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 posterior
-
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: acessar um aplicativo comercial 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.
-
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.
-
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
GetResourceOauth2Tokencom 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 ele é autorizado. -
Sarah (usuária final) entra no agente e pede que ele extraia seu resumo dos benefícios. Ela não é solicitada a se inscrever pela segunda vez. Nos bastidores, AgentCore Identity troca o token de entrada de Sarah por um token de acesso posterior 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 utilizam 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 compatíveis, consulte troca de On-behalf-of tokens.
Escolhendo o padrão de autenticação correto
Ao criar sua estratégia de autenticação de agentes, considere esses fatores para determinar qual padrão é o mais apropriado:
| Factor | User-delegated acesso (concessão do código de autorização do 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 de 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 com o usuário |
O usuário está presente e pode fornecer consentimento |
Nenhuma interação com o 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 em tempo real |
Operações em segundo plano, programadas ou em lote |
Operações interativas 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 do 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 do usuário para propagar a identidade do usuário para serviços posteriores que impõem autorização por usuário, sem avisar o usuário novamente. AgentCore O Identity suporta todos os padrões simultaneamente, permitindo que os agentes usem o mecanismo de autenticação mais adequado 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 com base na identidade e no contexto
-
Integração simplificada por meio do AgentCore SDK