Résumé

  • Le projet individuel déposé le 28 septembre par Justin Richer permet de copier une seule valeur depuis une page du navigateur vers un client OAuth distant.
  • La manipulation est plus courte, mais le site relais voit toujours code et state ; l’assemblage cryptographique ne lui confère aucune autorité nouvelle.

La difficulté commence avant le copier-coller. Un client exécuté dans un terminal distant peut ouvrir la procédure d’autorisation sans posséder une adresse de retour accessible au navigateur de la personne. draft-richer-oauth-oob-authcode-00 place donc une page auxiliaire à l’adresse de redirection enregistrée. Le navigateur y arrive, puis la personne reporte une valeur dans le terminal. Ce texte du 28 septembre 2026 est un Internet-Draft individuel, annoncé avec une intention informative. Son état Datatracker est I-D Exists : ni adoption par un groupe de travail, ni consensus IETF, ni RFC.

La page reçoit la réponse habituelle du serveur d’autorisation. Elle prend le code et le paramètre state, puis utilise HKDF, une opération XOR et une somme de contrôle pour former une valeur unique. Le client, qui avait conservé son propre state, retrouve le code et poursuit l’échange auprès du point de terminaison des jetons. L’intérêt opérationnel est précis : aucun nouveau type de délégation n’est demandé au serveur, hormis l’acceptation de cette adresse de retour enregistrée.

Il serait trompeur d’appeler cette valeur un coffre-fort. Le projet affirme expressément que sa méthode n’ajoute pas de sécurité à la délégation ordinaire par code d’autorisation. Le navigateur a déjà envoyé code et state dans une requête GET vers la page auxiliaire. Même si la page est statique et sans session côté serveur, l’hébergeur, son CDN, un miroir ou un cache peuvent voir les paramètres de l’URL. La simplicité du code JavaScript ne supprime pas cette provenance.

Le site relais n’atteste pas non plus l’identité du serveur d’autorisation. N’importe qui peut reprendre l’algorithme avec des données arbitraires. C’est au client de relier la valeur collée à la requête encore en attente, au state qu’il a conservé et au serveur auquel il comptait remettre le code. Un client sans état persistant ne peut pas employer cette voie. Si JavaScript échoue, le projet envisage de copier l’URL complète : cette issue transmet directement les paramètres d’origine et mérite un traitement distinct du format combiné.

La valeur proposée ne transporte pas tous les champs de la réponse. Elle contient code et state, mais pas iss comme paramètre autonome ; la section 3.4 évoque son éventuel usage dans le champ INFO de HKDF si le client sait que le serveur le renvoie. RFC 9207 fournit déjà un moyen d’identifier l’émetteur, notamment contre les confusions entre plusieurs serveurs. Cela n’établit pas une faille automatique dans chaque client utilisant le projet. Cela impose de savoir comment une application multi-serveur conserve sa vérification préexistante après la saisie manuelle.

La délégation destinée aux appareils, définie par RFC 8628, demeure une autre solution, avec participation du serveur et interrogation périodique. Le nouveau texte ne la retire pas. Il propose un autre compromis de migration : réutiliser le flux par code et accepter une page relais ainsi qu’une action humaine. La charge de développement côté serveur peut diminuer ; la responsabilité du chemin parcouru par la réponse, elle, ne disparaît pas.

Sources