Acesso à API entre domínios: além dos atalhos “óbvios” • Aaron Parecki
O acesso entre domínios está em toda parte no cenário de software atual. Quer você observe aplicativos SaaS corporativos, agentes de IA interagindo com dados de usuários em diversas plataformas ou “experiências integradas” extraindo informações de um calendário, uma ferramenta de bate-papo e um wiki, tudo eventualmente precisa se comunicar além dos limites.
As equipes de desenvolvimento frequentemente buscam o caminho mais rápido para conectar esses sistemas. Normalmente, as equipes recorrem a dois atalhos arquitetônicos “óbvios”. No entanto, como demonstra a experiência na implantação dessas arquiteturas em escala, ambos os modelos falham na produção.
Vamos examinar mais de perto por que esses atalhos falham e como realmente se parece um padrão resiliente entre domínios.
🧶 Atalho nº 1: Faça com que o IdP emita o token de acesso diretamente
O padrão: o cliente leva seu token de ID para o IdP, troca-o por um token de acesso e envia esse token de acesso diretamente para a API do aplicativo de recurso.
Por que é tentador: reutiliza o IdP em que todos já confiam. Parece um balcão único e limpo.
Por que quebra: cada API que recebe agora precisa confiar em uma lista crescente de emissores de tokens estrangeiros – cada um com suas peculiaridades em relação ao formato do token, convenções de reivindicação, rotação de chaves e revogação.
De repente, sua equipe de API está no negócio de federação, fazendo integrações únicas por IdP. Esse não é um modelo sustentável para construir APIs em escala. As APIs são muito melhor atendidas se tiverem um servidor de autorização local emitindo os tokens que validam – um emissor, um modelo, um conjunto de regras.
🪪 Atalho nº 2: Envie o token de ID entre domínios
O padrão: ignore o token de acesso emitido pelo IdP e apresente o token de ID original diretamente no servidor de autorização do aplicativo receptor, trocando-o por um token de acesso emitido localmente.
Por que é tentador: Os tokens de ID são padronizados, então parece que isso evita o problema de distribuição de confiança do número 1.
Por que quebra: Os tokens de ID são emitidos para um público – o aplicativo no qual o usuário se conectou. Enviá-los para outro lugar viola a vinculação do público, abre riscos de repetição e uso indevido.
🎯 O que o Cross-App Access faz de diferente
O Cross-App Access (XAA) usa um fluxo de dois estágios — e cada estágio existe especificamente para corrigir um dos problemas acima.
Etapa 1: O cliente faz uma solicitação de troca de token ao IdP para trocar o token de ID por um ID-JAG: uma concessão específica, de curta duração e vinculada ao público para o servidor de autorização de recursos.
Sem uso indevido de ID Token, sem confusão do público. O IdP também permanece informado para decidir se esse acesso entre aplicativos deve acontecer – exatamente onde a TI corporativa já gerencia quem pode acessar o quê.
Etapa 2: O servidor de autorização do aplicativo de recurso troca o ID-JAG pelo seu próprio token de acesso. A API mantém seu AS local, seu próprio formato de token e sua própria história de revogação. Ele só precisa confiar nos tokens de acesso emitidos por seu próprio AS – e não em um token de acesso estrangeiro.
Podemos empurrar toda a complexidade do login do usuário, criação de tokens e avaliação de políticas entre domínios para os componentes de identidade especializados, mantendo a API de recursos livre para realizar a tarefa muito mais simples de validar os tokens de acesso de seu próprio domínio e servir dados.
Se você estiver projetando acesso entre domínios para um agente de IA, um pacote empresarial ou qualquer ecossistema de vários fornecedores, este é o padrão a seguir. O rascunho da IETF: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
