JSON Web Token Best Current Practices

draft-ietf-oauth-rfc8725bis-03

Abstract

JSON Web Token（JWT とも呼ばれる）は、URL セーフな JSON ベースのセキュリティトークンであり、署名および／または暗号化できる一連のクレームを含みます。JWT は、デジタルアイデンティティの領域およびその他のアプリケーション領域の双方における多数のプロトコルやアプリケーションで、シンプルなセキュリティトークン形式として広く利用され、展開されています。この Best Current Practices（BCP）仕様は RFC 7519 を更新し、JWT の安全な実装および展開につながる実行可能なガイダンスを提供します。

さらに、この BCP 仕様は既存の JWT BCP 仕様である RFC 8725 を置き換え、RFC 8725 の公開以降に発見された脅威や攻撃を対象とした追加の実行可能なガイダンスを提供します。

About This Document

この注記は RFC として公開する前に削除されます。

本文書のステータス情報は次の場所にあります。\ https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc8725bis/。

本文書に関する議論は、Web Authorization Protocol Working Group のメーリングリスト（mailto:oauth@ietf.org）で行われます。アーカイブは https://mailarchive.ietf.org/arch/browse/oauth/ にあります。\ 購読は https://www.ietf.org/mailman/listinfo/oauth/ で行えます。

このドラフトのソースおよび Issue トラッカーは次で確認できます。\ https://github.com/oauth-wg/draft-ietf-oauth-rfc8725bis。

Status of This Memo

この Internet-Draft は BCP 78 および BCP 79 の規定に完全に適合する形で提出されています。

Internet-Draft は Internet Engineering Task Force（IETF）の作業文書です。なお、他のグループも Internet-Draft として作業文書を配布する場合があります。現在の Internet-Draft の一覧は https://datatracker.ietf.org/drafts/current/ にあります。

Internet-Draft は最長 6 か月間有効なドラフト文書であり、いつでも更新、置換、または他の文書によって廃止される場合があります。Internet-Draft を参照資料として使用したり、「進行中の作業（work in progress）」以外として引用したりすることは不適切です。

この Internet-Draft は 2026 年 7 月 16 日に失効します。

Copyright Notice

Copyright (c) 2026 IETF Trust および文書著者として識別される者。All rights reserved.

本文書は、本文書の公開日に有効な BCP 78 および IETF Trust の「IETF 文書に関する法的規定（Legal Provisions Relating to IETF Documents）」（https://trustee.ietf.org/ license-info）の対象です。これらの文書には本文書に関する権利および制限が記載されているため、注意深く確認してください。本書から抽出されたコード構成要素には、Trust Legal Provisions の 4.e 節で説明されている Revised BSD License の文言を含めなければならず、Revised BSD License に記載のとおり無保証で提供されます。

Table of Contents

• JSON Web Token Best Current Practices
  • Abstract
  • About This Document
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
    • 1.1. Target Audience
    • 1.2. Conventions Used in this Document
  • 2. Threats and Vulnerabilities
    • 2.1. Weak Signatures and Insufficient Signature Validation
    • 2.2. Weak Symmetric Keys
    • 2.3. Incorrect Use and Composition of Encryption and Signature
    • 2.4. Plaintext Leakage through Analysis of Ciphertext Length
    • 2.5. Insecure Use of Elliptic Curve Encryption
    • 2.6. Multiplicity of JSON Encodings
    • 2.7. Substitution Attacks
    • 2.8. Cross-JWT Confusion
    • 2.9. Indirect Attacks on the Server
    • 2.10. Computation Cost of Unreasonable Number of Hash Iterations
    • 2.11. Algorithm Verification Code Not Defensively Written
    • 2.12. JWE Decompression Bomb Attack
    • 2.13. JWT Format Confusion
  • 3. Best Practices
    • 3.1. Perform Algorithm Verification
    • 3.2. Use Appropriate Algorithms
    • 3.3. Validate All Cryptographic Operations
    • 3.4. Validate Cryptographic Inputs
    • 3.5. Ensure Cryptographic Keys Have Sufficient Entropy
    • 3.6. Avoid Compression of Encryption Inputs
    • 3.7. Use UTF-8
    • 3.8. Validate Issuer and Subject
    • 3.9. Use and Validate Audience
    • 3.10. Do Not Trust Received Claims
    • 3.11. Use Explicit Typing
    • 3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs
    • 3.13. Limit Hash Iteration Count
    • 3.14. Check JWT Format Type
    • 3.15. Limit JWE Decompression Size
  • 4. Security Considerations
  • 5. IANA Considerations
  • 6. Acknowledgements
    • 6.1. Acknowledgements for RFC 8725
    • 6.2. Acknowledgements for [[ this specification ]]
  • 7. References
    • 7.1. Normative References
    • 7.2. Informative References
  • Appendix A. Changes from RFC 8725
  • Appendix B. Document History
    • B.1. draft-ietf-oauth-rfc8725bis-03
    • B.2. draft-ietf-oauth-rfc8725bis-02
    • B.3. draft-ietf-oauth-rfc8725bis-01
    • B.4. draft-ietf-oauth-rfc8725bis-00
    • B.5. draft-sheffer-oauth-rfc8725bis-02
    • B.6. draft-sheffer-oauth-rfc8725bis-01
    • B.7. draft-sheffer-oauth-rfc8725bis-00
  • Authors' Addresses

