Resumo

  • A RFC 9207 entrega ao cliente OAuth um comprovante estreito: o emissor da resposta de autorização deve ser idêntico ao emissor guardado para aquela solicitação. Se houver diferença, o fluxo termina antes que o código seja enviado ao endpoint errado.
  • O parâmetro iss identifica o contexto do servidor de autorização. Ele não autentica o usuário, não valida o código, não prova emissão ou validade de token e não demonstra uma decisão do servidor de recursos.
  • Uma operação auditável preserva registros distintos para estado da solicitação, emissor esperado, metadados, emissor recebido, comparação, troca do código, validação do token, decisão do recurso e recuperação.

O callback perigoso parece legítimo.

O navegador volta para uma URI de redirecionamento cadastrada. O state corresponde ao valor criado pelo cliente. A resposta carrega um código produzido por um servidor de autorização honesto. Nenhuma senha foi roubada e ninguém forjou o código. Ainda assim, um cliente que trabalha com mais de um servidor pode cometer o erro decisivo: mandar esse código verdadeiro para um token endpoint controlado pelo invasor.

O defeito nasce da união indevida de dois registros plausíveis. Um diz qual servidor o cliente acreditava ter escolhido quando começou. O outro é a resposta entregue pelo navegador do usuário. A resposta original do OAuth 2.0 não identificava explicitamente o servidor que a criou. Se um callback genérico ou metadados hostis apagarem essa fronteira, uma credencial válida atravessa para o domínio operacional errado.

A RFC 9207 corrige a lacuna com uma peça deliberadamente pequena. OAuth 2.0 Authorization Server Issuer Identification, publicada em março de 2022 na trilha de padrões do IETF, é trabalho conjunto de Karsten Meyer zu Selhausen e Daniel Fett. Ela define iss na resposta de autorização. O servidor compatível inclui seu identificador de emissor tanto no sucesso quanto no erro. O cliente compara o valor recebido ao emissor do servidor para o qual enviou a solicitação.

Se as duas strings não forem iguais, o cliente rejeita a resposta e não continua o grant.

Essa é toda a autoridade do campo — e justamente a origem do seu valor.

O callback não dizia quem respondeu

O OAuth separa papéis por projeto. O proprietário do recurso usa um agente de usuário. Um cliente solicita autorização a um servidor. Depois apresenta o código ao token endpoint. Por fim, usa um access token diante do servidor de recursos. Essa composição permite serviços independentes, mas cria escolhas de rota que a simples chegada do navegador não resolve.

A RFC 6749 colocou um código na resposta e, quando a solicitação continha state, devolveu o mesmo valor. Esse estado é essencial: vincula a resposta ao estado autenticado do navegador e ajuda a impedir CSRF. Mas não responde a outra pergunta: qual servidor de autorização emitiu a resposta?

Com apenas um servidor, a diferença pode ficar invisível porque não existe outro conjunto de endpoints. A partir do segundo, não basta lembrar que “há um fluxo OAuth pendente”. O cliente precisa lembrar a qual emissor ele pertence. A RFC 9700, prática atual de segurança do OAuth, exige que clientes com dois ou mais servidores impeçam ataques de mix-up e vinculem o emissor esperado a cada solicitação.

O histórico público de Daniel Fett contextualiza o problema sem transformar um padrão coletivo em mito pessoal. Seu site o descreve como consultor de segurança especializado em identidade e protocolos web, atuante em OAuth e OpenID Connect. Em setembro de 2026, o Datatracker listava quatro RFCs em seu nome, entre elas a RFC 9207. Isso mostra continuidade temática, não autoria exclusiva nem controle sobre qualquer implantação.

Um emissor aponta para um conjunto de endpoints

O identificador de emissor não é um nome de exibição. Na RFC 8414, ele é uma URL HTTPS sem consulta nem fragmento. Essa URL ancora um documento de metadados que pode indicar authorization endpoint, token endpoint, localização de chaves e outras capacidades. Um mesmo host pode acomodar emissores diferentes por caminho.

O objeto a proteger é esse conjunto. O usuário pode ver a página honesta de autorização enquanto a configuração do cliente associa a ela um token endpoint do invasor. A RFC 9700 alerta que guardar apenas a URL de autorização não basta: um ator malicioso pode declarar a URL honesta como sua e oferecer um endpoint de troca sob seu controle. O emissor precisa identificar o pacote inteiro que o cliente pretendia usar.

A RFC 9207 reconecta a resposta trazida pelo navegador a esse pacote. Quando há metadados, o iss da resposta deve ser idêntico ao issuer do documento, que anuncia suporte por authorization_response_iss_parameter_supported. O cliente extrai o valor, faz a decodificação de formulário e usa comparação simples de strings contra o emissor esperado.

Não existe aproximação semântica. Um caminho diferente, uma barra inesperada ou outro emissor no mesmo host não são “quase iguais”. A finalidade é roteamento determinístico, não semelhança para leitura humana.

