As muitas faces do OAuth 2.0 Token Exchange

• Um mecanismo padronizado para converter um token de segurança em outro, definido como uma extensão do OAuth 2.0 na RFC 8693
• Transforma o servidor de autorização em um Security Token Service (STS), validando o token enviado pelo cliente e emitindo um novo token adequado a outro contexto, destino (audience) ou finalidade
• O funcionamento se divide principalmente em dois modos: Impersonation e Delegation
• Cada caso de uso — como impersonação administrativa, transição de protocolo, encadeamento de serviços e identidade federada — traz seus próprios trade-offs e impactos de segurança
• Com a expansão dos agentes de IA, tarefas que atravessam vários serviços e provedores passam a ser, em essência, cadeias de delegação, aumentando ainda mais a importância da troca de tokens

---

O que é Token Exchange

• O cliente envia um subject_token (token que representa o usuário/entidade que é o sujeito da requisição) e, opcionalmente, também um actor_token (a parte que executa a troca), recebendo em retorno um novo token adequado ao contexto de destino
• Repassar o token existente como está ou simplesmente criar um novo token do zero pode parecer intuitivo, mas ambos causam problemas sérios; essa especificação foi criada para resolver isso

• Dois modos básicos de operação

  • Impersonation: a parte que faz a requisição recebe um token indistinguível do do sujeito original; os serviços downstream não conseguem diferenciar se é o usuário real ou uma parte se passando por ele
  • Delegation: preserva as identidades dos dois sujeitos; por meio da claim act (actor) incluída no novo token, o serviço downstream consegue reconhecer tanto o usuário quanto quem está agindo em nome dele
  • A impersonação é poderosa, mas opaca; a delegação tem restrições, mas é auditável — essa escolha determina a postura de segurança e a capacidade de rastreamento

Impersonação administrativa (Administrative Impersonation)

• Situação em que um engenheiro de suporte precisa ver exatamente a mesma tela do cliente, com os mesmos privilégios e acesso aos mesmos dados, para diagnosticar um problema como informações incorretas exibidas em um dashboard
• O administrador troca seu próprio token por um token que representa a identidade do cliente; como o token resultante inclui a claim sub, os escopos e o audience do cliente, a aplicação passa a enxergar a requisição como se tivesse sido enviada pelo próprio cliente
• Nesse caso, a requisição usa apenas o subject_token (o usuário a ser impersonado) e não fornece actor_token — porque o objetivo é uma impersonação completa

• O problema da perda de trilha de auditoria

  • Como se trata de impersonação real, perde-se a trilha de auditoria sobre quem de fato executou a ação
  • Por isso, é indispensável combinar esse modelo com um mecanismo externo de logging que registre quem, quando e por qual motivo iniciou a troca; caso contrário, a solução de problemas pode abrir uma brecha de segurança

Gerenciando a transição de protocolo (Managing Protocol Transition)

• Cenário em que sistemas legados e protocolos antigos ainda existem, e é preciso operar dois ambientes em paralelo durante uma migração de autenticação SAML para OpenID Connect (OIDC)
• Um serviço que autentica usuários com SAML troca a assertion SAML por um token de acesso OAuth 2.0; o servidor de autorização valida o artefato SAML recebido e emite um token de acesso padrão que os serviços downstream conseguem entender

• Parâmetro subject_token_type

  • Identifica o formato do token recebido; a RFC 8693 define vários identificadores de tipo de token
    • Assertion SAML 2.0: urn:ietf:params:oauth:token-type:saml2
    • Token JWT: urn:ietf:params:oauth:token-type:jwt
  • Isso permite que o servidor de autorização aceite tokens de diferentes famílias de protocolo e os normalize em um formato consistente para serviços modernos
• É um padrão que aparece quando duas organizações com stacks de identidade diferentes, por exemplo após fusões e aquisições, precisam interoperar antes de concluir uma migração completa; o usuário continua se autenticando do jeito antigo, enquanto o sistema converte a credencial para o formato exigido pelo serviço consumidor

Encadeamento de chamadas de serviço (Chaining Service Calls)

• Em uma arquitetura de microsserviços, depois que o Service A processa uma requisição do usuário, ele pode precisar chamar o Service B em nome desse usuário, e o Service B pode então precisar chamar o Service C; a pergunta central é quais credenciais cada serviço deve usar na próxima chamada

• Opção 1 — usar as credenciais do próprio serviço

  • O Service A ignora o contexto do usuário e chama o Service B com suas próprias credenciais de cliente; isso serve para chamadas entre serviços em que o contexto do usuário não é necessário, como processamento em lote, verificação de estado do sistema ou sincronização de dados
  • Quando o usuário está envolvido, o Service B não consegue aplicar autorização no nível do usuário — não sabe qual usuário fez a requisição e, portanto, não pode verificar permissões de acesso; o contexto de segurança se perde

• Opção 2 — o serviço impersona o usuário

  • O Service A repassa o token original do usuário ao Service B ou o troca por um token indistinguível do do usuário; o Service B trata a chamada como uma requisição originada do próprio usuário e aplica autorização no nível do usuário
  • O Service B não consegue distinguir ações diretas do usuário de ações realizadas pelo Service A em nome dele; se o Service A for comprometido, poderá fazer qualquer chamada dentro das permissões do usuário, sem possibilidade de aplicar níveis diferentes de confiança para requisições diretas e por proxy — o contexto do usuário é preservado, mas o contexto do serviço se perde

• Opção 3 — agir em nome do usuário (Delegation)

  • O Service A troca o token do usuário por um novo token que identifica tanto o usuário (subject) quanto o Service A (actor); a claim act do token resultante informa algo como “requisição sobre o User X, executada pelo Service A”
  • Esse é o modelo de delegação que a RFC 8693 foi projetada principalmente para suportar; o Service B pode tomar decisões de autorização mais sofisticadas — se o Service A tentar executar algo que o usuário não autorizou, a requisição falha
  • A claim act pode ser aninhada (nestable); se o Service B chamar o Service C, a cadeia de delegação se expande e fornece uma trilha de auditoria completa
  • O trade-off é a complexidade — cada salto exige uma troca de token, aumentando a latência, e cada serviço precisa ser registrado como cliente no servidor de autorização; ainda assim, em arquiteturas onde segurança e auditoria são cruciais, é a escolha mais correta

Token Exchange e identidade federada

• Quando os serviços atravessam domínios de segurança — por exemplo, um serviço fornecido por uma organização terceira — o cenário de encadeamento fica muito mais complexo
  • O Service A possui um token para acessar o Service B em nome de um usuário dentro do domínio de segurança da MyCompany
  • O Service B precisa chamar o Service C, protegido no domínio do External Provider, e para isso necessita de um token de acesso
• Um token emitido pelo servidor de autorização da MyCompany não tem significado no domínio do External Provider — um token emitido por um servidor não é automaticamente aceito por outro; os limites de confiança existem para limitar o blast radius

• Limites da configuração federada

  • O servidor de autorização do External Provider precisa ser configurado para aceitar tokens do domínio da MyCompany como subject_token válidos; isso exige confiança prévia por troca de metadados, validação de certificados ou configuração direta, além do mapeamento de identidades entre domínios
  • À medida que o número de domínios cresce — em integrações corporativas, ecossistemas SaaS e ambientes multicloud — a matriz de relações bilaterais de confiança se torna impossível de administrar

• Cross App Access e Identity Chaining

  • Cross App Access (XAA) surge para resolver esse problema de escala; ele implementa o Identity Assertion JWT Authorization Grant e introduz um IdP corporativo como intermediário nas trocas entre domínios
  • A ideia aproveita o fato de que o IdP já conhece os dois aplicativos e a relação com o usuário; em vez de cada par de domínios estabelecer confiança bilateral, a decisão de acesso fica centralizada no IdP

  • Os 4 participantes do fluxo XAA

    • Requesting App: aplicação (ou agente de IA) no domínio da MyCompany que precisa acessar recursos em outro domínio
    • Enterprise IdP: provedor de identidade do domínio da MyCompany que autentica os funcionários e gerencia políticas entre aplicativos
    • Resource App: aplicação no domínio do External Provider que possui a API protegida
    • Resource Authorization Server: servidor de autorização que emite tokens de acesso para a API protegida do Resource App

  • Fluxo XAA passo a passo

    • O funcionário faz login no Requesting App via SSO e obtém um ID token do IdP
    • O Requesting App envia esse ID token de volta ao IdP para solicitar uma assertion de identidade entre domínios (ID-JAG, um JWT especial com escopo para uso entre aplicativos)
    • O IdP verifica a política XAA — decide se esse acesso ao Resource App em nome desse usuário é permitido; se for, retorna o ID-JAG
    • O Requesting App apresenta o ID-JAG ao servidor de autorização do Resource App
    • O servidor de autorização do Resource App valida o ID-JAG com a chave pública do IdP via OIDC discovery e então emite um token de acesso
    • O Requesting App usa esse token de acesso para chamar a API do Resource App
  • A diferença decisiva em relação à troca de tokens comum está na etapa 3, em que o IdP impõe a decisão de política — o administrador configura explicitamente quais aplicativos podem alcançar quais recursos, dando visibilidade e controle à TI e evitando que os usuários tenham de passar repetidamente por fluxos de consentimento
  • Identity Chaining é o padrão mais amplo em que a assertion de identidade do usuário flui de forma padronizada desde a autenticação inicial até todos os serviços downstream; o XAA é uma implementação desse padrão baseada em primitivas do OAuth
  • Isso é especialmente relevante em cenários com agentes de IA, nos quais uma única requisição de usuário pode disparar chamadas para serviços de vários provedores terceirizados