1. Introduction

JSON Web Token（JWT とも呼ばれる）[RFC7519] は、URL セーフな JSON ベースのセキュリティトークンであり、署名および／または暗号化できる一連のクレームを含みます。JWT 仕様が急速に採用されたのは、セキュリティに関係する情報を 1 つの保護しやすい場所に集約できること、そして広く入手可能なツールを用いて容易に実装できることによります。JWT が一般的に利用される適用領域の 1 つは、OAuth 2.0 Access Token [RFC9068] のような認可情報や、OpenID Connect ID Token [OpenID.Core] のようなアイデンティティ情報を表現することです。これらの利用の詳細は、アプリケーションおよび展開環境に依存します。

JWT 仕様が公開されて以来、実装および展開に対する攻撃がいくつか広く公表されてきました。そのような攻撃は、セキュリティ機構の仕様が十分に定められていないこと、ならびに実装が不完全であることやアプリケーションによる使い方が誤っていることに起因します。

本文書の目的は、JWT の安全な実装および展開を促進することです。本書の推奨事項の多くは、JSON Web Signature（JWS）[RFC7515]、JSON Web Encryption（JWE）[RFC7516]、および JSON Web Algorithms（JWA）[RFC7518] により定義される、JWT の基盤となる暗号メカニズムの実装と利用に関するものです。その他は、JWT のクレーム自体の利用に関するものです。

これらは、実装および展開の大多数のシナリオにおける JWT 利用に対して、最小限の推奨事項となることを意図しています。本書を参照する他の仕様は、その個別の状況に基づいて、形式の 1 つ以上の側面に関してより厳格な要件を持つ場合があります。その場合、実装者はそれらのより厳格な要件に従うことが推奨されます。さらに、本書は上限ではなく下限を提供するものなので、より強力な選択肢は常に許容されます（たとえば、暗号強度の重要性と計算負荷の重要性の評価が異なる場合など）。

さまざまなアルゴリズムの強度や実行可能な攻撃に関するコミュニティの知見は急速に変化し得ます。また、セキュリティに関する Best Current Practice（BCP）文書は特定時点の見解に過ぎないことが経験的に示されています。読者は、本書に適用される正誤表（errata）や更新情報がないかを確認することが推奨されます。

1.1. Target Audience

本文書の想定読者は以下です。

• 実装者：JWT ライブラリ（およびそれらが利用する JWS および JWE ライブラリ）
• 実装者：そのようなライブラリを利用するコード（ある種のメカニズムはライブラリによって提供されない可能性があること、または提供されるようになるまでの期間があることを考慮した範囲で）
• 策定者：IETF の内外を問わず、JWT に依存する仕様

1.2. Conventions Used in this Document

本文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で記載されている場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているとおりに解釈されます。

2. Threats and Vulnerabilities

この節では、JWT の実装および展開における既知および潜在的な問題をいくつか列挙します。各問題の説明の後には、その問題に対する 1 つ以上の緩和策への参照を示します。

2.1. Weak Signatures and Insufficient Signature Validation

署名付き JSON Web Token は、暗号アルゴリズムの柔軟な切り替え（cryptographic agility）を容易にするため、「alg」Header Parameter の形で署名アルゴリズムを明示的に示します。これが、一部のライブラリやアプリケーションにおける設計上の欠陥と相まって、いくつかの攻撃につながりました。

• アルゴリズムが攻撃者によって「none」に変更され、一部のライブラリはこの値を信頼し、署名を一切確認せずに JWT を「検証」してしまう。
• 「RS256」（RSA、2048 bit）というパラメータ値が「HS256」（HMAC、SHA-256）に変更され、一部のライブラリが HMAC-SHA256 を用いて署名を検証しようとし、さらに RSA の公開鍵を HMAC の共有秘密鍵として用いてしまう（[McLean] および [CVE-2015-9235] を参照）。

緩和策については Section 3.1 および Section 3.2 を参照してください。

2.2. Weak Symmetric Keys

さらに、一部のアプリケーションは、「HS256」のような鍵付き Message Authentication Code（MAC）アルゴリズムを用いてトークンに署名しますが、エントロピーが不十分な弱い対称鍵（人が覚えられるパスワードなど）を与えています。そのような鍵は、攻撃者がそのトークンを入手すると、オフラインでの総当たり攻撃や辞書攻撃に対して脆弱です [Langkemper][JWT-Cracker]。

緩和策については Section 3.5 を参照してください。

2.3. Incorrect Use and Composition of Encryption and Signature

ほとんどの認証ユースケースでは、トークンとして単純な署名付き JWT だけで十分です。しかし、検証者が、受信した JWT が JWE（暗号化された構造を持つ JWT）ではなく JWS（署名付き JWT）であることを常に確認しているとは限りません。その結果、検証者側のライブラリが「復号に成功した」ことと「署名検証に成功した」ことを区別しない場合、脆弱性につながる可能性があります [CVE-2023-51774]。

機密性が必要となる、より複雑なユースケースでは、JWE で暗号化された JWT を復号して JWS 署名されたオブジェクトを得るライブラリの中に、内部の署名を必ずしも検証しないものがあります。

