1.1. 対象読者

本文書の対象読者は以下の通りです。¶

• JWTライブラリ（およびそれに用いられるJWS/JWEライブラリ）を実装する人。¶
• そのようなライブラリを用いるコードを実装する人（ライブラリで提供されていない機構を自前で扱う場合も含む）。¶
• JWTに依存する仕様を開発する人、IETF内外を問わず。¶

1.2. 本文書で使用する表記法

本文書で使用されるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、 BCP 14 に従って解釈されます。 ただし、すべて大文字で書かれた場合に限ります。¶

2.1. 弱い署名と不十分な署名検証

署名されたJSON Web Tokenは、暗号アルゴリズムの変更性を容易にするために、 "alg" ヘッダパラメータの形で署名アルゴリズムを明示的に示す。 これに加え、一部のライブラリやアプリケーションの設計上の欠陥により、いくつかの攻撃が発生している。¶

• 攻撃者によってアルゴリズムを "none" に変更でき、一部のライブラリは この値を信頼して署名をチェックせずにJWTを「検証」してしまう。¶
• "RS256" (RSA、2048ビット) のパラメータ値が "HS256" (HMAC、SHA-256) に 変更され、一部のライブラリはRSA公開鍵をHMACの共有秘密として使用して HMAC-SHA256で署名を検証しようとする場合がある（参照 [McLean] および [CVE-2015-9235]）。¶

軽減策については、セクション 3.1 および 3.2 を参照。¶

2.2. 弱い対称鍵

さらに、一部のアプリケーションは "HS256" のような鍵付きメッセージ認証コード（MAC）アルゴリズムを使用してトークンに署名するが、 エントロピーが不十分な弱い対称鍵（人間が覚えやすいパスワードなど）を使用している場合がある。 このような鍵は、攻撃者がトークンを入手した場合、オフラインの総当たり攻撃や辞書攻撃に対して脆弱である。[Langkemper]。¶

軽減策については、セクション3.5 を参照。¶

2.3. 暗号化と署名の不適切な組み合わせ

JWEで暗号化されたJWTを復号してJWS署名されたオブジェクトを取得する一部のライブラリは、 内部署名を常に検証するわけではない。¶

軽減策については、セクション3.3 を参照。¶

2.4. 暗号文の長さ分析による平文漏洩

多くの暗号アルゴリズムは、平文の長さに関する情報を漏洩する。漏洩量はアルゴリズムや運用モードに依存する。 平文が最初に圧縮されている場合、この問題は悪化する。なぜなら、圧縮後の平文の長さ、ひいては暗号文の長さは元の平文の長さだけでなく、内容にも依存するからである。 圧縮攻撃は、攻撃者が制御できるデータが秘密データと同じ圧縮空間にある場合に特に強力であり、これはHTTPSに対する一部の攻撃で見られる。¶

圧縮と暗号化の一般的な背景については [Kelsey] を、 HTTPクッキーに対する攻撃の具体例については [Alawatugoda] を参照。¶

軽減策については、セクション3.6 を参照。¶

2.5. 楕円曲線暗号の不安全な使用

[Sanso] によると、いくつかのJavaScript Object Signing and Encryption (JOSE) ライブラリは、 楕円曲線鍵共有（"ECDH-ES"アルゴリズム）を実行する際に入力を正しく検証できない。 攻撃者が無効な曲線点を使用した任意のJWEを送信し、その無効な曲線点で復号した平文を観察できる場合、この脆弱性を利用して受信者の秘密鍵を回復することができる。¶

軽減策については、セクション3.4 を参照。¶

2.6. JSONエンコーディングの多様性

以前のJSONフォーマット（廃止された [RFC7159] など）は、UTF-8、UTF-16、UTF-32など複数の文字エンコーディングを許可していた。 現在の標準 [RFC8259] では、内部的な「閉じたエコシステム」内での使用を除き、UTF-8のみを許可している。 この曖昧さにより、古い実装や閉じた環境で使用される実装が非標準のエンコーディングを生成する可能性があり、JWTが受信者によって誤解される可能性がある。 これにより、悪意のある送信者が受信者の検証チェックを回避することができる。¶

軽減策については、セクション3.7 を参照。¶

2.7. 置換攻撃

受信者が本来意図されたJWTを別の受信者で使用しようとする攻撃が存在する。 例えば、OAuth 2.0 [RFC6749] アクセストークンが正当に 意図されたOAuth 2.0保護リソースに提示された場合、その保護リソースが同じアクセストークンを 意図されていない別の保護リソースに提示し、アクセスを試みる可能性がある。 このような状況を検出できない場合、攻撃者が本来アクセス権のないリソースにアクセスできる可能性がある。¶

