Resumo

  • O draft-ietf-oauth-rar-metadata-remediation-00 permite que um servidor de recursos retorne objetos RAR acionáveis quando o token é válido, mas não traz os detalhes de autorização exigidos para a operação.
  • O servidor de recursos descreve o que considera suficiente; ele não concede o poder. O cliente escolhe se prossegue, o servidor de autorização aplica política e o titular pode negar ou reduzir o pedido.
  • Daniel Kade propõe um registro de delta de autoridade que una a operação negada, o poder atual, a proposta, a origem do schema, o consentimento, os detalhes efetivamente concedidos e o resultado. Isso é orientação fora do protocolo.

A resposta negativa passa a carregar uma proposta

O valor do novo mecanismo aparece onde integrações OAuth costumam ficar frágeis. Um aplicativo chama uma API com um token autêntico. A API entende a operação, mas conclui que faltam detalhes finos de autorização. Se responder apenas “acesso negado”, o cliente precisa conhecer uma convenção privada ou mandar a pessoa descobrir, em outra tela, o que deve solicitar.

O primeiro texto de grupo de trabalho sobre metadata e remediação de RAR define uma resposta mais útil. O servidor de recursos envia HTTP 401 com insufficient_authorization. O parâmetro authorization_remediation contém JSON codificado em base64url, podendo levar authorization_details construídos a partir da chamada recusada e uma authorization_reference opaca.

O cliente pode procurar um token já associado à referência, desde que esteja na mesma sessão do usuário e no mesmo origin do servidor de recursos. Se não encontrar um candidato aceitável, usa os detalhes fornecidos em uma nova solicitação OAuth com RAR. Depois da emissão, repete a chamada protegida.

Isso fecha uma lacuna real de interoperabilidade. A RFC 9396 padronizou objetos estruturados para autorização granular, mas não resolveu de forma geral a descoberta de cada tipo nem o percurso de recuperação após uma negativa do recurso. O rascunho acrescenta endpoint de metadata, JSON Schema ou URI de schema, código de erro, referência e regras de processamento.

O status, porém, não deve ser inflado. A revisão 00 foi publicada em 23 de agosto de 2026, substitui uma série individual e aparece no Datatracker como documento do grupo OAuth. As atas do IETF 126 registram apoio ao problema, debate sobre a solução e chamada para adoção. Ainda não é RFC, não passou por teleconferência do IESG e os novos nomes no registro IANA continuam propostos.

Quem formula a suficiência não decide sozinho

O rascunho diz que o servidor de recursos constrói os detalhes acionáveis usando a operação que falhou. Se uma nova concessão bem-sucedida incluir esses detalhes, ela deverá satisfazer os requisitos do recurso. É uma função substantiva: o componente que aplica a política escreve a proposta que pode alimentar a próxima solicitação de autoridade.

Isso não transforma o recurso em servidor de autorização. O cliente pode descartar o desafio. O servidor de autorização valida o tipo, aplica sua política e executa o fluxo escolhido. Pela RFC 9396, o conjunto pedido é apresentado ao titular; ele pode consentir apenas com uma parte. A resposta do token informa quais detalhes foram de fato concedidos. O recurso, por fim, avalia novamente o token e a operação.

Há, portanto, dois erros de leitura a evitar. O primeiro é dizer que a API concedeu poder a si mesma. O segundo é chamar tudo de repetição. Entre a tentativa original e a seguinte, a autoridade pedida pode ter mudado de ação, objeto, duração, recorrência ou contexto.

Uma leitura pontual de conta não equivale a acesso contínuo. Um pagamento único não equivale a mandato recorrente. Uma alteração de geolocalização ou postura do aparelho pode fazer o servidor pedir outra cerimônia e outros atributos. Em cada caso, a proposta pode ser mais estreita, igual, mais ampla ou incomparável ao que o cliente já possuía.

Não há atalho pela contagem de campos. A RFC 9396 afirma que não existe mecanismo padronizado para comparar objetos arbitrários, pois a semântica pertence a cada API. Omissão pode ativar um default mais aberto; uma lista pode somar capacidades; um identificador diferente pode deslocar o direito para outro recurso. JSON válido não significa autoridade apropriada.

A referência opaca só localiza um candidato

A authorization_reference evita que o cliente tenha de compreender todo objeto RAR para procurar um token. O servidor deve produzir um valor estável para detalhes iguais ou semanticamente equivalentes. O cliente faz comparação simples e recupera uma credencial associada à mesma sessão e ao mesmo origin.

O uso é cercado por limites. A referência não pode revelar informação sensível, não deve ser interpretada pelo cliente, não vale em outro servidor de recursos e não deve aparecer quando o token é de uso único.

Mesmo quando há correspondência, a aceitação não está garantida. O consentimento pode ter sido revogado. O contexto de risco pode ter mudado. O servidor de autorização pode ter emitido um subconjunto. A referência seleciona um candidato; não substitui a decisão do recurso.

Quando não há correspondência, também não se pode inferir que falta autoridade. O rascunho observa que um token para débitos recorrentes de até 100 pode servir a uma operação de 80 apesar de referências distintas. A relação de inclusão depende da semântica do tipo, não da igualdade entre strings opacas.

Essa diferença precisa sobreviver à telemetria. “Referência encontrada” não deveria virar “autorização confirmada”. “Referência nova” não deveria iniciar automaticamente outro fluxo sem revelar o que mudou. Um valor criado para reduzir complexidade de seleção não pode ser promovido a parecer de política.

Schema descobre e valida forma, não finalidade

O endpoint de metadata proposto permite publicar, para cada tipo, versão informativa, descrição, documentação, exemplos e um JSON Schema incorporado ou referenciado. O schema descreve um único objeto e restringe o campo type ao identificador correto.

Isso ajuda a construir e validar mensagens. Não decide se o pedido é razoável. O texto diz que descrições não podem orientar autorização ou validação, exemplos não são normativos e versão não implica negociação semântica. Um objeto perfeitamente conforme ainda pode pedir poder excessivo para a finalidade do usuário.

A procedência do schema continua importante. Se a definição mudar entre a negativa e a autorização, os mesmos nomes podem ganhar leitura distinta. Uma investigação precisa do URI ou hash, da hora de obtenção e da versão do avaliador específico que comparou as autoridades.

Também precisa do emissor escolhido. Se o servidor de autorização corrente não conhece o tipo, o cliente pode usar Protected Resource Metadata para descobrir outro. Trocar de emissor muda possíveis regras de cadastro, autenticação, consentimento, retenção e responsabilidade institucional. Não é apenas trocar uma URL.

Um registro de delta de autoridade

Proponho um registro de delta de autoridade. Ele não acrescenta claim, header ou objeto ao OAuth. É uma trilha operacional mínima ao redor do fluxo.

O primeiro bloco fixa a negativa: sessão do usuário, origin do recurso, classe da operação, compromisso seguro com a requisição e detalhes ou scopes efetivos do token apresentado. Conta, prontuário, localização e valor não devem ser despejados em log geral; referências curtas e compromissos salgados são preferíveis.

O segundo fixa a proposta: hash do authorization_remediation decodificado, resumo legível do efeito, referência, tipo, URI ou hash do schema, versão informativa e instante de consulta. Um avaliador semântico classifica o delta como igual, menor, maior, incomparável ou desconhecido, preservando também sua versão de política.

O terceiro registra a conduta do cliente. Ele abandonou, tentou token existente, abriu autorização, pediu confirmação ou encaminhou a um responsável? Qual servidor de autorização foi escolhido? Qual versão da tela de consentimento apareceu? O titular negou, limitou ou aceitou? Quais detalhes o token declara como efetivamente concedidos?

O último bloco acompanha o resultado. A associação entre referência e token fica presa à sessão e ao origin, sem guardar o token. O registro separa tentativa em cache de nova autorização, conta os ciclos, captura a decisão final do recurso e liga essa decisão ao resultado ou à reversão da operação.

Cada parte pode então provar apenas o que observou. O servidor de recursos prova a proposta; o cliente, o tratamento; o servidor de autorização, a apresentação e emissão; o titular, a escolha; o sistema de negócio, o efeito. Emissão de token não vira prova automática de pagamento concluído.

Evidência mínima para não criar um novo vazamento

Objetos RAR podem conter dados bancários, clínicos e transacionais. O rascunho recomenda que o recurso evite informação sensível e use handles opacos. Ao servidor de autorização, recomenda avaliar tamanho e privacidade antes de incluir detalhes em JWT, usando introspecção autenticada quando for mais adequado.

O registro de delta precisa obedecer ao mesmo princípio. Hash sem sal de um valor previsível pode ser revertido por tentativa. O resumo humano deve explicar a classe de efeito sem copiar o ativo protegido. O material detalhado, quando necessário, permanece no domínio de origem e por prazo definido.

Além disso, cada campo precisa de rótulo de proveniência. Um identificador enviado pelo recurso não é declaração do usuário. Texto de schema não é consentimento. Detalhes no token não comprovam que a interface foi entendida. Separar as fontes impede que vestígios técnicos sejam transformados em uma história institucional que eles não sustentam.

Limite de repetição não basta sem limite de poder

O rascunho contém defesa contra loop: uma tentativa com token em cache, uma autorização nova e parada se a mesma referência voltar após o novo token. Uma referência diferente pode abrir outra remediação, sujeita a um máximo definido pela implementação. O armazenamento deve ser isolado por sessão.

Isso controla repetição idêntica, mas não uma escada de propostas. Referências que mudam podem acompanhar contexto legítimo, política instável ou requisitos cada vez maiores. A implantação precisa de um orçamento semântico: novo emissor, recurso diferente, ação de alto impacto, duração ou recorrência maior, schema alterado e objeto incomparável.

Ao cruzar essa fronteira, o produto deixa de chamar o passo de reparo automático e apresenta uma nova decisão. Repetir usa a autoridade que já existia. Remediar pode solicitar outra. O protocolo torna a proposta transportável; a governança impede que a diferença desapareça antes do efeito.

Fontes

  1. Rascunho de metadata e remediação RAR
  2. Histórico do rascunho
  3. Revisão 00
  4. Repositório do texto predecessor
  5. Atas OAuth do IETF 126
  6. Grupo OAuth
  7. RFC 9396 — Rich Authorization Requests
  8. RFC 6750 — Bearer Token Usage
  9. RFC 8414 — metadata de servidor de autorização
  10. RFC 9728 — metadata de recurso protegido
  11. RFC 9470 — desafio de autenticação adicional
  12. RFC 7662 — introspecção de token
  13. RFC 9068 — perfil JWT para tokens de acesso
  14. RFC 9126 — Pushed Authorization Requests
  15. RFC 9101 — JWT-Secured Authorization Request
  16. Parâmetros OAuth da IANA
  17. Registro da API do Datatracker
  18. Texto simples da revisão 00
  19. Fonte XML da revisão 00
  20. Issues do repositório predecessor