緩和策については Section 3.3 を参照してください。

2.4. Plaintext Leakage through Analysis of Ciphertext Length

多くの暗号アルゴリズムは、平文の長さに関する情報を漏えいさせます。その漏えい量は、アルゴリズムや動作モードによって異なります。JWE はこの漏えいに対して脆弱です。この問題は、平文が最初に圧縮されている場合に悪化します。圧縮後の平文、したがって暗号文の長さは、元の平文の長さだけでなく内容にも依存するためです。圧縮攻撃は、秘密データと同じ圧縮空間に攻撃者が制御できるデータが存在する場合に特に強力になります。これは HTTPS に対するいくつかの攻撃で該当します。

圧縮と暗号化に関する一般的な背景は [Kelsey] を参照してください。また HTTP Cookie に対する攻撃の具体例は [Alawatugoda] を参照してください。

緩和策については Section 3.6 を参照してください。

2.5. Insecure Use of Elliptic Curve Encryption

[Sanso] によれば、複数の Javascript Object Signing and Encryption（JOSE）ライブラリは、楕円曲線鍵共有（「ECDH-ES」アルゴリズム）を実行する際に入力の正当性検証を正しく行っていません。攻撃者が、無効な曲線上の点を用いた任意の JWE を送信でき、かつその無効な点による復号結果として得られる平文出力を観測できる場合、この脆弱性を利用して受信者の秘密鍵を回復できる可能性があります。

緩和策については Section 3.4 を参照してください。

2.6. Multiplicity of JSON Encodings

廃止された [RFC7159] のような以前の JSON 形式では、UTF-8、UTF-16、UTF-32 といった複数の文字エンコーディングが許容されていました。しかし最新の標準 [RFC8259] では、「閉じたエコシステム」内での内部利用を除き UTF-8 のみが許容されます。古い実装や閉じた環境で利用される実装が非標準のエンコーディングを生成し得るというこの曖昧さにより、JWT が受信者によって誤って解釈される可能性があります。結果として、悪意のある送信者が受信者の検証チェックを回避するためにこれを悪用する可能性があります。

緩和策については Section 3.7 を参照してください。

2.7. Substitution Attacks

ある受信者が、自身のために意図され発行された JWT を受け取り、それを本来意図されていない別の受信者に対して使用しようとする攻撃があります。たとえば、OAuth 2.0 [RFC6749] の Access Token が、本来の対象である OAuth 2.0 により保護されたリソースに正当に提示された場合、その保護リソースが、アクセスを得ようとして、その同じ Access Token を本来の対象ではない別の保護リソースに提示してしまうことがあります。このような状況が検出されないと、攻撃者が権限のないリソースにアクセスできる結果となり得ます。

緩和策については Section 3.8 および Section 3.9 を参照してください。

2.8. Cross-JWT Confusion

JWT がより多くのプロトコルで多様な方法で利用されるようになるにつれ、ある目的のために発行された JWT トークンが別の目的で利用されることを防ぐ重要性が増しています。これは代替攻撃（substitution attack）の一種です。JWT が、別種の JWT と混同され得るアプリケーション文脈で利用される可能性がある場合、これらの代替攻撃を防ぐための緩和策を講じなければなりません（MUST）。

緩和策については Section 3.8、Section 3.9、Section 3.11、および Section 3.12 を参照してください。

2.9. Indirect Attacks on the Server

さまざまな JWT クレームが、データベース検索や Lightweight Directory Access Protocol（LDAP）検索など、受信者による参照（lookup）処理に用いられます。ほかにも、サーバーが同様に参照する URL を含むものがあります。これらのいずれのクレームも、攻撃者がインジェクション攻撃や server-side request forgery（SSRF）攻撃のベクトルとして悪用する可能性があります。

緩和策については Section 3.10 を参照してください。

2.10. Computation Cost of Unreasonable Number of Hash Iterations

PBES2 暗号化アルゴリズムにおける p2c（PBES2 Count）ヘッダーパラメータは、実行される反復ハッシュ計算の回数を指定します。攻撃者は非常に大きな回数を指定することで、受信者に不合理な計算負荷を強いることができます。

緩和策については Section 3.13 を参照してください。

2.11. Algorithm Verification Code Not Defensively Written

一部の JWT 実装には、たとえば「none」を使用しない、といった禁止アルゴリズム名のリストが含まれていました。しかしこれらの同じアプリケーションは、トークンを解析する際に JOSE 仕様を誤って解釈し、アルゴリズム値を大文字・小文字を区別しないものとして読み取っていました。その結果、攻撃者は「alg」値を「noNE」に変更し、セキュリティチェックを回避できました。

緩和策については Section 3.1 を参照してください。

2.12. JWE Decompression Bomb Attack

JWE は、[RFC7516] Section 4.1.3 で定義される「zip」ヘッダーパラメータにより、暗号化前の平文を任意に圧縮することをサポートします。復号後、受信者はさらなる処理の前にペイロードを展開することが想定されています。しかし受信者が展開後の出力サイズに上限を課さない場合、攻撃者は高圧縮で任意に大きなペイロードを持つ悪意ある JWE を作成できます。これにより過剰なリソース消費（CPU、メモリ）が引き起こされ、サービス拒否（DoS）につながります。