Token Exchange e Auth0

• O Auth0 implementa token exchange com mecanismos voltados a diferentes pontos do espectro discutido acima

• Custom Token Exchange

  • Implementa a RFC 8693 no endpoint /oauth/token do Auth0, oferecendo ao desenvolvedor controle total sobre a lógica de validação
  • Define um Token Exchange Profile que mapeia a URI de subject_token_type para uma Action customizada; quando a requisição chega, o Auth0 chama o código da Action para validar o token, aplicar regras de autorização e vincular o usuário dentro do tenant
  • Como o Auth0 trata o subject_token como uma string opaca, ele pode aceitar qualquer formato — JWT de outro IdP, assertion SAML legada ou token proprietário de uma API parceira — servindo como mecanismo para transição de protocolo e federação customizada

• Token Vault

  • Voltado a cenários com agentes de IA que precisam chamar APIs de terceiros em nome do usuário em vários provedores, adicionando à troca de tokens armazenamento seguro e gerenciamento automático de ciclo de vida
  • Após a autenticação, o usuário conecta contas como Google, GitHub, Slack e Microsoft; o Token Vault armazena os tokens com segurança e cuida automaticamente da renovação, enquanto o agente de IA recupera do cofre, via token exchange, um token de acesso válido
  • O token resultante inclui uma claim act que identifica o agente de IA — gerando uma trilha de auditoria sobre qual agente acessou qual serviço em nome de qual usuário, algo essencial para conformidade corporativa, onde é necessário saber o que disparou a automação

• On-Behalf-Of (OBO) Token Exchange

  • Implementa diretamente o padrão de delegação para cenários de cadeia de serviços; um serviço intermediário troca o token de usuário recebido por um novo token com escopo para a API downstream, adicionando a si mesmo na cadeia de delegação por meio da claim act
  • Suporta até 5 níveis de aninhamento na cadeia de delegação; cada token carrega as claims sub (preserva a identidade do usuário), aud (escopo do serviço de destino) e act aninhada (registra a cadeia de serviços envolvida)

• Cross App Access (XAA)

  • Voltado a cenários de identidade federada em que a aplicação solicitante precisa chamar uma API de recurso protegida por outro servidor de autorização; implementa a extensão OAuth Identity Assertion Authorization Grant
  • O Auth0 atua como Resource Authorization Server — o Requesting App envia o ID token do usuário para um IdP como o Okta e recebe um ID-JAG; o IdP só emite a assertion se o administrador tiver configurado a conexão entre aplicativos no Admin Console
  • Quando o Requesting App apresenta o ID-JAG ao Auth0, ele o valida via OIDC discovery e emite um token de acesso com escopo, oferecendo à TI visibilidade centralizada sobre o compartilhamento de dados entre aplicativos

Escolhendo a abordagem correta

• Token exchange não é uma solução única, mas um conjunto de padrões; a escolha depende de qual contexto você precisa preservar e de quais limites de confiança precisa atravessar
  • Impersonação administrativa: quando é necessário ver exatamente a mesma tela que o usuário vê para resolver um problema
  • Transição de protocolo: quando é preciso uma ponte entre sistemas de identidade legados e modernos durante uma migração
  • Delegation: quando uma cadeia de serviços exige contexto do usuário com auditoria completa
  • Cross App Access / Identity Chaining: quando a delegação precisa atravessar vários domínios de segurança
  • Token Vault: quando agentes de IA precisam de acesso gerenciado a APIs de terceiros em nome do usuário
• Agentes de IA que orquestram tarefas em nome do usuário por vários serviços e provedores são, em essência, cadeias de delegação; os mecanismos de token exchange fornecem a base de segurança para que essa cadeia seja auditável, autorizada e limitada à intenção do usuário