要約

  • RFC9470の要求は、アクセストークンに結び付いた認証イベントの強さと新しさを対象とする。発行時刻は別の時計であり、同じ認可応答に由来するトークンの更新だけで認証情報は新しくならない。
  • 資源側は、選んだ検証方法を通して実際の認証情報を評価する必要がある。拡張は、要求された認証コンテキストを満たすか、満たせないことを明確に返すことを勧め、不十分なトークンの繰り返しを避ける。
  • トークンの有効性、認証条件、許可範囲、処理の完了は別の判断である。共通の契約はOAuthを認証プロトコルへ変えるものではなく、すべての操作に中央の追加許可を求めるものでもない。

更新の実績と、認証の実績を分ける

運用報告に「資格情報の更新は正常」と書かれていても、資源が必要とする事実は別かもしれない。ある想定環境で、クライアントは以前の認可応答に由来する新しいトークンを受け取り続ける。利用者の新しい能動的な認証イベントはない。資源は直近の認証を求めている。更新の報告は正確でも、その条件が満たされたとはまだいえない。

これは特定製品で本稿が発見した故障ではない。何を「新しい」と呼んでいるのかを確かめるための仮定だ。トークン自体が新しく、利用者イベントはより古いという状態は区別できる。逆に、実際のイベントが資源の条件を既に満たすなら、すべての操作で新しい認証画面を出す必要があるとは導けない。具体的な条件と証拠が判断の対象になる。

2023年9月のRFC9470は、OAuthの追加認証を求めるチャレンジの方法を定める。アクセストークンに関連する認証イベントが、強さや経過時間の条件を満たさないと資源が伝えられる。ただし、認証そのものの仕組みは別の層に依存する。文書はOAuthを認証プロトコルとして位置付けるために使ってはならないと明記している。

その境界は言葉の省略も制限する。新しい認可要求を送ることは、利用者の新しい認証を常に意味しない。新しいトークンが戻ることは、指定した条件の達成を保証しない。条件を満たすことも、操作が許可され、実行されたことの代わりにはならない。それぞれの成功報告がどの事実を述べるのか、区別する必要がある。

JWTのiatは発行側の時計を表す。RFC7519ではJWTが発行された時刻であり、その年齢の判定に使える。利用者が最後に能動的に認証された時刻ではない。一般仕様での任意性を、個別プロファイルの要求より優先してよいわけでもない。正しく検証された発行時刻があっても、欠けた認証時刻をそこから作ることはできない。

RFC9068は、関係する認可でauth_time、acr、amrといった認証情報を載せられるとする。値は同じ認可応答から派生するトークン間で固定され、更新や交換で新しいトークンを得た場合も同じである。RFC9470もauth_timeとacrについて認証時点と更新を分ける。ただし、同じ応答に由来するという範囲を残さなければならない。利用者が本当に新しい認証を行ったなら、それは別の証拠だ。

したがって、更新そのものを否定する議論ではない。自動化はサービスの継続に役立ち、ほかの保護策とも組み合わせられる。問題は、資格情報を再び作っただけで、繰り返されていないイベントの時刻を新しく見なすことだ。資源がイベントの新しさを必要とするなら、発行の実績ではなく、そのイベントについて説明できる情報が要る。

資源は何を要求しているのか

insufficient_user_authenticationは、資源の認証要件を満たさないことを表す。トークンの期限切れや許可範囲の不足と、いつでも同じ診断になるわけではない。チャレンジにはacr_valuesで受け入れる認証コンテキストのクラスを優先順に並べ、max_ageで能動的な認証からの許容経過秒数を示せる。両方があってもよい。許可範囲も足りないなら、参照するBearerの規則に沿ってscopeを示すこともできる。

クラスの名前は、認証方法を実行するものではない。OpenID Connect Coreは、値の意味について当事者の合意を求め、意味が文脈に依存し得ることを示す。標準フィールドに収まった文字列だけで、特定の方法や世界共通の保証水準が証明されるわけではない。資源が何を受け入れ、認可サーバーが何によって満たせるのかを理解する必要がある。

max_ageが指すのは、非負の整数で表す能動的なイベントからの秒数である。最後に発行されたトークンの年齢ではない。最新の発行情報を見ただけでは、その経過時間を検証したとはいえない。ここで示しているのは証拠の対象であって、現行サービスの脆弱性の判定ではない。

クライアントは、実際に示されたパラメータを認可要求へ反映することが勧められる。条件を正しく運ぶことは有用だが、達成されたこととは違う。転送、画面の遷移、トークンの受領が順調でも、資源側が返された認証情報を評価する仕事は残る。連続した処理の見た目が一つの成功でも、証拠まで一つになるわけではない。

達成できないなら、失敗を見える結果にする

OpenID Connect Coreの一般的なacr_valuesは、任意提供の属性を求める扱いになる。ID Tokenでのコンテキスト処理を、どんな希望水準も必ず達成するという保証に広げることはできない。max_ageでは、許容時間を超えた場合に能動的な再認証を試み、返すID Tokenへauth_timeを含める必要がある。しかし、ID Tokenの規則は、任意のアクセストークンの内容を証明する規則ではない。

RFC9470は、この拡張に従うサーバーのアクセストークンで、対応する要求にacrとauth_timeを伴わせる振る舞いを述べる。とりわけ、要求されたacrを成功に必要なものとして扱うことを勧める。達成した値を返すか、達成できなければunmet_authentication_requirementsで失敗する。不十分なトークンを何度も返し、クライアントを資源からの再要求の循環に置くことを避けるためだ。

どちらの方向にも過大な読み方はある。単なる無視可能な希望にすぎないと説明すれば、アクセストークンについての推奨を弱める。チャレンジが来れば必ず強い認証に成功すると説明すれば、保証していない結果を加える。明確な失敗は、達成されなかった条件への適切な応答になり得る。OpenIDのエラー拡張は、その結果を伝えるもので、許可範囲や操作完了を作るものではない。

仮定上の繰り返しは、達成できないクラス、経過時間を裏付けない情報、両者が調整できない条件から生じるかもしれない。本稿は、そのような配備を観察していない。これらの可能性が示すのは、新しいトークンの時刻だけでは原因を区別できないことだ。サービスの組は、何を満たせるか、どこで試行が終わるかを説明する必要がある。

失敗の明示は運用上の責任にも関わる。認可サービスにとっては発行が成功でも、資源にとっては使えないものが戻っている。別々の成功を一つの進捗に数えると、条件未達の状態が隠れる。利用者の体験を改善することと、正確な結果を残すことを切り離してはいけない。無理な条件を別の資格情報で覆うのではなく、到達できなかったと読めることが大切だ。

証拠を運ぶ二つの方法

RFC9470は、JWTアクセストークンの検証とOAuthのトークンイントロスペクションという二つの一般的な方法に認証情報を結び付ける。ほかの符号化と検証方法も選べるが、この文書の範囲外である。情報が必要であることと、全利用者が一つの運用形態に従うことは違う。

JWTのauth_timeやacrを読むだけでは、資格情報の検証を置き換えられない。適用するプロファイルの発行者、対象の受け手などの確認が残り、その上でイベントの意味を評価する。信頼されていない入力の値が、見慣れたフィールド名だけで証拠になるわけではない。この説明は概念上の境界であり、特定実装の安全性監査ではない。

イントロスペクションのactive:trueも、すべての方針を満たすという省略記号ではない。トークンが有効な状態でも、イベントが古すぎたり、コンテキストが受け入れられなかったりする。RFC7662の状態・メタデータに、RFC9470が認証イベントの応答項目を加える。単純な有効状態とは別に、その項目を評価しなければならない。

この選択肢から、すべての操作でオンラインの中央機関へ問い合わせる義務は出てこない。JWTがあるからオフライン確認がいつでも十分だともいえない。配備は責任とほかの条件に見合う経路を選ぶ。共通契約は、何を説明するかを定めながら、全資源の運転方法を一つに固定しなくてもよい。

認可サーバーのメタデータにあるacr_values_supportedは、RFC9470では関係する要求パラメータを理解し、尊重するという能力の告知になる。それは個別イベントの成功記録ではなく、実際の経過時間や操作結果でもない。能力の一覧、イベントの証拠、資源の結果は、同じ提供者に見えても別の対象だ。

条件を満たしても、新しい許可にはならない

OAuthの更新では、もとの認可で与えられた範囲を超えるscopeを要求してはならず、省略すればもとの範囲を維持する。トークンを得る接続でクライアントを認証することも、利用者本人の直近の認証とは別である。自動的な取引の成功だけで、新しい利用者イベントや権限の拡大が証明されるわけではない。

資源は認証の質をアクセス条件に使えるが、それが判断のすべてではない。有効性、受け手、許可範囲、コンテキスト、経過時間は別に問われ得る。一つを満たしてもほかの条件は生まれない。必要な条件を満たしたとしても、要求された操作が実際に完了した証拠にはならない。成功の報告は、どの対象について述べるかを明らかにする必要がある。

RFC9470は、資源と認可サーバーの組の方針に具体的な制約を課すことを範囲外とする。利用者が満たせない要求や、望ましくない体験が起き得る。特定の機器など、条件の達成に必要な実際の手段も、クラスの名前だけでは決まらない。条件を伝えられることは、誰でも達成できることの保証ではない。

チャレンジ自体も、入力トークンの検証済みを証明しない。文書は通常の検証の前後どちらでも判定でき、まず有効なトークンを確認しなくてもチャレンジを返せるとする。その場合、まだ資格情報を得られると示していない相手へ要求の性質を知らせる影響がある。順序には選択と結果があり、本稿が一律の正解を作るものではない。

認証コンテキストの違いから、特権利用者などの手掛かりが漏れる可能性も記される。資源が利用者の操作を引き起こせる機能は、悪意のある資源に悪用され得る。本稿は攻撃や被害を観測していない。資料が示すのは注意すべき仕組みであり、現行サービスでの発生率ではない。

RFC9700の更新されたOAuthセキュリティの背景も、認証時刻を新しくするものではない。更新用トークンのローテーションや、資格情報の保護強化はそれぞれの問題に対応する。役に立つ対策が、別のイベントの証拠まで兼ねるとは限らない。複数の保護策を組み合わせるときも、その違いは残る。

Lu Hengが示す最小の初期仕様、将来判断の局所化、自発的な採用は、編集上の参照になる。共通層は要求とイベント情報を理解可能にする。適切な資源とサービスの組は、具体的な方針と達成可能な条件を説明する。採用者はそれを見て選ぶ。すべての操作に追加の中央許可を置かずとも、局所的な責任を見えるものにできる。

新しいトークンは、適切な判断に使われ得る。しかし、新しい認証イベント、条件の達成、操作完了の代わりではない。共有された語彙の利点は、違いを失わずに協調できることにある。発行の時計にすべての判断を委ねないことが、その限定された利点を守る。

参照資料