緩和策については Section 3.15 を参照してください。

2.13. JWT Format Confusion

一部の JWS 実装は Compact および JSON の両方の Serializations をサポートします。JWT は Compact Serialization を使用しなければなりません（MUST）が、アプリケーションが誤って JSON Serialization を用いて JWT を検証し、しかしクレームの抽出は Compact Serialization として（たとえば文字列分割で）解析して行う場合、攻撃者は偽造されたペイロードを含む有効な JSON JWS を作成できます。この形式処理の不一致は、認証回避やなりすましにつながる可能性があります。

緩和策については Section 3.14 を参照してください。

3. Best Practices

以下に示すベストプラクティスは、前節で列挙した脅威を緩和するために実務者が適用すべきものです。

3.1. Perform Algorithm Verification

ライブラリは、呼び出し側がサポートされるアルゴリズムの集合を指定できるようにしなければならず（MUST）、暗号操作を実行する際にそれ以外のアルゴリズムを用いてはなりません（MUST NOT）。ライブラリは、「alg」または「enc」ヘッダーが、暗号操作に用いられるアルゴリズムと同一のアルゴリズムを指定していることを保証しなければなりません（MUST）。さらに、各鍵は厳密に 1 つのアルゴリズムでのみ使用されなければならず（MUST）、暗号操作が実行される際にその点を確認しなければなりません（MUST）。

ライブラリは、JSON パーサーなどの基盤インフラに潜在的な問題がある場合に備えて、防御的なセキュリティポリシーを選ぶべきです（SHOULD）。特に、ライブラリは「alg」のような重要パラメータに対して、ブロックリストではなく許可リスト（allowlists）を使用すべきです（SHOULD）。

3.2. Use Appropriate Algorithms

[RFC7515] の Section 5.2 では、「ある文脈でどのアルゴリズムを使用できるかはアプリケーションの判断である。JWS が成功裏に検証できたとしても、JWS で用いられたアルゴリズムがアプリケーションにとって受け入れ可能でない限り、アプリケーションは JWS を無効とみなすべきである（SHOULD）」と述べています。

したがって、アプリケーションは、アプリケーションのセキュリティ要件を満たす、現時点で暗号学的に妥当なアルゴリズムの使用のみを許可しなければなりません（MUST）。この集合は、新しいアルゴリズムの導入や、暗号上の弱点が発見された既存アルゴリズムの非推奨化により、時間とともに変化します。したがって、アプリケーションは暗号の柔軟な切り替え（cryptographic agility）を可能にするよう設計されなければなりません（MUST）。

「none」アルゴリズムは、JWT が他の手段によって暗号学的に保護されている場合にのみ使用すべきです。JWT で「none」を使用するケースは、内容が任意に署名されるアプリケーション文脈でしばしば利用されます。その文脈では、URL セーフなクレーム表現と処理は、署名付きの場合と署名なしの場合で同一にできます。JWT ライブラリは、呼び出し側から明示的に要求された場合を除き、「none」を使用する JWT を生成すべきではありません（SHOULD NOT）。同様に、JWT ライブラリは、呼び出し側から明示的に要求された場合を除き、「none」を使用する JWT を受理すべきではありません（SHOULD NOT）。

アプリケーションは、以下のアルゴリズム固有の推奨に従うべきです（SHOULD）。

• すべての RSA-PKCS1 v1.5 暗号化アルゴリズム（[RFC8017] Section 7.2）を避け、RSAES-OAEP（[RFC8017] Section 7.1）を優先する。
• Elliptic Curve Digital Signature Algorithm（ECDSA）署名 [ANSI-X962-2005] は、署名される各メッセージごとに一意な乱数値を必要とします。複数メッセージにわたりその乱数値のわずかなビットであっても予測可能である場合、署名方式の安全性が損なわれる可能性があります。最悪の場合、攻撃者によって秘密鍵が回復され得ます。これらの攻撃に対抗するため、JWT ライブラリは [RFC6979] で定義される決定論的アプローチを用いて ECDSA を実装すべきです（SHOULD）。このアプローチは既存の ECDSA 検証者と完全に互換であり、新たなアルゴリズム識別子を必要とせずに実装できます。

読者は、[I-D.ietf-jose-deprecate-none-rsa15] が、RFC となる段階で「none」および「RSA1_5」アルゴリズムに関する追加ガイダンスを提案する意図であることを知っておくとよいでしょう。

3.3. Validate All Cryptographic Operations

JWT で使用されるすべての暗号操作は検証されなければならず（MUST）、そのいずれかが検証に失敗した場合は JWT 全体を拒否しなければなりません（MUST）。これは、単一の Header Parameters 集合を持つ JWT だけでなく、[RFC7519] Section 2 で定義される Nested JWT にも当てはまり、外側と内側の両方の操作が、アプリケーションにより与えられた鍵とアルゴリズムを用いて検証されなければなりません（MUST）。

ライブラリは、検証者が署名付き JWT（JWS）と暗号化された JWT（JWE）を区別できるようにしなければなりません（MUST）。これにより検証者は、署名付き JWT のみを受け入れるというポリシーを容易に確立できます。

