要約

  • draft-ietf-oauth-rar-metadata-remediation-00 は、有効なトークンでも細粒度の権限詳細が足りない場合、リソースサーバーが実行可能なRARオブジェクトを返す仕組みを提案している。
  • リソースサーバーは十分条件を提案するが、権限を付与するわけではない。クライアントが処理を選び、認可サーバーがポリシーを適用し、リソース所有者は拒否または縮小できる。
  • Daniel Kadeは、失敗した操作、現在の権限、提案、スキーマの由来、同意、実際の付与内容、最終的な効果を結ぶ権限差分記録を提案する。これは草案外の運用ガバナンスである。

「足りない」の中身を機械が運べるようにする

OAuthで保護された業務APIが支払いを拒否したとする。トークンは正規で期限も切れていない。それでも、対象取引に必要なauthorization_detailsがない。従来なら、クライアントは曖昧なエラーを表示するか、サービス固有の手順書を読んで別の認可を求めるしかない。相手ごとの取り決めが、相互運用性の穴を埋めてきた。

OAuthワーキンググループの新しい草案は、その穴に構造を与える。リソースサーバーはHTTP 401とinsufficient_authorizationを返し、base64urlで符号化したauthorization_remediationに、失敗した要求から組み立てたauthorization_detailsを入れられる。任意のauthorization_referenceも加えられる。

クライアントは、同じエンドユーザーセッションと同じリソースサーバー起点に限って、参照値に対応する既存トークンを探す。候補がなければ、提示された詳細をRAR対応の新しい認可要求にそのまま使える。新しいトークンを得た後、元のリソース要求を再度送る。

この流れが埋める欠落は明確だ。RFC 9396は細粒度の権限をJSONオブジェクトで表す方法を標準化したが、あらゆる型の発見方法や、リソース層で拒否された後の共通復旧手順までは定めなかった。今回の草案は、型メタデータのエンドポイント、スキーマ、エラーコード、参照値、処理手順を組み合わせる。

ただし制度上の重みは限定して読む必要がある。00版は2026年8月23日付で、個人草案を引き継ぐOAuth WG文書である。IETF 126の議事録には、問題設定への支持、解決方法をめぐる議論、採択手続きへの賛意が残る。まだRFCではなく、IESGテレチャットもなく、IANA登録値も提案段階だ。相互運用の設計が具体的であることと、標準化が完了したことは別である。

執行者が提案を書いても、付与者にはならない

草案では、リソースサーバーが失敗した要求に基づいて、実行可能な権限詳細を構成する。その詳細を新しい認可が含めば、リソース側の要件を満たすはずだとする。つまりアクセスを執行する側が、次の認可要求の材料を作る。

ここで役割を混同してはいけない。クライアントはチャレンジを処理しない選択ができる。認可サーバーは型とポリシーを検証する。RFC 9396に従う認可フローでは、要求された権限がリソース所有者に提示され、所有者は一部だけを許可できる。トークン応答は実際に付与された詳細を返す。最後にリソースサーバーが、そのトークンで具体的操作を認めるかを再判断する。

したがって、リソースサーバーが自分に権限を与える仕組みではない。一方で、単なる再試行でもない。第一の要求から第二の要求までに、クライアントが申請する権限の内容が変わり得るからだ。

最初は一件の照会だったのに、補修オブジェクトが継続的なアクセスを表すかもしれない。単発の支払い失敗に対し、定期支払いのマンデートが提示されることも理論上は区別しなければならない。位置情報や端末状態の変化で、リソースサーバーが別の認証手順や追加属性を求める場合もある。

その差をJSONの長さで測ることはできない。RFC 9396は、各APIがフィールドの意味を決めるため、任意の二つの権限詳細を比較する標準手法はないと明記する。省略したフィールドが広い既定値を呼ぶことも、配列が複数の能力を足し合わせることもある。別の識別子が、権限の対象そのものを変えることもある。

不透明な参照値が教えるのは「候補がある」まで

authorization_referenceは、クライアントが複雑な権限オブジェクトを解釈せずに、既存トークンを探すための工夫である。リソースサーバーは同一または意味的に同等な詳細から安定した値を作ることが推奨される。クライアントは文字列を比較し、一致したトークンを候補として取り出す。

適用範囲は厳しく限定される。参照値は機微情報を漏らしてはならず、クライアントは意味を解析してはならない。別のリソースサーバーでは使えず、単回使用のトークン向けには付けない。

一致しても受理は保証されない。ユーザーが同意を取り消したかもしれず、リスク環境が変化したかもしれない。認可サーバーが要求の一部しか付与していない可能性もある。参照値は検索キーであり、現在の執行判断ではない。

不一致も権限の大小を示さない。草案は、上限100の定期引き落としを許すトークンが、80の要求を満たし得る例を挙げる。この二つは参照値が違っていてよい。包摂関係は型固有の意味によって決まり、不透明な文字列比較からは導けない。

運用画面で「参照一致」を「認可済み」と表示すれば、検索を判断にすり替えることになる。「参照変更」を理由に自動で次の認可を始めれば、権限の変化を復旧処理の裏に隠すことになる。

スキーマは正しい形を示すが、妥当な目的は示さない

草案のメタデータエンドポイントは、権限詳細の型ごとに説明、文書、例、情報用の版、埋め込みJSON SchemaまたはスキーマURIを提供できる。スキーマは一個のオブジェクトを記述し、typeを対応する識別子に制約する。

