Summary

  • draft-richer-oauth-oob-authcode-00は、ブラウザからcallbackを受け取れないclient向けに、保存済みstateでauthorization codeを一つの転記値へまとめる。個人提案であり、OAuth WG採用文書でもRFCでもない。
  • helper pageはHKDF、XOR、3-byte checksumでCCを作り、clientは元のstateでcodeを復元する。その後のtoken endpointへの交換は残る。
  • checksum一致は復元の整合性だけを示す。通信の秘匿、issuer、PKCE、token発行、resource権限、業務結果は証明しない。

callbackの代わりに人が運ぶ

remote shell上のCLIはauthorization URLをユーザーのブラウザで開けても、ブラウザから届くURLを自分で待ち受けられないことがある。revision 00はauthorization code grantを変えず、静的helper pageをredirect_uriとして登録する。ASはcodeとstateをそこへ返し、ページが一つの値を表示し、ユーザーが待機中のclientへ運ぶ。

helperはbackend stateを持たず、clientとの共有秘密もなく、tokenを要求しない。AS側の新しい参加も不要である。二つの値を取り違える人的リスクを減らすことだけが、新しい層の仕事だ。

したがって、ページ表示、copy、paste、復元、token交換は同じ出来事ではない。

短いchecksumの管轄

ページはcodeをCへ変換する。UTF-8 state、空のsalt、合意済みINFOからHKDFで同じ長さのKSを導き、E = C XOR KSを計算する。SHA256(C)の先頭3 byteをTとし、TとEを別々にpaddingなしbase64urlで表現して連結したものがCCである。

clientは保持していたstateから同じKSを作り、Cを戻してTを再計算する。不一致なら失敗し、checksum部分以下の短い入力も捨てる。そして初めて、復元したcodeをtoken endpointへ送る。

TはASだけが作れるMACではない。静的ページは誰でも任意のcodeとstateに使える。一致が語るのは、選んだstateで得たcode候補が短い自己検査と合うことだけだ。発行者、ブラウザsession、利用者、期限、有効性はそこに含まれない。

値は計算前に露出する

helperを取得するGETにはcodeとstateがqueryとして入る。origin server、CDN、mirror、cacheが両方を見る可能性がある。HKDF処理はその後である。草案自身も、暗号関数を使っていてもbasic code grant以上のsecurity protectionはなく、codeは秘密にならないと明記する。

codeとstateの両方が盗まれればCCは守らない。stateを保存しないclientは復元できない。JavaScriptが使えない場合のfallbackはhelper URL全体のcopyであり、その経路ではHKDFすら使われない。

さらにissなど他のparameterは落ちる。ASがissを返すとclientが分かっている場合に限り、それをINFOへ組み込めるという提案にとどまる。issuer確認は独立した判断として残さなければならない。

OAuthの判定列は続く

RFC 6749のcode binding、redirect、寿命、一回性、token交換はそのまま必要だ。PKCEを使うならchallengeに対応するverifierを提示する。client authenticationやRFC 9700の脅威対策が、3-byte checksumから生まれることはない。

RFC 8628のdevice authorization grantは、ASがdevice codeを発行しclientがpollingする別の構成である。新案はserver側の追加grantを避ける。round trip削減は運用上の利点だが、securityや復旧の同等性を証明しない。

Lu HengのMinimum Initial Specificationに従えば、共通機能は「転記ミスを減らしてcodeを復元する」まででよい。Running-Code Primacyは、その後にclient、token endpoint、resource serverが実際に何を受理したかを問う。一つの文字列は複数の現実層を一つにしない。

情報源と限界

これらはOAuth WG採用、IETF合意、RFC化、実装、相互接続、導入、login完了、token発行、攻撃、防御効果、resource結果を証明しない。既存のRFC 10027記事は攻撃者が起点deviceを支配するcontext問題を保持し、本稿はrevision 00の正直なflowにおける復元receiptだけを扱う。