3.4. Validate Cryptographic Inputs

Elliptic Curve Diffie-Hellman 鍵共有（「ECDH-ES」）のような一部の暗号操作は、無効な値を含み得る入力を取ります。これには、指定された楕円曲線上にない点やその他の無効な点が含まれます（例： [Valenta] Section 7.1）。JWS/JWE ライブラリ自体が、使用する前にこれらの入力を検証しなければならないか、または検証を行う基盤暗号ライブラリを利用しなければなりません（あるいはその両方が必要です）。

Elliptic Curve Diffie-Hellman Ephemeral Static（ECDH-ES）の ephemeral 公開鍵（epk）入力は、受信者が選択した楕円曲線に従って検証されるべきです。NIST の素数位数曲線 P-256、P-384、P-521 については、「Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography」[nist-sp-800-56a-r3] の Section 5.6.2.3.4（ECC Partial Public-Key Validation Routine）に従って検証が実施されなければなりません（MUST）。「X25519」または「X448」[RFC8037] アルゴリズムが使用される場合は、[RFC8037] のセキュリティ考慮事項が適用されます。

3.5. Ensure Cryptographic Keys Have Sufficient Entropy

[RFC7515] Section 10.1 の Key Entropy and Random Values に関する助言と、[RFC7518] Section 8.8 の Password Considerations は、遵守されなければなりません（MUST）。特に、人が覚えられるパスワードは、「HS256」のような鍵付き MAC アルゴリズムの鍵として直接使用してはなりません（MUST NOT）。さらに、パスワードは、[RFC7518] Section 4.8 で説明されるとおり、コンテンツ暗号化ではなく鍵暗号化を行うためにのみ使用すべきです。なお、鍵暗号化に使用する場合でも、パスワードベース暗号は依然として総当たり攻撃の対象となります。

3.6. Avoid Compression of Encryption Inputs

[Kelsey] で説明されるとおり、そのような圧縮データはしばしば平文に関する情報を漏えいさせるため、JWE を作成する際にはデータ圧縮を使用すべきではありません（SHOULD NOT）。

3.7. Use UTF-8

[RFC7515]、[RFC7516]、および [RFC7519] はすべて、Header Parameters および JWT Claims Sets で使用される JSON のエンコードとデコードに UTF-8 を使用することを規定しています。これは最新の JSON 仕様 [RFC8259] とも整合します。実装およびアプリケーションはこれに従わなければならず（MUST）、これらの目的に他の Unicode エンコーディングを使用したり使用を許可したりしてはなりません（MUST NOT）。

3.8. Validate Issuer and Subject

JWT が「iss」（issuer）クレームを含む場合、アプリケーションは、その JWT の暗号操作に用いられた暗号鍵が issuer に属していることを検証しなければなりません（MUST）。もし属していない場合、アプリケーションは JWT を拒否しなければなりません（MUST）。

issuer が所有する鍵を決定する方法は、アプリケーションに依存します。1 つの例として、OAuth 2.0 Authorization Server の「issuer」値 [RFC8414] は「https」URL であり、「jwks_uri」値（issuer の鍵が JWK Set [RFC7517] として取得される「https」URL）を含む JSON メタデータ文書を参照します。この同じ仕組みは OpenID Connect [OpenID.Core] でも使用されます。ほかのアプリケーションは、issuer と鍵を結び付ける別の手段を使用する場合があります。

同様に、JWT が「sub」（subject）クレームを含む場合、アプリケーションは subject 値が、そのアプリケーションにおける有効な subject、および／または issuer-subject の組に対応することを検証しなければなりません（MUST）。これには、issuer がアプリケーションから信頼されていることの確認が含まれる場合があります。OAuth の文脈では、[RFC9700] Section 4.15 が、ユーザー識別子と client ID 値が混同される可能性について論じています。issuer、subject、またはその組が無効である場合、アプリケーションは JWT を拒否しなければなりません（MUST）。

3.9. Use and Validate Audience

同一の issuer が、1 つ以上の relying party またはアプリケーションでの利用を意図した JWT を発行できる場合、あるいは将来的に発行する可能性がある場合、JWT は「aud」（audience）クレームを含まなければなりません（MUST）。このクレームにより、JWT が意図された当事者によって使用されているのか、それとも攻撃者によってすり替えられたのかを判定できます。

そのような場合、relying party またはアプリケーションは audience 値を検証しなければなりません（MUST）。audience 値が存在しない場合、または値のいずれも受信者と関連付けられていない場合、JWT を拒否しなければなりません（MUST）。

3.10. Do Not Trust Received Claims

「kid」（key ID）ヘッダーは、relying application が鍵の参照（lookup）を行うために使用されます。アプリケーションは、受信した値を検証および／またはサニタイズすることで、これが SQL や LDAP のインジェクション脆弱性を引き起こさないようにすべきです。

同様に、任意の URL を含み得る「jku」（JWK set URL）または「x5u」（X.509 URL）ヘッダーに盲目的に従うことは、server-side request forgery（SSRF）攻撃を招く可能性があります。アプリケーションは、たとえば許可された場所の allowlist に URL を照合し、GET リクエストで Cookie が送信されないようにするなどにより、そのような攻撃から保護すべきです（SHOULD）。