A superfície de decisão continua local. O servidor declara sua identidade; os metadados descrevem os endpoints; o cliente registra a escolha, conserva o estado de suporte, compara e aborta. O sinal comum não transfere o controle futuro para uma coordenação central.

Coincidir autoriza a continuação, não comprova o fim

O mau uso mais fácil de iss é fazer o campo significar demais.

A igualdade de emissores não autentica o proprietário do recurso. O servidor ainda pode exigir login ou responder com erro. Ela não prova que o usuário entendeu o scope pedido; essa decisão pertence à interação de autorização e à política do produto.

A igualdade também não valida o código. Depois de selecionar o token endpoint correto, o endpoint ainda verifica o código, a identidade do cliente quando necessária, a URI de redirecionamento e as demais condições. O código pode ter expirado, ser replay ou pertencer a outro cliente.

O campo tampouco prova a emissão do token. Tipo, audience, scope, vida útil, sender constraint e revogação ficam fora dele. O servidor de recursos toma sua própria decisão quando recebe o token. Mesmo um token válido não demonstra que a ação da aplicação terminou nem que o usuário viu o resultado.

A cadeia correta conserva: criação da solicitação e emissor ligado ao navegador; chegada da resposta; valor iss; comparação e aceite ou aborto; endpoints escolhidos de metadados validados; aceitação ou recusa do código; validação e enforcement do token; resultado observado e recuperação.

A RFC 9207 governa a comparação. Chamar isso de “sucesso OAuth” apaga todas as decisões posteriores.

O campo não é uma assinatura

O iss da resposta comum não tem proteção criptográfica. A RFC 9207 afirma isso expressamente. A aparente contradição só existe quando o campo é apresentado como certificado universal.

O modelo de ameaça é menor. No mix-up, o cliente recebe uma resposta do servidor honesto, mas se confunde sobre qual conjunto de endpoints deve receber o código. Se o invasor consegue alterar a resposta antes da chegada, ele também consegue ler o código e não precisa do mix-up. O parâmetro remove a confusão de rota nesse modelo; não promete integridade contra qualquer adversário.

Quando uma resposta protegida é necessária, outros mecanismos carregam o emissor dentro de uma estrutura com integridade. O JARM usa um JWT assinado. Alguns fluxos OpenID Connect retornam ID Token no authorization endpoint e também podem transportar o emissor, desde que seja validado. Se vários identificadores presentes não coincidirem, a resposta deve ser rejeitada.

É a especificação inicial mínima em ação: acrescentar o menor sinal compartilhado que revela a ambiguidade, preservando escolhas locais de proteção forte, compatibilidade e migração. A RFC 9700 também admite URIs de redirecionamento distintas por emissor, desde que o cliente as verifique.

Compatibilidade antiga precisa de dono

Servidores não são atualizados ao mesmo tempo. Por isso a RFC 9207 mantém estado de suporte por servidor.

Se o cliente sabe que um servidor suporta iss, deve rejeitar uma resposta sem o parâmetro. Para um servidor conhecido como não compatível, a política local pode aceitar a ausência ou recusar a integração. Um servidor que envia iss sem anunciar suporte também merece tratamento explícito, pois pode expor inconsistência de configuração.

Essa flexibilidade localiza responsabilidade. Um cliente multiemissor precisa inventariar emissores, metadados, endpoints, suporte, fonte e data da crença, exceção legada, responsável e prazo de retirada. Sem saída, “compatibilidade” vira uma rota permanente ao redor da defesa.

Adicionar um segundo provedor é mudança de estado de segurança. O fato de um cliente de emissor único não precisar da defesa não o torna seguro após a expansão. A vinculação por solicitação precisa existir no código em execução antes do lançamento.

O comprovante que a operação pode testar

Ler os metadados uma vez não prova uma implantação. O teste começa na criação da solicitação.

Registre ID da solicitação, vínculo com o agente de usuário, emissor selecionado, versão dos metadados, endpoints, flag de suporte e URI de redirecionamento. Na volta, registre presença, valor decodificado, valor esperado, resultado da comparação e supressão efetiva da troca do código. Cubra sucesso, erro, ausência, duplicidade, emissor desconhecido e dois emissores no mesmo host com caminhos diferentes.

O teste negativo é decisivo. Depois da diferença, nenhuma requisição contendo código, credencial do cliente ou token pode chegar ao endpoint inesperado. Logs do cliente e dos endpoints de teste devem concordar. Uma mensagem de erro visível acompanhada por uma requisição de rede não constitui defesa.

Na investigação, a diferença de emissor prova falha de comparação, não automaticamente comprometimento. A recusa do token endpoint prova que ele negou um grant, não que a resposta era hostil. Uma negação do recurso não prova retroativamente a vinculação correta.

O campo funciona quando transforma uma ambiguidade invisível em decisão obrigatória antes que um segredo se mova. Ele nomeia o servidor. O token e o resultado ainda precisam de seus próprios responsáveis.

Fontes