Summary

  • draft-richer-oauth-oob-authcode-00 propose à un client incapable de recevoir une redirection de faire recopier une valeur combinant code et state; il s’agit d’une soumission individuelle, pas d’un résultat adopté par OAuth ni d’une RFC.
  • La page auxiliaire dérive un flux avec HKDF, applique un XOR au code et ajoute trois octets de contrôle. Le client reconstruit le code grâce au state qu’il avait conservé.
  • Le contrôle réussi atteste une reconstruction cohérente, pas un canal confidentiel, l’identité de l’émetteur, PKCE, l’acceptation au token endpoint, la permission sur la ressource ou l’effet final.

Une page statique au milieu du parcours

Le client ouvre l’URL d’autorisation dans le navigateur puis attend une saisie. L’authorization server effectue son travail habituel et redirige vers une page auxiliaire enregistrée comme redirect_uri. Cette page reçoit code et state, calcule la valeur à afficher, puis laisse l’utilisateur la transporter jusqu’au terminal.

Le serveur d’autorisation n’a pas besoin de connaître cette transformation. La page n’entretient ni session côté serveur ni secret partagé avec le client. Elle ne demande pas le token. Elle remplace seulement deux opérations humaines fragiles par une seule.

Le mécanisme gagne ainsi en ergonomie sans changer la chaîne d’autorité. La page auxiliaire n’est ni le client d’origine ni le token endpoint. Le presse-papiers n’est pas une redirection authentifiée.

Trois octets ne signent personne

Le texte encode le code en octets C. HKDF reçoit le state en entrée, un sel vide, une valeur INFO commune et produit KS de même longueur. La page calcule E = C XOR KS. Elle tronque ensuite SHA256(C) à trois octets pour obtenir T, encode séparément T et E en base64url sans remplissage, puis les concatène dans CC.

Le client connaît encore son state. Il redérive KS, récupère C, recalcule T et refuse la valeur si le contrôle diffère. Une saisie de quatre caractères ou moins doit être rejetée. Un mauvais state doit normalement conduire à un code que le token endpoint ne reconnaît pas.

Mais T n’est pas un MAC émis par l’authorization server. La page publique peut fabriquer des valeurs à partir de n’importe quels code et state. La concordance dit que les octets reconstruits sont cohérents avec ce petit contrôle. Elle ne dit pas quelle autorité les a créés, qui les a vus, ni si le code reste valable.

L’exposition précède le calcul

Le navigateur appelle la page auxiliaire avec code et state dans la requête GET. Le serveur, le CDN, les miroirs et les caches qui servent la page peuvent donc les recevoir. HKDF intervient ensuite. Le projet le dit sans détour : les primitives cryptographiques n’ajoutent aucune protection au-delà du grant de base et ne rendent pas le code secret.

Si un attaquant obtient à la fois le code et le state, la valeur combinée ne répare rien. Si le client n’a pas conservé son state, il ne peut rien reconstruire. Et si JavaScript ne calcule pas HKDF, la solution de repli consiste à recopier toute l’URL : dans ce cas, code et state voyagent directement, sans construction combinée.

Le paramètre iss ne fait pas partie du paquet. Il pourrait devenir INFO si le client sait qu’il sera renvoyé, mais ce choix reste un profil local. Une copie réussie ne prouve donc pas à elle seule que l’émetteur attendu a été vérifié.

L’échange reste à accomplir

Après la reconstruction, le client doit encore appeler le token endpoint. Les liaisons du code, l’exactitude de la redirection, la durée de vie et l’usage unique continuent de relever de RFC 6749. PKCE exige toujours la preuve du verifier lié au challenge. Les recommandations de sécurité de RFC 9700 ne sont pas encapsulées par la chaîne affichée.

RFC 8628 suit une autre architecture : le serveur délivre un device code et le client interroge périodiquement le token endpoint. La proposition OOB évite cette prise en charge serveur. Ce choix peut réduire le nombre d’allers-retours, mais il ne transforme pas deux modèles différents en garanties équivalentes.

La Minimum Initial Specification de Lu Heng conduit à garder la promesse commune petite : une reconstruction moins exposée aux erreurs de transcription. Running-Code Primacy exige ensuite les reçus réellement produits par le client, le token endpoint et le resource server. La présentation d’une seule chaîne ne fusionne pas ces réalités.

Sources et limites

Ces sources ne prouvent ni adoption par le groupe OAuth, ni consensus IETF, ni RFC, ni implémentation, interopérabilité, déploiement, connexion achevée, token délivré, attaque, efficacité d’une défense ou résultat de ressource. L’Article antérieur sur la RFC 10027 conserve l’attaque où un appareil initiateur hostile reçoit l’autorité; celui-ci analyse le reçu de reconstruction du flux honnête décrit en révision 00.