そのような allowlist が利用できない場合、Authorization Server はホスト名がどの IP に解決されるかを確認し、ループバックまたはローカル IP アドレスに解決される場合はリクエストを回避すべきです（SHOULD）。例として、「attacker.example.com/etc/passwd」が「jwks_uri」値として使用され、「attacker.example.com」に対する DNS エントリが「127.0.0.1」または他のローカル IP アドレス値に解決される場合が挙げられます。

3.11. Use Explicit Typing

JWT の 2 つの異なる用途が共通のクレーム集合を共有する場合、ある種の JWT が別の JWT と混同され得ます。ある特定種の JWT がそのような混同の対象となる場合、その JWT に明示的な JWT type 値を含め、検証ルールで type を確認するように定めることができます。この仕組みにより、そのような混同を防止できます。明示的な JWT の型付けは、「typ」Header Parameter を使用して行います。たとえば [RFC8417] 仕様は、Security Event Token（SET）を明示的に型付けするために「application/secevent+jwt」というメディアタイプを使用しています。

異なる種類の JWT 間の混同を防ぐための場当たり的な手段の例として、Logout Token [OpenID.Backchannel] が「nonce」クレームの含有を禁じている要件が挙げられます。これにより、Logout Token は ID Token [OpenID.Core] の検証ルールに失敗します。明示的な型付けを用いれば、両方の種類の JWT の検証ルールが「typ」値の検証を含み、かつ 2 種類の JWT に受け入れ可能な「typ」値が異なる場合に、このような場当たり的な仕組みを採用する必要がなくなります。

[RFC7515] Section 4.1.9 における「typ」の定義に従い、関連するメディアタイプと比較して「typ」Header Parameter 値から「application/」プレフィックスを省略することが推奨されます（RECOMMENDED）。したがって、たとえば SET の型を明示的に含めるために使用される「typ」値は「secevent+jwt」とすべきです（SHOULD）。

JWT に明示的な型付けを適用する場合、「application/example+jwt」の形式のメディアタイプ名を使用することが推奨されます（RECOMMENDED）。ここで「example」は特定の種類の JWT の識別子に置き換えられます。したがって、たとえば SET のメディアタイプ名は「application/secevent+jwt」とすべきです（SHOULD）。

Nested JWT に明示的な型付けを適用する場合、明示的な type 値を含む「typ」Header Parameter は、Nested JWT の内側の JWT（ペイロードが JWT Claims Set となる JWT）に存在しなければなりません（MUST）。場合によっては、Nested JWT 全体を明示的に型付けするために、同一の「typ」Header Parameter 値が外側の JWT にも存在します。

明示的な型付けの利用は、既存の種類の JWT との曖昧さ解消を達成できない場合があることに注意してください。明示的な型付けに関する [RFC8725] のガイダンスが利用可能になる前に定義された種類の JWT の検証ルールでは、「typ」Header Parameter 値を使用しないことが多いためです。

また、すでに明示的な型付けを使っていない既存の種類の JWT の検証ルールに、必須の明示的な型付けを後付けで導入しようとすると破壊的変更となる点にも注意してください。レガシー実装が明示的な type を含めずに JWT を作成し、更新された実装がそれを受信した際に明示的な type を必須とする場合、その JWT は拒否されます。両実装は相互運用できません。しかし、JWT が「typ」値を含む場合、その値が期待される明示的な type でなければならない（MUST）というルールを後付けすることは、破壊的変更ではありません。

既存の種類の JWT に関する別の考慮事項として、[RFC7519] Section 5.1 で当初推奨されていた「JWT」という「typ」値の使用は、有効な明示的型付けを構成しないことが挙げられます。

新しい JWT の用途では、明示的型付けが推奨されます（RECOMMENDED）。

3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs

JWT の各適用は、必須および任意の JWT クレームと、それらに関連する検証ルールを指定するプロファイルを定義します。同一の issuer によって 2 種類以上の JWT が発行され得る場合、それらの JWT の検証ルールは相互排他的に書かれなければならず（MUST）、誤った種類の JWT を拒否するようにしなければなりません（MUST）。

ある文脈で発行された JWT が別の文脈にすり替えられることを防ぐために、アプリケーション開発者は複数の戦略を採用できます。

• 異なる種類の JWT に対して明示的型付けを使用する。そうすると、異なる「typ」値を用いて異なる種類の JWT を区別できます。
• 必須クレームの集合を変える、または必須クレーム値を変える。そうすると、ある種類の JWT の検証ルールは、異なるクレームまたは値を持つものを拒否します。
• 必須 Header Parameters の集合を変える、または必須 Header Parameter 値を変える。そうすると、ある種類の JWT の検証ルールは、異なる Header Parameters または値を持つものを拒否します。
• 異なる種類の JWT に対して異なる鍵を使用する。そうすると、ある種類の JWT を検証するために用いられる鍵では、別の種類の JWT の検証に失敗します。
• 同一の issuer からの JWT の異なる用途に対して、異なる「aud」値を使用する。そうすると、audience の検証により不適切な文脈にすり替えられた JWT は拒否されます。
• 異なる種類の JWT に対して異なる issuer を使用する。そうすると、異なる「iss」値を用いて異なる種類の JWT を分離できます。

