JWT (JSON Web Token) の構造と、セキュリティ上のベストプラクティス

JWT (JSON Web Token) とは？

**JWT（JSON Web Token：ジョットと発音します）**は、WebアプリケーションやAPI間で、安全に情報をやり取りするために標準化されたデータフォーマット（RFC 7519）です。

現代のWebシステムでは、OAuth 2.0のアクセストークンや、OpenID Connect (OIDC) のIDトークンなど、**「状態を持たない（ステートレスな）認証・認可」**を実現するための事実上の標準技術として世界中で使われています。

JWT の3つの構造（ヘッダー、ペイロード、シグネチャ）

JWTは一見すると単なるランダムな文字列の羅列（例: eyJhbGci....eyJzdWIi....SflKxw...）に見えますが、実はドット（.）で3つの部分に区切られています。それぞれをBase64Urlデコードすると、中身のJSONデータを確認することができます。

1. ヘッダー (Header)

トークンの種類（typ）と、使用されている暗号化（署名）アルゴリズム（alg）が記述されています。 例: {"alg": "RS256", "typ": "JWT"} （RSA暗号を用いた署名であることを示します）

2. ペイロード (Payload)

実際に伝達したいデータ（クレーム：Claims）が格納されています。

• iss (Issuer): トークンの発行者
• sub (Subject): ユーザーの識別子（ID）
• exp (Expiration Time): 有効期限
• iat (Issued At): 発行日時 これらの標準クレームの他に、アプリケーション独自のデータ（例: {"role": "admin"}）を含めることも可能です。

3. シグネチャ (Signature / デジタル署名)

ヘッダーとペイロードのデータに対し、発行者の「秘密鍵」を用いて計算された暗号署名です。 この署名があるおかげで、受信者側は発行者の「公開鍵」を使って計算を行い、**「途中でデータが1文字でも改ざんされていないか」を確実に検証（Verify）**することができます。

開発者が陥りやすいセキュリティ上の落とし穴

JWTは非常に便利ですが、実装を誤ると致命的な脆弱性を生み出します。以下のベストプラクティスを必ず守る必要があります。

1. 重要な機密情報をペイロードに入れない

JWTは暗号化（暗号化して読めなくする技術：JWE）されているわけではなく、単にBase64でエンコード（変換）され、署名が付与されているだけです。つまり、デコードすれば誰でも中身を読むことができます。パスワードやクレジットカード番号などの機密情報をペイロードに含めてはいけません。

2. alg: "none" 攻撃を防ぐ

一部の古いJWTライブラリでは、悪意のあるユーザーがヘッダーのアルゴリズムを "alg": "none"（署名なし）に書き換えて送信すると、署名検証をスキップして認証を通過してしまうという脆弱性がありました。バックエンドの実装では、必ず期待するアルゴリズム（例: RS256）が使われていることを明示的にチェックする必要があります。

3. 有効期限（exp）を短く設定する

JWTはステートレスである（サーバー側にセッションを持たない）ため、「一度発行したトークンをサーバー側から即座に無効化（Revoke）することが難しい」という特性があります。そのため、万が一トークンが盗まれても被害を最小限に抑えるため、アクセストークンの有効期限（exp）は数分〜数十分程度と短く設定し、リフレッシュトークンを用いて定期的に再発行する設計が推奨されます。