軽減策については、セクション 3.8 および 3.9 を参照。¶

2.8. JWTの混同

JWTが異なるプロトコルや多様なアプリケーション領域で使用されるにつれ、 ある目的で発行されたJWTが他の目的で悪用されることを防ぐことがますます重要になる。 これは特定の置換攻撃の一種であることに注意。 JWTが他の種類のJWTと混同されうるアプリケーションコンテキストで使用される場合、 このような置換攻撃を防ぐために軽減策 MUST が必要である。¶

軽減策については、セクション 3.8、3.9、 3.11、および 3.12 を参照。¶

2.9. サーバーに対する間接攻撃

さまざまなJWTクレームは、受信者がデータベースやLDAP検索などのルックアップ操作を行うために使用される。 他には、同様にサーバーがルックアップするURLなどがある。 これらのクレームはいずれも、攻撃者によって注入攻撃やサーバーサイドリクエストフォージェリ（SSRF）攻撃のベクターとして利用される可能性がある。¶

軽減策については、セクション3.10 を参照。¶

3.1. アルゴリズム検証を実施する

ライブラリは呼び出し元がサポートされるアルゴリズムの集合を指定できるようにしMUST、暗号操作を行う際にそれ以外のアルゴリズムを使用してはならないMUST NOT。 ライブラリは "alg" または "enc" ヘッダが暗号操作で使用されるのと同じアルゴリズムを指定していることをMUST 確保する必要がある。 さらに、各キーは厳密に一つのアルゴリズムでのみ使用されるべきであり、そのことは暗号操作が実行される際に確認されなければならないMUST。¶

3.2. 適切なアルゴリズムを使用する