JWT の利用やアプリケーションは非常に多様であるため、異なる種類の JWT を区別するための type、必須クレーム、値、Header Parameters、鍵の用途、issuer の最適な組み合わせは、一般にアプリケーション固有となります。Section 3.11 で述べたとおり、新しい JWT アプリケーションでは明示的型付けの使用が推奨されます（RECOMMENDED）。

3.13. Limit Hash Iteration Count

実装は、PBES2 暗号化アルゴリズムを使用して暗号化されたコンテンツを検証する際に実行可能なハッシュ反復回数について、受信者に不合理な計算負荷を課す攻撃者を防ぐため、合理的な上限を設定することが推奨されます（RECOMMENDED）。[OWASP-Password-Storage] は、FIPS-140 準拠を達成するために HMAC-SHA-256 を使用する際に必要となる具体的な反復回数（公開時点では 600,000）を示しています。推奨される OWASP の値の 2 倍を超える p2c（PBES2 Count）値を持つ入力を拒否することが推奨されます（RECOMMENDED）。

3.14. Check JWT Format Type

実装は、JWT を解析する際に、その JWT が正当な形式であることを確認しなければなりません（MUST）。正当な JWT は、ドットで連結された base64url 文字列であるため、ASCII 文字の英字、数字、ダッシュ、アンダースコア、ピリオドのみを含みます。それ以外の文字（特に波括弧や引用符）を含むコンテンツは JWT ではなく、拒否しなければなりません（MUST）。

3.15. Limit JWE Decompression Size

実装は、JWE の展開後サイズに対して、たとえば 250 KB のような合理的な上限を設定することが推奨されます（RECOMMENDED）。

4. Security Considerations

本文書全体は、JSON Web Token の実装および展開におけるセキュリティ考慮事項に関するものです。

5. IANA Considerations

本文書には IANA に対するアクションはありません。

6. Acknowledgements

6.1. Acknowledgements for RFC 8725

本仕様に取り込まれている [RFC8725] の謝辞（本文）を以下に保持します。

JWE および JWT 実装者に対し、「ECDH-ES」の無効点攻撃を知らせてくれた Antonio Sanso に感謝します。Tim McLean は RSA/HMAC 混同攻撃 [McLean] を公開しました。明示的型付けの利用を提唱してくれた Nat Sakimura に感謝します。数多くのコメントを寄せてくれた Neil Madden に感謝します。また、Carsten Bormann、Brian Campbell、Brian Carpenter、Alissa Cooper、Roman Danyliw、Ben Kaduk、Mirja Kühlewind、Barry Leiba、Dan Moore、Eric Rescorla、Adam Roach、Martin Vigoureux、および Éric Vyncke によるレビューに感謝します。

6.2. Acknowledgements for [[ this specification ]]

本仕様の新しい内容に対する貢献について、Brian Campbell、Jianjun Chen、Dan Moore、Aaron Parecki、Filip Skokan、Tom Tervoort、Enze Wang、Jesse Yang に感謝します。

7. References

7.1. Normative References

• [nist-sp-800-56a-r3]\ Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-56ar3, April 2018, https://doi.org/10.6028/nist.sp.800-56ar3.

• [RFC2119]\ Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/rfc/rfc2119.

• [RFC6979]\ Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, https://www.rfc-editor.org/rfc/rfc6979.

• [RFC7515]\ Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, https://www.rfc-editor.org/rfc/rfc7515.

• [RFC7516]\ Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, https://www.rfc-editor.org/rfc/rfc7516.

• [RFC7518]\ Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, https://www.rfc-editor.org/rfc/rfc7518.

• [RFC7519]\ Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, https://www.rfc-editor.org/rfc/rfc7519.

• [RFC8017]\ Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, https://www.rfc-editor.org/rfc/rfc8017.

• [RFC8037]\ Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, https://www.rfc-editor.org/rfc/rfc8037.

• [RFC8174]\ Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/rfc/rfc8174.

• [RFC8259]\ Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/rfc/rfc8259.

7.2. Informative References

• [Alawatugoda]\ Alawatugoda, J., Stebila, D., and C. Boyd, "Protecting Encrypted Cookies from Compression Side-Channel Attacks", Springer Berlin Heidelberg, Lecture Notes in Computer Science pp. 86-106, DOI 10.1007/978-3-662-47854-7_6, ISBN ["9783662478530", "9783662478547"], 2015, https://doi.org/10.1007/978-3-662-47854-7_6.

• [ANSI-X962-2005]\ American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)", November 2005.

• [CVE-2015-9235]\ NIST, "CVE-2015-9235 Detail", National Vulnerability Database, May 2018, https://nvd.nist.gov/vuln/detail/CVE-2015-9235.

• [CVE-2023-51774]\ NIST, "CVE-2023-51774 Detail", National Vulnerability Database, February 2024, https://nvd.nist.gov/vuln/detail/CVE-2023-51774.

• [I-D.ietf-jose-deprecate-none-rsa15]\ Madden, N., "JOSE: Deprecate 'none' and 'RSA1_5'", Work in Progress, Internet-Draft, draft-ietf-jose-deprecate-none-rsa15-03, 19 September 2025, https://datatracker.ietf.org/doc/html/draft-ietf-jose-deprecate-none-rsa15-03.

