Resumo

  • Justin Richer apresentou em 28 de setembro um Internet-Draft individual para levar um código de autorização OAuth do navegador a um cliente remoto em um único valor copiável.
  • A combinação facilita a transferência, mas não protege o código além do fluxo usual: a página auxiliar recebe code e state, e o cliente precisa conservar o contexto da solicitação.

O terminal remoto inicia a autorização, enquanto a pessoa conclui a interação em um navegador que não consegue alcançar uma URL de redirecionamento hospedada pelo próprio cliente. draft-richer-oauth-oob-authcode-00 responde a esse impasse com uma página auxiliar registrada como destino de retorno. Ela mostra uma sequência que a pessoa cola no terminal. O documento foi apresentado em 28 de setembro de 2026 como proposta individual de caráter informativo. Seu estado no Datatracker é I-D Exists, não adoção por grupo de trabalho, aprovação da IETF ou publicação como RFC.

O servidor de autorização segue devolvendo a resposta habitual ao URI registrado. A página usa code e state, material derivado por HKDF, XOR e uma soma de verificação para formar um valor único. O cliente havia guardado o state original; com ele recupera o código e prossegue ao endpoint de tokens previsto. A atratividade para quem mantém o servidor está em não exigir um novo tipo de concessão ou extensão do protocolo, além do cadastro da página de retorno.

Mas a palavra “combinar” não significa ocultar o código de toda a cadeia. O próprio rascunho afirma que o método não traz segurança adicional sobre a concessão básica por código de autorização. A requisição GET do navegador leva code e state à página auxiliar. Hospedagem, CDN, espelhos, caches e logs podem ter contato com esses parâmetros, mesmo quando o arquivo da página é estático e não usa sessão no servidor. Uma implantação que vende simplicidade sem mapear essa exposição desloca a questão para outro operador.

O valor apresentado tampouco autentica por si o servidor esperado. Qualquer parte pode executar a transformação com dados arbitrários. A checagem relevante permanece no cliente: qual pedido está pendente, qual state foi retido e a qual servidor e endpoint se pretendia responder. O método combinado não serve a um cliente sem estado preservado. Se o JavaScript falhar, o texto sugere colar a URL inteira; esse plano alternativo transfere os parâmetros originais diretamente e deve ser analisado como outro tratamento.

Há ainda uma decisão sobre campos da resposta. A sequência normal contém code e state, não o parâmetro independente iss. A seção 3.4 aventa seu uso no INFO do HKDF quando o cliente sabe que o servidor o envia. A RFC 9207 já estabelece a identificação do emissor como defesa contra confusão entre servidores para clientes que utilizam mais de um. Isso não torna todo uso da proposta vulnerável; exige que uma implantação multi-servidor mostre como mantém sua vinculação com o emissor na passagem manual.

A autorização de dispositivo da RFC 8628 continua disponível, com participação do servidor e consultas periódicas. O novo texto não determina sua substituição. Ele oferece uma opção de engenharia para reaproveitar o fluxo de código em ambientes remotos. Menos trabalho no servidor pode ser uma vantagem, mas a origem da página e o gesto de copiar passam a compor a decisão de manutenção do cliente.

Fontes