Summary

  • draft-richer-oauth-oob-authcode-00 combina o código de autorização com o state guardado pelo cliente para produzir um valor copiável quando o navegador não alcança o callback; é uma submissão individual, não adoção do OAuth nem RFC.
  • A helper page usa HKDF, XOR e checksum de três bytes; o cliente reverte o processo e ainda precisa trocar o código no token endpoint.
  • Reconstrução coerente não prova sigilo, issuer, PKCE, aceitação do token, autorização no recurso ou efeito final.

O usuário ocupa o trecho que faltava

Um cliente em linha de comando pode abrir o navegador, mas não receber uma URL nele. A revisão 00 mantém o authorization code grant e registra uma página auxiliar estática como redirect_uri. O AS envia code e state à página; ela mostra um valor único; o usuário o leva ao cliente que está esperando.

A página não mantém sessão no backend, não compartilha segredo prévio e não chama o token endpoint. O AS continua alheio à codificação. A melhoria concreta é evitar que duas cadeias sejam confundidas durante a transferência manual.

Esse limite impede um salto semântico: mostrar, copiar, reconstruir e obter token são eventos diferentes.

O checksum confirma formato, não autoridade

O code vira C. HKDF recebe state em UTF-8, salt vazio e INFO comum, produzindo KS do mesmo tamanho. A página calcula E = C XOR KS, toma os três primeiros bytes de SHA256(C) como T e concatena as codificações base64url sem padding de T e E em CC.

Com o state original, o cliente recria KS, recupera C e compara T. Divergência encerra o processo; entradas de quatro caracteres ou menos devem ser descartadas. Só depois o code recuperado segue para o token endpoint.

T não é MAC do AS. Qualquer pessoa pode fornecer code e state à página pública. A igualdade indica autoconsistência sob aquele state, não identidade do emissor, origem do navegador, validade temporal ou aceitação futura.

A infraestrutura vê antes da transformação

Code e state chegam no GET da helper page. Origem, CDN, espelhos e caches podem recebê-los. HKDF acontece depois. O próprio texto afirma que as funções criptográficas não acrescentam proteção ao grant básico nem mantêm o código secreto.

Roubo de ambos os valores não é corrigido por CC. Cliente que não reteve state não consegue decodificar. Sem JavaScript, o fallback copia a URL inteira e extrai os parâmetros diretamente, sem HKDF.

O método também descarta iss. Usá-lo como INFO só é possível quando o cliente sabe que o AS o devolve. Logo, validar issuer permanece uma etapa própria.

A troca normal continua valendo

RFC 6749 ainda define binding, redirect, validade e token request. PKCE continua exigindo o verifier relacionado ao challenge. Autenticação do cliente, uso único e a orientação de RFC 9700 não nascem do checksum.

RFC 8628 usa outro desenho: device code fornecido pelo servidor e polling. Evitar esse suporte pode reduzir integrações e round trips, mas não prova equivalência de segurança, recuperação ou telemetria.

A Minimum Initial Specification de Lu Heng mantém a promessa comum pequena: reduzir erro de transcrição. Running-Code Primacy exige depois os fatos do cliente, token endpoint e resource server. Uma sequência na tela não apaga essas camadas.

Fontes e limites

As fontes não provam adoção pelo OAuth, consenso IETF, RFC, implementação, interoperabilidade, implantação, login concluído, token emitido, ataque, sucesso de mitigação ou resultado de recurso. O Artigo anterior sobre RFC 10027 mantém o problema do dispositivo iniciador hostil; este trata apenas do recibo de reconstrução no fluxo honesto da revisão 00.