7. Creating and Validating JWTs (JWTの作成と検証)

7.1. Creating a JWT (JWTの作成)

JWTを作成するには、以下の手順を実行します。ステップの入力と出力の間に依存関係がない場合、ステップの順序は重要ではありません。

1. 必要なクレームを含むJWT Claims Setを作成します。表現では空白が明示的に許可されており、エンコード前に正規化を実行する必要はないことに注意してください。

2. Messageを、JWT Claims SetのUTF-8表現のオクテットとします。

3. 必要なHeader Parametersのセットを含むJOSE Headerを作成します。JWTは [JWS] または [JWE] 仕様のいずれかに準拠しなければなりません (MUST)。表現では空白が明示的に許可されており、エンコード前に正規化を実行する必要はないことに注意してください。

4. JWTがJWSかJWEかに応じて、2つのケースがあります:

   • JWTがJWSの場合、MessageをJWS Payloadとして使用してJWSを作成します。JWSを作成するために [JWS] で指定されているすべてのステップに従わなければなりません (MUST)。

   • それ以外の場合、JWTがJWEの場合、MessageをJWEの平文として使用してJWEを作成します。JWEを作成するために [JWE] で指定されているすべてのステップに従わなければなりません (MUST)。

5. ネストされた署名または暗号化操作が実行される場合、MessageをJWSまたはJWEとし、ステップ3に戻ります。そのステップで作成された新しいJOSE Headerで "cty" (content type) 値 "JWT" を使用します。

6. それ以外の場合、結果のJWTをJWSまたはJWEとします。

7.2. Validating a JWT (JWTの検証)

JWTを検証する場合、以下の手順を実行します。ステップの入力と出力の間に依存関係がない場合、ステップの順序は重要ではありません。リストされているステップのいずれかが失敗した場合、JWTは拒否されなければなりません (MUST) - つまり、アプリケーションによって無効な入力として扱われます。

1. JWTに少なくとも1つのピリオド ('.') 文字が含まれていることを確認します。

2. Encoded JOSE Headerを、最初のピリオド ('.') 文字の前のJWTの部分とします。

3. 改行、空白、またはその他の追加文字が使用されていないという制限に従って、Encoded JOSE HeaderをBase64urlデコードします。

4. 結果のオクテットシーケンスが、RFC 7159 [RFC7159] に完全に準拠した有効なJSONオブジェクトのUTF-8エンコード表現であることを確認します。JOSE HeaderをこのJSONオブジェクトとします。

5. 結果のJOSE Headerに重複するHeader Parameter名が含まれていないことを確認します。ECMAScript 5.1 [ECMAScript] のセクション15.12で指定されているように、字句的に最後の重複メンバー名のみを返すJSONパーサーを使用する場合、このステップは自動的に達成できます。

6. JOSE Headerの "enc" (encryption algorithm) Header Parameterの存在を調べることにより、JWTがJWSかJWEかを判断します。

   • "enc" Header Parameterが存在する場合、JWTはJWEです。

   • それ以外の場合、JWTはJWSです。

7. JWTがJWSかJWEかに応じて、2つのケースがあります:

   • JWTがJWSの場合、JOSE Header内のアルゴリズムと鍵、JWS Payload、JWS Signatureを使用してJWSを検証するために [JWS] で指定されている手順に従います。MessageをJWS Payloadとします。

   • それ以外の場合、JWTがJWEの場合、JOSE Header内のアルゴリズムと鍵を使用してJWEを検証するために [JWE] で指定されている手順に従います。Messageを復号化の結果の平文とします。

8. JOSE Headerに値 "JWT" を持つ "cty" (content type) Header Parameterが含まれている場合、JWTはNested JWT (ネストされたJWT) です。この場合、ステップ1に戻り、MessageをJWTとして使用します。

9. それ以外の場合、改行、空白、またはその他の追加文字が使用されていないという制限に従って、MessageをBase64urlデコードします。

10. 結果のオクテットシーケンスが、RFC 7159 [RFC7159] に完全に準拠した有効なJSONオブジェクトのUTF-8エンコード表現であることを確認します。JWT Claims SetをこのJSONオブジェクトとします。

11. JWT Claims Setに重複するClaim Namesが含まれていないことを確認します。ECMAScript 5.1 [ECMAScript] のセクション15.12で指定されているように、字句的に最後の重複メンバー名のみを返すJSONパーサーを使用する場合、このステップは自動的に達成できます。

最後に、アプリケーションで複数の鍵が利用可能な場合、異なる鍵で複数回JWSまたはJWEの検証を試みる可能性があることに注意してください。特定の鍵の使用により失敗したとアプリケーションが判断した場合、成功するまで、またはすべての鍵が使い果たされるまで、他の鍵を試し続けることができます。

7.3. String Comparison Rules (文字列比較規則)

JWTの処理には、JSON文字列値の比較が必要です。

Claim NamesとHeader Parameter Namesの比較は、常に型変換なしの大文字小文字を区別する文字列比較として実行されます。

StringOrURI値のURIとJSON文字列値の比較は、次のように実行されます:

• 一方の値がURIで他方がURIでない場合、2つの値は異なります。

• 両方の値がURIの場合、型変換、正規化、またはバックスラッシュエスケープの処理なしで、大文字小文字を区別する文字列比較を使用して比較されます。

• どちらの値もURIでない場合、型変換またはバックスラッシュエスケープの処理なしで、大文字小文字を区別する文字列比較を使用して比較されます。

任意のユースケースに対して、URIやその他の文字列に対してより緩い、またはより厳密な比較規則が適切である可能性がありますが、これらの比較規則は明示的に指定されなければならない (MUST) ことに注意してください。

---