要約

  • IESG は2026年8月24日、draft-ietf-oauth-rfc8725bis-10を Best Current Practice として承認した。証拠確定時点では RFC Editor の待ち行列にある Internet-Draft であり、刊行されれば RFC 8725 を廃止し、RFC 7519 を更新する。
  • 運用上の核心は、異なる JWT 種別の検証条件を相互排他的にすることだ。正しい署名だけでは足りず、型、発行者、受信者、必須クレーム、保護ヘッダー、アルゴリズム、鍵、アプリケーション文脈が一致しなければならない。

同じ鍵を通った、別の通行証

アカウント異常を受け取るイベント処理系と、API のアクセス制御が同じ発行者を信頼し、同じ公開鍵群を参照しているとする。正規に発行された Security Event Token が API に届く。共通の JWT ライブラリは署名を確認し、成功を返す。

偽造はない。しかし、許可されていない意味が持ち込まれた。

これは特定企業の事故ではなく、境界を調べるための仮想例である。改訂文書が扱う cross-JWT confusion とは、用途の異なるトークンを別の受信環境へ代入する問題だ。攻撃者は秘密鍵を盗む必要がない。受信側が「この発行者の真正な発言」を「この操作への許可」と取り違えればよい。

対策は暗号方式の強化だけではない。イベント受信器とアクセス API は、同じ形式や鍵を利用していても、互いのトークンを受け入れない検証規則を持たなければならない。

承認は刊行や配備と同義ではない

IESG の告知によると、OAuth ワーキンググループによる「JSON Web Token Best Current Practices」第10版は8月24日18時02分 UTC に BCP として承認された。

8月28日の証拠確定時点で、Datatracker は文書を8月21日付、25日更新、2027年2月22日期限の active Internet-Draft と表示していた。IESG 状態は RFC Ed Queue。RFC Editor は未着の参照文献を理由に処理を止めていた。IANA は新規の登録作業を不要としつつ、手続き状況は進行中だった。

したがって、標準化上の決定は完了しているが、RFC 番号、編集完了、実装普及はまだ証明されていない。表題情報どおりに刊行されれば、RFC 8725 を obsolete とし、JWT の基礎仕様 RFC 7519 を update する。

「有効なJWT」を四段階に分解する

JWT はクレームの形式であって、単一の保護方式ではない。JWS 署名、JWE 暗号化、入れ子構造、明示的に許された unsecured JWT があり得る。base64url とピリオドによる compact serialization も、JOSE の JSON serialization と同じではない。

受信側は少なくとも次の四問を順に判定する必要がある。

  1. この入口が許すシリアライズ形式として正しいか。
  2. 受信側が許可したアルゴリズムと所定の鍵で署名または認証付き暗号が検証できるか。
  3. この入口が処理すべきトークン種別か。
  4. 現在時刻、発行者、受信者、主体、要求操作を踏まえてクレームが権限を与えるか。

JWE を復号しただけでは内部 JWT の署名を検証したことにならない。compact 形式を解釈できても信頼は生まれない。JWS の署名が正しくても、同じ鍵を信じる全サービスでクレームが有効になるわけではない。

typ は種別を閉じるためにある

混同の恐れがある場合、改訂案は typ による明示的な型付けを推奨する。RFC 8417 が定める Security Event Token の型は、解釈前にイベントであることを識別する材料になる。一方、一般値 JWT は容器の種類しか示さず、アプリケーション契約を特定しない。

型だけでも十分ではない。異なるトークン検証器は、受け入れる集合を相互排他的にする必要がある。異なる明示型、必須クレームや値、保護ヘッダー、鍵、受信者、発行者のいずれか、または組み合わせで境界を作る。

RFC 9068 は OAuth アクセストークンの JWT profile を、RFC 8417 はセキュリティイベントを規定する。どちらも真正であり得るが、代用可能ではない。クレームの意味を権限に変える前に、受信側が適用 profile を選ぶ。

既存環境では typ のないトークンも多い。一斉必須化は障害になり得るため、まず値が存在する場合の不一致を拒否し、欠落数を計測し、発行側と受信側を段階的に必須化へ移す方法が現実的だ。

発行者と受信者は境界条件である

iss は誰が主張したかを、aud は誰に向けた主張かを示す。存在確認だけでなく、選択した profile に従って一致を調べ、権限判断より前に確定しなければならない。

同じ会社のサービス A と B は、自動的に同じ audience にはならない。同じ ID 基盤を共有していても、A 向けトークンを B へ持ち込める理由にはならない。

sub の意味も一律ではない。人を示す場合も、クライアントやセキュリティイベントの対象を示す場合もある。フィールド名ではなく、トークン種別の契約が意味を決める。

検証方式をトークンに選ばせない

許可アルゴリズムは受信側が固定する。alg は照合対象であり、トークン自身が検証政策を選ぶ命令ではない。さらに一つの鍵を一つのアルゴリズムにだけ結び付け、同じ鍵素材が別方式として再解釈される余地をなくす。

kid、jku、x5u のような鍵選択ヘッダーは、検索や外部取得を動かす入力になる。無制限に SQL や URL へ渡せば、注入やサーバー側リクエスト偽造を招く。署名検証前は攻撃者入力であり、検証後でも発行者へ自由なネットワーク到達性を与えてはならない。

改訂案は、パスワード由来暗号の反復回数、JWE 展開量の上限、RFC 9864 の fully specified algorithm identifiers も扱う。署名偽造だけでなく、資源枯渇やアルゴリズムの曖昧さを制御対象にした点が重要である。

許可の証拠を段階で残す

受信バイト、シリアライズ形式、入口、期待 profile、保護ヘッダー、許可アルゴリズム、解決した鍵とその単一アルゴリズム、暗号結果、型、発行者、受信者、必須クレーム、時間条件、必要な再利用・失効状態、政策判断、要求操作、最終効果を連結して保存する。

「JWT valid」という一行では、正しい profile を選んだか、audience を照合したか、どの操作が実行されたかを証明できない。標準は最小条件を示す。稼働コードが誤種別を拒み、下流効果が生じないことを観測して初めて、境界が実在すると言える。

情報源