JWTヘッダーのtypフィールド

JWTヘッダーのtyp(タイプ)フィールドの仕組み、JWTに設定される理由、異なるタイプ値の使用場面、トークン識別におけるtypフィールドの役割を解説します。

Concept

詳細な説明

JWTヘッダーのtyp(タイプ)パラメータは、完全なトークンのメディアタイプを宣言します。標準的なJWTでは、この値は慣例として"JWT"に設定されます。些細なフィールドに見えるかもしれませんが、複数のトークンタイプが共存し識別が必要な環境では重要な役割を果たします。

標準的な使用法:

{
  "alg": "RS256",
  "typ": "JWT"
}

typフィールドはRFC 7519では技術的にオプションであり、ほとんどのJWTライブラリは存在を要求しません。ただし、ミドルウェア、ログシステム、デバッグツールがペイロードをパースせずにトークン形式をすばやく識別できるため、含めることが推奨されます。

JWTのtyp値:

RFC 7519では、存在する場合、typの値は"JWT"であるべきとされています(RFC 7515では大文字・小文字を区別しませんが、慣例では大文字)。"application/jwt"ではなくコンパクト形式の"JWT"が使用されます。これはJOSE(JSON Object Signing and Encryption)仕様のメディアタイプの扱いと一致しています。

トークンタイプの識別:

複数のJOSEベースのトークン形式を使用するシステムでは、typフィールドが不可欠になります。例えば、OAuth 2.0 DPoP(Demonstrating Proof-of-Possession)はDPoP証明トークンと通常のアクセストークンを区別するために"dpop+jwt"を使用します。Security Event Token(SET)仕様は"secevent+jwt"を使用します。OpenID ConnectのLogout Tokenは"logout+jwt"を使用します。typフィールドがなければ、サーバーがこれらのトークンの一つを受け取った場合、標準のJWTとして誤って処理する可能性があります。

検証の考慮事項:

アプリケーションが標準のJWTのみを受け入れる場合、typが存在しないか"JWT"に設定されていることを検証してください。これにより、DPoP証明や他の特殊なトークンがアクセストークンの代わりに送信されるタイプ混同攻撃を防ぎます。一部のJWTライブラリは設定オプションとしてこのチェックをサポートしています。複数のトークンタイプを処理する環境では、typを最初のディスパッチポイントとして使用し、トークンを適切な検証ロジックにルーティングしてください。

ctyとの関係:

cty(コンテンツタイプ)ヘッダーパラメータはペイロードのメディアタイプを記述し、ネストされたJWT(JWE内のJWT)で使用されます。JWTペイロード自体が別のJWTを含む場合、外側のトークンのヘッダーには"cty": "JWT"を含めて、復号後にペイロードをJWTとして処理すべきことを示す必要があります。これはトークン全体を記述するtypとは異なります。

ユースケース

OAuth 2.0認可サーバーがtypフィールドを使用して、検証時に通常のアクセストークン(typ: JWT)とDPoP証明トークン(typ: dpop+jwt)を区別します。

試してみる — JWT Decoder

フルツールを開く