要約

  • RFC 9701 は認証済みのリソースサーバーに、発行者・受信者・作成時刻と、入れ子にしたトークン状態を持つ署名済み、必要なら暗号化済みの JWT イントロスペクション応答を渡す。
  • 署名の成功は入力の真正性であり、アクセストークンの代替でも最終許可でもない。型、鮮度、内部 audience と scope、個人データ開示、再利用防止、ローカル規則、実行結果まで別々の受領書が要る。

事故の入口は、壊れた署名ではない。正しい鍵で署名された JWT を、正しい用途とは別の入口が受け入れることである。RFC 9701 の応答はアクセストークンに似ている。どちらもコンパクトな JWT で、iss と aud を持ち得る。しかし前者はトークンについての回答であり、後者は資源への提示物である。

RFC 7662 は、リソースサーバーが認可サーバーにトークン状態を問い合わせる仕組みを定めた。RFC 9701 は普通の JSON 応答に JWT の署名と任意の暗号化を加える。回答者と内容を後から検証できるようにするが、回答を権限そのものへ変えない。

問い合わせる側にも資格が要る

認可サーバーは、イントロスペクションを呼ぶリソースサーバーを識別し、認証し、認可しなければならない。TLS 接続が成立しただけでは不十分である。誰が問い合わせたか、そのサーバーが対象トークンの audience か、どのデータを受け取れるかを結び付ける必要がある。

RFC 7591 の動的登録を使い、リソースサーバーをクライアントとして管理する方法もある。これは一例であり、唯一の実装ではない。重要なのは、資格情報が必要な呼び出しだけに制限され、第三者がトークン情報を引き出せないことである。

無効、期限切れ、失効済み、または呼び出し元向けでないトークンには、内部 active:false だけを返し、他のメンバーを含めてはならない。正の場合も scope はそのリソースサーバーに関係する範囲へ絞るべきで、個人情報は受信者別の方針と法的根拠に従う。

外側の時刻と内側の時刻

要求は Accept: application/token-introspection+jwt を使い、応答もそのメディア型を示す。JWT header の typ は token-introspection+jwt。上位 claim は iss、aud、iat、token_introspection である。

上位 iat は回答が作られた時刻で、内部 iat や exp はトークンの時間軸である。上位 aud はこの回答の受信者、内部 aud はトークンの利用先を示す。同名だから一つに統合できるのではなく、同名だから文脈を保持しなければならない。

RFC 9701 は上位の sub と exp を避けるよう勧め、応答 JWT はトークンの別表現ではないと明記する。IANA OAuth registry、JWT claim registry、media type record は名前を共有するが、実行時の用途判定までは行わない。

暗号化は意味を変更しない

応答は署名、または署名後に暗号化した Nested JWT となる。JWS、JWE、JWT が構造を定める。暗号化に成功すれば、意図した鍵の所持者だけが読めるという性質は強まる。誰にデータを開示してよいか、どの操作を許すかは別である。

RFC 9701 は署名、鍵暗号化、内容暗号化のメタデータを追加する。認可サーバーは RFC 8414 で対応アルゴリズムを公表できる。公表は能力の集合で、個々の応答がどの鍵とポリシーで検証されたかを証明しない。

運用記録には応答 hash、typ、期待 issuer、issuer に結び付いた key set の版、許容 algorithm、実際の alg と kid、署名結果、必要なら受信鍵と復号結果を残す。単一の「JWT OK」では設定ドリフトを追えない。

型の混同は署名を権限へ変える

アクセストークン入口が「あらゆる署名済み JWT」を受け入れると、攻撃者はイントロスペクション応答を資格情報として提示できる。RFC 9701 の専用 typ と入れ子は、この cross-JWT confusion を防ぐためにある。RFC 8725 が求める明示的 typing と用途別検証 rule の具体例である。

各入口は、type、issuer、audience、必須 claims、algorithm を固定した相互排他的 profile を持つべきだ。復号できたことも、署名できたことも、別 profile への昇格を認めない。

また、応答の署名は元のアクセストークンを送信者に結び付けない。RFC 9701 は replay 対策を RFC 9700 に委ねる。proof-of-possession、request binding、token audience は独立して確認する。真正な active:true と、提示者の正当性は別の証拠である。

有効だった事実は残り、現在の権利は消える

上位 iat により応答年齢を計算できる。ただし一律の cache 期限は与えられない。発行後にトークンは失効、満了、scope 変更を受け得る。古い署名は歴史的に正しいままでも、現在の高リスク操作には古すぎる。

リソースサーバーは操作ごとの最大年齢を決める必要がある。低リスク参照と不可逆な更新を同じ cache で扱うべき理由はない。鮮度を超えれば再問い合わせか別の仕組みを使う。

その後にローカル認可がある。scope=write でも対象が凍結中、アカウントが保留、追加承認が必要、地域制限に違反、proof が不正なら拒否できる。許可の後にも実行失敗や rollback があるため、永続した副作用はさらに別の受領書となる。

問い合わせ自体が利用時刻を知らせる

応答は個人情報を含み得る。RFC 9701 は法的根拠と受信者別の制限を要求する。暗号化は盗み見を防いでも、過剰な claim や誤った受信者を正当化しない。RFC 9325 の TLS も同じである。

イントロスペクション要求は、利用者がいつリソースサーバーを使ったかを認可サーバーへ知らせる。これが受け入れられない場合、トークン情報を運ぶ別方式が必要である。形式選択はプライバシー設計でもある。

完成した証拠鎖は、token fingerprint、操作、呼び出し元 identity、認証、endpoint/TLS、response hash、type、key、signature/decryption、外側 claims、内部状態と scope、開示根拠、replay check、local policy、allow/deny、実行と補償を結ぶ。

Lu Heng の最小初期仕様は、共通形式を狭く保ち、信頼、鮮度、プライバシー、認可をローカル判断として見える形にする。reality layers は registry、JWT、署名、状態、判断、結果を分離する。running-code primacy は対応表より実際の validator と enforcement trace を重く見る。

出典