[セクション5.2 of [RFC7515]が述べるように、 「特定の文脈でどのアルゴリズムが使用できるかはアプリケーションの判断である。たとえ JWS が正常に検証できたとしても、JWS で使用されたアルゴリズムがアプリケーションにとって受け入れられるものでない限り、アプリケーションは当該 JWS を無効とみなすべきである」とある。¶

したがって、アプリケーションは暗号的に現在安全とされるアルゴリズムのみを許可しMUST、アプリケーションのセキュリティ要件を満たす必要がある。 この集合は新しいアルゴリズムの導入や既存アルゴリズムが暗号的弱点により非推奨になるに従って時間とともに変化する。 よってアプリケーションは暗号のアジリティを可能にするよう設計されなければならないMUST。¶

とはいえ、JWT が TLS のような輸送層でエンドツーエンドに暗号的に保護されており、かつその輸送が暗号的に現在安全なアルゴリズムを使用している場合、JWT に別の暗号保護層を適用する必要はないかもしれない。 そのような場合、"none" アルゴリズムの使用は完全に容認され得る。 "none" アルゴリズムは JWT が他の手段によって暗号的に保護されている場合にのみ使用されるべきである。 "none" を使用する JWT は、署名が任意であるアプリケーション文脈で用いられることが多く、その場合、URL 安全なクレーム表現と処理は署名あり・なしの両方で同一にできる。 JWT ライブラリは明示的に呼び出し元に要求されない限り "none" を使用して JWT を生成すべきでないSHOULD NOT。 同様に、JWT ライブラリは明示的に呼び出し元に要求されない限り "none" を使用する JWT を消費すべきでないSHOULD NOT。¶

アプリケーションは次のアルゴリズム固有の推奨事項に従うべきであるSHOULD：¶

• すべての RSA-PKCS1 v1.5 暗号化アルゴリズム（[RFC8017], セクション7.2）を避け、 RSAES-OAEP （[RFC8017], セクション7.1）を好むべきである。¶
• 楕円曲線デジタル署名アルゴリズム（ECDSA）署名 [ANSI-X962-2005] は、署名される各メッセージに対して一意のランダム値を必要とする。 もしランダム値の一部のビットでも複数メッセージ間で予測可能であれば、署名スキームの安全性は損なわれる可能性がある。最悪の場合、攻撃者によって秘密鍵が回復されることもあり得る。これらの攻撃に対抗するために、JWT ライブラリは決定論的な手法（[RFC6979]で定義される）を用いて ECDSA を実装することを推奨するSHOULD。 この手法は既存の ECDSA 検証者と完全に互換性があるため、新たなアルゴリズム識別子を必要とせずに実装できる。¶

3.3. すべての暗号操作を検証する

JWT で使用されるすべての暗号操作は検証されるべきであり、いずれかが検証に失敗した場合は JWT 全体を拒否しなければならないMUST。 これはヘッダパラメータが単一のセットである JWT に限らず、外側と内側の両方の操作が検証されるべきネストされた JWT に対しても同様であり、これらはアプリケーションによって提供されるキーとアルゴリズムを用いて検証されなければならないMUST。¶

3.4. 暗号入力を検証する

楕円曲線ディフィー・ヘルマン鍵共有（"ECDH-ES"）のような一部の暗号操作は、指定された楕円曲線上にない点やその他の無効な点（例: [Valenta]、セクション7.1）を含む無効な値を入力として取る可能性がある。 JWS/JWE ライブラリ自体がこれらの入力を使用する前に検証するか、あるいは基盤となる暗号ライブラリがそれを行う（またはその両方）必要がある。¶

楕円曲線ディフィー・ヘルマン Ephemeral-Static（ECDH-ES）のエフェメラル公開鍵（epk）入力は、受信者が選択した楕円曲線に従って検証されるべきである。NIST の素数位数曲線 P-256、P-384、P-521 の場合、検証は"Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography" のセクション5.6.2.3.4（ECC 部分公開鍵検証ルーチン）に従って行われるべきである[nist-sp-800-56a-r3]。 "X25519" または "X448" のアルゴリズムが使用される場合は、[RFC8037] に記載されたセキュリティ考慮事項が適用される。¶

3.5. 暗号鍵が十分なエントロピーを有していることを保証する

キーのエントロピーとランダム値に関する助言は、[RFC7515 セクション10.1]および[RFC7518 セクション8.8]のパスワードに関する考慮事項に従うべきであり、これらは守られなければならないMUST。特に、人間が記憶可能なパスワードを "HS256" のような keyed-MAC アルゴリズムのキーとして直接使用してはならないMUST NOT。 さらに、パスワードはコンテンツ暗号化よりも鍵暗号化を行うためにのみ使用されるべきであり、その詳細は [RFC7518 セクション4.8] に記載されている。鍵暗号化に用いる場合でも、パスワードベースの暗号化は総当たり攻撃の対象となる点に注意する必要がある。¶

3.6. 暗号化入力の圧縮を避ける

データの圧縮は暗号化の前に行うべきではないSHOULD NOT。圧縮されたデータはしばしば平文に関する情報を明らかにするためである。¶

3.7. UTF-8 を使用する

[RFC7515]、[RFC7516]、および [RFC7519] はすべて、ヘッダパラメータおよび JWT クレームセットで使用される JSON のエンコードおよびデコードに UTF-8 を使用することを指定している。これは最新の JSON 仕様書 [RFC8259] とも一致する。 実装およびアプリケーションはこれを行い、これらの目的のために他の Unicode エンコーディングを使用したり許容したりしてはならないMUST。¶

3.8. 発行者と主体を検証する

JWT に "iss"（発行者）クレームが含まれる場合、アプリケーションは JWT の暗号操作に使用された暗号鍵が発行者に属することを検証しなければならないMUST。 もし属していない場合、アプリケーションは JWT を拒否しなければならないMUST。¶

発行者が所有する鍵を特定する手段はアプリケーション固有である。一例として、OpenID Connect [OpenID.Core] の発行者値は JSON メタデータ文書を参照する "https" URL であり、その文書には発行者の鍵が JWK セットとして取得される "jwks_uri" 値（"https" URL）を含む。このメカニズムは [RFC8414] でも使用される。その他のアプリケーションは異なる手段で鍵と発行者を結び付ける場合がある。¶

同様に、JWT に "sub"（主体）クレームが含まれる場合、アプリケーションは主体値が有効な主体および/またはアプリケーションにおける発行者-主体の組と対応していることを検証しなければならないMUST。 これには発行者がアプリケーションによって信頼されていることの確認を含む場合がある。もし発行者、主体、またはその組が無効であれば、アプリケーションは JWT を拒否しなければならないMUST。¶

3.9. オーディエンスを使用し検証する

同じ発行者が複数の依存当事者またはアプリケーション向けに JWT を発行できる場合、JWT は "aud"（オーディエンス）クレームを含み、その値を使用して JWT が意図された当事者によって使用されているか、攻撃者によって意図しない当事者に差し替えられていないかを判断できるようにしなければならないMUST。¶

そのような場合、依存当事者やアプリケーションはオーディエンス値を検証しなければならないMUST。 もしオーディエンス値が存在しないか受信者に関連付けられていない場合、JWT を拒否しなければならないMUST。¶

3.10. 受け取ったクレームを信用しない

"kid"（キーID）ヘッダは依存アプリケーションが鍵検索を行うために使用される。アプリケーションはこれが SQL や LDAP インジェクションの脆弱性を生じさせないよう、受け取った値を検証および/またはサニタイズすることを保証すべきである。¶

同様に、任意の URL を含み得る "jku"（JWK セット URL）や "x5u"（X.509 URL）ヘッダを盲目的にたどることは、サーバーサイドリクエストフォージェリ（SSRF）攻撃を招く可能性がある。アプリケーションはそのような攻撃に対して保護すべきでありSHOULD、例えば URL を許可された場所のホワイトリストに照合し、GET リクエストでクッキーが送信されないことを確保する等の対策を講じるべきである。¶

3.11. 明示的な型指定を使用する

場合によっては、ある種類の JWT が別の種類と混同されることがある。もし特定の種類の JWT がそのような混乱の対象となるなら、その JWT は明示的な JWT 型値を含めることができ、検証ルールは型のチェックを指定することができる。このメカニズムはそのような混同を防ぐことができる。 明示的な JWT 型指定は "typ" ヘッダパラメータを使用して行われる。例えば、[RFC8417] 仕様は Security Event Tokens (SET) の明示的な型指定を行うために "application/secevent+jwt" メディアタイプを使用する。¶

[RFC7515 セクション4.1.9] における "typ" の定義によれば、"typ" 値から "application/" プレフィックスを省略することが推奨されるRECOMMENDED。 したがって、例えば SET の型を明示的に含めるために使用される "typ" 値は "secevent+jwt" であるべきだSHOULD。 JWT に明示的な型指定が用いられる場合、"application/example+jwt" の形式のメディアタイプ名を使用することが推奨されるRECOMMENDED。ここで "example" は特定の JWT 種類の識別子に置き換えられる。¶

ネストされた JWT に明示的な型指定を適用する場合、明示的な型値を含む "typ" ヘッダパラメータはネストされた JWT の内側の JWT（ペイロードが JWT クレームセットである JWT）に存在しなければならないMUST。 場合によっては、全体のネストされた JWT を明示的に型指定するために外側の JWT にも同じ "typ" ヘッダパラメータ値が存在することがある。¶

明示的な型指定を用いても既存の種類の JWT からの曖昧性を完全に解消できないことがある点に注意せよ。既存の種類の JWT に対する検証ルールはしばしば "typ" ヘッダパラメータ値を使用していないからである。 新しい JWT の用途に対しては明示的な型指定が推奨されるRECOMMENDED。¶

3.12. 異なる種類の JWT に対して相互に排他的な検証ルールを使用する

各 JWT の適用は、必要および任意の JWT クレームとそれらに関連する検証ルールを指定するプロファイルを定義する。 同一の発行者が複数種類の JWT を発行できる場合、それらの JWT に対する検証ルールは相互に排他的になるように記述されなければならずMUST、間違った種類の JWT を拒否すること。 JWT をある文脈から別の文脈へ差し替えられることを防ぐために、アプリケーション開発者は複数の戦略を用いることができる：¶

• 異なる種類の JWT に対して明示的な型指定を使用する。すると異なる "typ" 値を用いて JWT の種類を区別できる。¶
• 必要なクレームの集合や要求されるクレーム値を変える。するとある種類の JWT に対する検証ルールは、異なるクレームや値を持つものを拒否する。¶
• 必要なヘッダパラメータの集合や要求されるヘッダパラメータ値を変える。するとある種類の JWT に対する検証ルールは、異なるヘッダパラメータや値を持つものを拒否する。¶
• 異なる種類の JWT に対して異なる鍵を使用する。するとある種類の JWT を検証するために使用される鍵は他の種類の JWT を検証できず、失敗する。¶
• 同一の発行者からの異なる用途の JWT に対して異なる "aud" 値を使用する。するとオーディエンス検証は不適切な文脈に差し替えられた JWT を拒否する。¶
• 異なる種類の JWT に対して異なる発行者を使用する。すると異なる "iss" 値を用いて JWT の種類を分離できる。¶

JWT の用途とアプリケーションの多様性を考えると、異なる種類の JWT を区別するための型、必要なクレーム、値、ヘッダパラメータ、鍵の使用、発行者の最良の組み合わせは、一般にアプリケーション固有である。 新しい JWT アプリケーションに関しては、セクション3.11で述べたように、明示的な型指定の使用が推奨されるRECOMMENDED。¶