• [JWT-Cracker]\ Rius, B., "JWT Cracker", n.d., https://github.com/brendan-rius/c-jwt-cracker.

• [Kelsey]\ Kelsey, J., "Compression and Information Leakage of Plaintext", Springer Berlin Heidelberg, Lecture Notes in Computer Science pp. 263-276, DOI 10.1007/3-540-45661-9_21, ISBN ["9783540440093", "9783540456612"], 2002, https://doi.org/10.1007/3-540-45661-9_21.

• [Langkemper]\ Langkemper, S., "Attacking JWT authentication", September 2016, https://www.sjoerdlangkemper.nl/2016/09/28/ attacking-jwt-authentication/.

• [McLean]\ McLean, T., "Critical vulnerabilities in JSON Web Token libraries", March 2015, https://auth0.com/blog/critical- vulnerabilities-in-json-web-token-libraries/.

• [OpenID.Backchannel]\ Jones, M. and J. Bradley, "OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1", December 2023, https://openid.net/specs/openid-connect-backchannel- 1_0.html.

• [OpenID.Core]\ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", December 2023, https://openid.net/specs/openid-connect-core-1_0.html.

• [OWASP-Password-Storage]\ OWASP, "Password Storage Cheat Sheet", OWASP Cheat Sheet Series , 2025, https://cheatsheetseries.owasp.org/cheatsheets/ Password_Storage_Cheat_Sheet.html.

• [RFC6749]\ Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/rfc/rfc6749.

• [RFC7159]\ Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, https://www.rfc-editor.org/rfc/rfc7159.

• [RFC7517]\ Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, https://www.rfc-editor.org/rfc/rfc7517.

• [RFC8414]\ Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, https://www.rfc-editor.org/rfc/rfc8414.

• [RFC8417]\ Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, https://www.rfc-editor.org/rfc/rfc8417.

• [RFC8725]\ Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, https://www.rfc-editor.org/rfc/rfc8725.

• [RFC9068]\ Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, https://www.rfc-editor.org/rfc/rfc9068.

• [RFC9700]\ Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, https://www.rfc-editor.org/rfc/rfc9700.

• [Sanso]\ Sanso, A., "Critical Vulnerability in JSON Web Encryption", March 2017, https://auth0.com/blog/critical- vulnerability-in-json-web-encryption/.

• [Valenta]\ Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In search of CurveSwap: Measuring elliptic curve implementations in the wild", March 2018, https://ia.cr/2018/298.

Appendix A. Changes from RFC 8725

本文書は RFC 8725 を廃止し、いくつかの重要な改善および追加を提供します。

1. Algorithm Verification: alg 値が大文字・小文字を区別しないものとして誤って読まれることに対処するため、防御的なチェックを追加しました（Section 3.1）。
2. Encryption-Signature Confusion: 検証者が「復号の成功」と「署名検証の成功」を区別しない攻撃に対する緩和策を追加しました（Section 3.12）。
3. PBES2 Count Limits: DoS 攻撃を防ぐため、不合理に大きい p2c（PBES2 Count）値を拒否する要件を追加しました（Section 3.13）。
4. JWT Format Confusion: JWT のシリアライズ形式の混同攻撃に対する緩和策を追加しました（Section 3.14）。
5. Compression DoS: JWE における圧縮の悪用に起因する DoS 攻撃に対する緩和策を追加しました（Section 3.15）。
6. 明示的な型付けと、すでにそれを採用していない種類の JWT との関係を説明しました。

Appendix B. Document History

[[RFC Editor への注記：公開前に削除してください。]]

B.1. draft-ietf-oauth-rfc8725bis-03

• 明示的な型付けと、すでにそれを採用していない種類の JWT との関係を説明しました。

B.2. draft-ietf-oauth-rfc8725bis-02

• Aaron Parecki のレビュー提案を取り込みました。
• 本仕様の新しい内容への貢献者を謝辞として記載しました。

B.3. draft-ietf-oauth-rfc8725bis-01

• Dan Moore による編集上の提案を適用しました。
• RFC 8725 に対する変更点を記述しました。

B.4. draft-ietf-oauth-rfc8725bis-00

• ドラフトが採択され、本文の変更はありません。

B.5. draft-sheffer-oauth-rfc8725bis-02

• RFC 8725 を廃止し、RFC 7519 を更新します。

B.6. draft-sheffer-oauth-rfc8725bis-01

• 暗号化と署名の混同を緩和しました。
• 不合理に大きい p2c（PBES2 Count）値を拒否します。
• alg 値が大文字・小文字を区別しないものとして誤って読まれることに対処する防御的チェックを追加しました。
• 圧縮の悪用に起因する DoS 攻撃を緩和しました。
• JWT のシリアライズ形式の混同を緩和しました。

B.7. draft-sheffer-oauth-rfc8725bis-00

• 初版であり、本文は RFC 8725 と同一です。

Authors' Addresses

Yaron Sheffer\ Intuit\ Email: yaronf.ietf@gmail.com

Dick Hardt\ Email: dick.hardt@gmail.com

Michael B. Jones\ Self-Issued Consulting\ Email: michael_b_jones@hotmail.com\ URI: https://self-issued.info/