これは構築と形式検証に役立つ。だが説明文は認可や検証の根拠にしてはならず、例は非規範的で、版番号は意味バージョン交渉を意味しない。スキーマに合うことは、その要求がユーザーの目的にかなうことや最小権限であることを証明しない。

それでもスキーマの来歴は必要だ。拒否時と認可時で定義が変われば、同じフィールドを別のポリシーが解釈する。URI、埋め込みスキーマのハッシュ、取得時刻、型固有の評価器とその版を残さなければ、後から判断を再現できない。

認可サーバーの選択も記録対象になる。現在の認可サーバーが要求型を扱えないとき、クライアントはProtected Resource Metadataを使って代替先を発見できる。発行者を替えることは単なる接続先変更ではない。クライアント登録、認証、同意表示、データ保持、組織責任の境界が変わり得る。

権限差分記録を四段階で作る

ここで提案する権限差分記録は、新しいOAuthオブジェクトではない。プロトコルを変更せず、補修の周囲に運用証拠を置くためのものだ。

第一段階は拒否を固定する。エンドユーザーセッション、リソースサーバー起点、失敗した操作の種類、安全な要求ダイジェスト、提示したトークンの有効なscopeまたは権限詳細を記録する。口座番号、患者情報、金額などは一般ログへ複写せず、短期の不透明ハンドルやソルト付きコミットメントに置き換える。

第二段階は提案を固定する。復号したauthorization_remediationのハッシュ、要求される効果の最小限の説明、参照値、型、スキーマURIまたはダイジェスト、情報用の版、取得時刻を保存する。型固有の評価器が差分を同等、縮小、拡大、比較不能、不明に分類し、ポリシー版も併記する。

第三段階は処理経路を残す。クライアントが中止したのか、既存トークンを探したのか、新しい認可を開始したのか、ユーザー確認や運用者判断を求めたのか。選択した認可サーバー、表示した同意画面の版、所有者が許可・縮小・拒否した内容、トークン応答が実際に付与した詳細を分ける。

第四段階は結果を結ぶ。参照値とトークンの対応をセッション・起点内に限定して保持しつつ、トークン自体は保存しない。キャッシュ利用と新規認可の試行回数、最終的なリソース判断、業務操作の成功・失敗、取り消しやロールバック先を残す。

この構造なら、リソースサーバーは提案、クライアントは処理、認可サーバーは表示と発行、所有者は選択、業務システムは効果という、自分が観測した事実だけを証明できる。認可成功を業務成功と取り違えずに済む。

監査を理由に別の機微情報台帳を作らない

RARは金融、医療、位置、取引条件を表現し得る。草案は、リソースサーバーが機微データを補修詳細へ入れないことを推奨し、不透明ハンドルの利用を認める。認可サーバーにも、JWTへ詳細を埋め込む前にサイズとプライバシーを検討し、必要なら認証付きイントロスペクションを使うよう促す。

差分記録にも同じ節度が要る。推測しやすい金額を無塩ハッシュにしても匿名化ではない。人が読む要約は効果の種類を示し、保護対象の値を再掲しない。詳細な比較材料は保護ドメイン内に短期間だけ置く。

誰が値を出したかも消してはいけない。リソースサーバーのハンドルはユーザーの陳述ではない。スキーマ説明は同意ではない。トークン内の付与詳細は、画面が理解可能だった証拠ではない。この出所分離が、技術記録の過大解釈を防ぐ。

回数制限だけでなく権限変化にも上限を置く

草案は無限ループを明示的に止める。同じ参照に対しては、キャッシュ済みトークンで一回、新しい認可で一回を推奨し、新しいトークンでも同じ参照が返れば停止する。別の参照なら、実装が決めた上限内で追加の修復を試せる。トークン保管はユーザーセッションごとに分離する。

この回数制限では、異なる参照が段階的に大きな権限を求める状況は捕まらない。そこで運用側は、発行者変更、新しいリソース種別、高影響操作、長い有効期間、継続権限、スキーマ変更、比較不能という意味上の予算を設けるべきだ。

予算を超えたら、自動修復の表示をやめ、新しい判断として説明する。それは相互運用性への反対ではない。同じ権限で送り直す行為と、別の権限を申請してから送り直す行為を区別するだけだ。草案が提案を運び、権限差分記録がその意味を守る。

出典

  1. OAuth RARメタデータと修復の草案
  2. 草案の履歴
  3. ワーキンググループ版00
  4. 前身草案のソースリポジトリ
  5. IETF 126 OAuth議事録
  6. OAuthワーキンググループ
  7. RFC 9396：Rich Authorization Requests
  8. RFC 6750：Bearer Token Usage
  9. RFC 8414：認可サーバーメタデータ
  10. RFC 9728：保護リソースメタデータ
  11. RFC 9470：認証強化チャレンジ
  12. RFC 7662：トークンイントロスペクション
  13. RFC 9068：JWTアクセストークンプロファイル
  14. RFC 9126：Pushed Authorization Requests
  15. RFC 9101：JWT-Secured Authorization Request
  16. IANA OAuthパラメータ
  17. Datatracker APIレコード
  18. 改訂00のテキスト
  19. 改訂00のXMLソース
  20. 先行リポジトリのissue