要約

  • draft-ietf-oauth-deferred-token-response-00 の deferral_code は、送信者に拘束された一件の保留要求を表す。アクセストークンではなく、資源への権限も与えない。
  • 取消はRFC 7009の失効エンドポイントを使う。実際に取消した場合も、何も変えなかった場合もHTTP 200になり得るため、対応メタデータと確認pollは別の証拠である。
  • すでに渡されたアクセストークンは独立したcredentialである。延期コードの取消だけでは、そのトークンも資源操作も止まらない。

200が隠しているもの

OAuthの失効応答は、入力値が有効だったかどうかを漏らさないよう設計されている。候補値を試す相手にオラクルを与えないためだ。その安全性は、運用側には別の課題を残す。HTTP成功を内部状態の成功として扱えない。

Deferred Token Response第00版 は、トークン判断が一回の往復で終わらない場面を扱う。人手審査、不正検知、外部検証などが続く間、クライアントは延期完了を希望できる。認可サーバーが選択すると、トークンエンドポイントはHTTP 400とauthorization_pending、不透明な延期コード、有効期間、poll間隔を返す。

これは失敗したアクセストークンではない。一件の保留要求を後で引き取るためのcredentialであり、保護資源へのアクセスを与えない。元の要求がDPoP鍵または相互TLS証明書に拘束されていれば、同じ拘束を引き継ぐ。

文書はOAuth作業部会の活発なInternet-Draftで、RFCでも実装調査でもない。以下は仕様が示す境界の分析であり、配備済み動作の主張ではない。

同じexpires_inでも時計の所有者が違う

延期応答のexpires_inは延期コードの寿命を示す。期限後のpollはexpired_tokenになる。最終的にアクセストークンが発行されると、成功応答にもexpires_inが現れ得るが、今度はトークンの寿命である。

文字列が同じでも、片方の時計で他方を更新してはならない。保留状態とアクセス状態は異なるcredentialに属する。

intervalも初回応答から保持しなければならない。保留中の応答は値を繰り返さず、slow_downを受ければ少なくとも五秒増やす。最新の応答だけを保存する監視では、クライアントが正しい頻度を守ったか検証できない。

callbackは最終回答ではない

登録したHTTPS endpointには、要求が成功、失敗、取消のどれかに解決したとき通知が届く。callbackは延期コードを示すだけで、トークンも結果も運ばない。「今pollすれば最終応答が得られる」という起床信号である。

要求ごとの通知トークンを使えば送信元を認証できる。使わない場合は別の保護が必要で、pollまで助言として扱うべきだ。認証できた通知でも、成功を意味しない。誰が知らせたかと、何が決まったかは別だ。

仕様はcallbackを登録しても間隔を守るpollを続けるよう勧める。通知は待ち時間を短くし、pollは紛失、遅延、抑止に耐える。二経路を一つの意味に潰せば、冗長性は消える。

取消応答は意図的に結果を区別しない

クライアントは延期コードを失効エンドポイントへ送り、deferral-codeのtype hintを添えることが推奨される。コードが認識され、認証済みクライアントのものなら、サーバーは保留要求を原子的にcancelledへ移す。まだ開始していないcallbackを抑止し、その後のpollをaccess_deniedにする。

一方、未知のコード、別クライアントのコード、すでにredeem、取消、期限切れとなったコードでも、HTTP 200を返して状態を変えない。RFC 7009 の非開示をそのまま保つためである。

第00版はrevocation_endpoint_token_type_values_supportedを定義する。延期コード失効に対応するサーバーは該当typeを列挙する。対応を表明しないサーバーも任意の失効要求に200を返すため、応答だけでは成功と区別できない。仕様自身が、確認を省けば取消が静かに失敗すると警告している。

証拠の順序は、対応メタデータのsnapshot、取消要求とtransport結果、続くpollのaccess_deniedである。200は必要な中間記録だが、終端証明ではない。

トークン引渡しの前後で義務が変わる

審査結果が成功としてcommitされても、トークンがまだクライアントに渡っていない瞬間がある。その間に取消が勝つと、延期コードは「redeem後にcancel」として扱われる。トークンは発行されず、pollはaccess_deniedになる。

すでに成功応答を受け取っていれば、延期コードの失効はアクセストークンを失効させてはならない。二つは独立したcredentialである。アクセスを止めるならトークンを別に失効し、必要なら資源サーバーで利用不能を観測する。

callbackも取消前に送信を開始しているかもしれない。抑止義務は未開始の通知に限られる。遅れて届くcallbackは、正しい取消と矛盾しない。それを承認や再開の信号にしてはいけない。

したがって状態表示は少なくとも、保留、解決済み未引渡し、トークン引渡し済みを区別する。「取消済み」だけでは次の操作が決まらない。

待っている間に同意は古くなる

延期コードは数時間、数日続くことがある。その間に資源所有者が同意を撤回し、クライアントが無効化され、sessionが終わる可能性がある。発行直前に認可サーバーは条件を再評価し、満たさなければaccess_deniedを返す。外部審査の成功は現在の同意を代替しない。

さらに資源サーバーはscopeとローカル方針で受入れを決める。正しいトークンも個別操作の成功証明ではない。最後の権限と観測は、各層に残る。

秘密を残さず、競合の形を残す

最小のローカルreceiptには、issuerと対応メタデータのdigest、クライアントと拘束鍵への参照、延期コードの一方向correlation、初回時刻、期限、poll間隔、取消とretry、確認poll、callback状態、トークン引渡し境界を含める。

一般ログに延期コード自体を残す必要はない。草案はrefresh token相当の秘密としてredactするよう求める。引渡し済みなら別のトークン失効receiptを加える。実行リスクなら資源の受入れと制御された操作結果を加える。

これは中央の取消台帳ではなく、証拠の最小初期仕様である。Lu HengのReality Layersに沿えば、200は記号、取消は内部遷移、access_deniedはプロトコル観測、トークン失効は別credentialの事象、資源操作は実行結果だ。下の層へ進むほど証拠は強くなる。

出典

  1. Deferred Token Response rev00
  2. DTR改訂履歴
  3. DTR rev00 HTML
  4. DTR rev00本文
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — OAuth失効
  7. RFC 8628 — Device Authorization Grant
  8. RFC 8693 — Token Exchange
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — OAuth Security BCP
  12. IANA OAuth Parameters
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary