要約

  • Justin Richerが9月28日に提出した個人Internet-Draftは、ブラウザーで受けたOAuth認可コードを一つの文字列として遠隔クライアントへ手入力する方法を示す。
  • 文字列を作るHKDFとXORは新しい安全性を与えない。補助ページはcodeとstateを受け取り、クライアント側の要求と発行元の確認も必要なままだ。

手元のブラウザーで承認し、遠くのサーバーで動くコマンドラインに結果を戻したい。しかしそのコマンドラインはブラウザーから到達できるリダイレクト先を開けない。この間隙に向けたのがdraft-richer-oauth-oob-authcode-00だ。登録済みの補助ページを戻り先にし、表示された値を利用者が端末へ貼り付ける。2026年9月28日提出の情報提供を意図した個人草案であり、Datatrackerの状態はI-D Exists。作業部会の採用、IETFの承認、RFC化を示すものではない。

認可サーバーは通常のコード応答を登録済みURIへ返す。ページはcodeとstateを受け取り、stateからのHKDF、XOR、短い検査値によって一つの値を作る。元のstateを保持する端末はそこからコードを復元し、本来のトークンエンドポイントへ進む。新たな認可方式をサーバーに実装させる提案ではなく、補助ページを戻り先として登録することが前提となる。

問題は、そのページがどこに置かれるかだ。草案自身、組み合わせの計算は基本の認可コード方式より安全性を増さないと明記する。ブラウザーから補助ページへのGETには、元のcodeとstateがURLパラメーターとして含まれる。ページが静的でサーバー側のセッションを持たなくても、配信元、CDN、ミラー、キャッシュやアクセスログがそのURLに触れうる。コードを一つの見やすい値に変えることと、途中の受信者を消すことは違う。

また、誰でも任意の入力で同じ組み合わせ処理を実行できる。その出力だけを認可サーバーの証明として扱ってはならない。端末は、自分が開始した未完了の要求、保持したstate、予定したサーバーとトークン送信先を照合する必要がある。状態を保持できないクライアントにはこの方法を適用できない。JavaScriptが動かない場合にはURL全体のコピーも例示されるが、それは元のパラメーターを直接渡す別経路である。

運ぶ項目の選択にも境界がある。通常の結合値はcodeとstateを対象とし、issなど他の応答パラメーターは独立して運ばない。第3.4節は、サーバーがissを送るとクライアントが知っている場合、HKDFのINFOに使う可能性に触れる。RFC 9207は複数の認可サーバーを使うクライアント向けに、発行元の取り違えを抑える識別を定めている。省略だけで全実装に欠陥があるとは言えないが、既存の発行元との結び付きをどのように守るかは説明が要る。

RFC 8628のデバイス認可は、サーバー側の対応とポーリングを伴う別の選択肢だ。今回の草案がそれを廃止するわけではない。認可コード方式を再利用して遠隔端末に対応するという、別の移行判断を示したにすぎない。サーバー改修が少なく見えても、補助ページの運用者と人手の転記が新しい確認点になる。

出典