はじめに

Webアプリケーションの認証において、JWT（JSON Web Token） は今や欠かせない技術となっています。従来のセッションベース認証と比べて、ステートレスでスケーラブルな認証が実現できるため、APIやマイクロサービスアーキテクチャで広く採用されています。

この記事では、JWTの基本的な仕組みから、安全に実装するためのベストプラクティスまでを解説します。

この記事で学べること

JWTの構造と仕組み
認証フローの全体像
セキュリティのベストプラクティス

対象読者

Web開発の基礎知識がある方
認証・認可の仕組みに興味がある方
JWTを安全に実装したいエンジニア

JWTとは何か？

JWT（JSON Web Token） は、当事者間で情報を安全に伝達するためのオープン標準（RFC 7519）です。トークン自体に情報（クレーム）を含むため、サーバー側でセッション情報を保持する必要がありません。

従来のセッション認証との比較

項目	セッション認証	JWT認証
サーバー側の状態	セッション情報を保持（ステートフル）	保持しない（ステートレス）
スケーラビリティ	サーバー間でセッション共有が必要	各サーバーで独立して検証可能
通信量	セッションIDのみ（軽量）	トークン全体（やや大きい）
無効化	サーバー側で即座に可能	追加の仕組みが必要

JWTの構造を理解する

JWTは**ドット（.）**で区切られた3つの部分で構成されています。

xxxxx.yyyyy.zzzzz
  ↓      ↓      ↓
Header.Payload.Signature

1. Header（ヘッダー）

トークンのタイプと署名アルゴリズムを指定します。

header.json

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

alg: 署名アルゴリズム（HS256, RS256など）
typ: トークンタイプ（通常は"JWT"）

2. Payload（ペイロード）

実際のデータ（クレーム）を格納する部分です。

payload.json

{
  "sub": "1234567890",
  "name": "田中太郎",
  "iat": 1737705600,
  "exp": 1737712800
}

標準クレーム（Registered Claims）

クレーム	説明	例
`iss`	発行者（Issuer）	`"https://example.com"`
`sub`	主題（Subject）、通常はユーザーID	`"user123"`
`aud`	対象者（Audience）	`"https://api.example.com"`
`exp`	有効期限（Expiration Time）	`1737712800`
`nbf`	有効開始時刻（Not Before）	`1737705600`
`iat`	発行時刻（Issued At）	`1737705600`
`jti`	JWT ID（一意識別子）	`"abc123"`

ペイロードはBase64エンコードされているだけで、暗号化されていません。誰でもデコードして内容を読めるため、パスワードや個人情報などの機密データは絶対に含めないでください。

3. Signature（署名）

トークンの改ざんを検出するための署名です。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

署名により、トークンが改ざんされていないことを検証できます。

実際のトークン例

以下は実際のJWTトークンの例です：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IueUsOS4reeahOmDjiIsImlhdCI6MTczNzcwNTYwMH0.Kj8mQZvR3xPqYz5H7wLdN2fA9gC4yB6sT1eU0iM5hXo

これをデコードすると：

// Header
{ "alg": "HS256", "typ": "JWT" }

// Payload
{ "sub": "1234567890", "name": "田中太郎", "iat": 1737705600 }

JWTの認証フロー

基本的な認証フロー

Access Token と Refresh Token

セキュリティと利便性のバランスを取るため、2種類のトークンを使い分けます。

トークン	有効期限	用途
Access Token	短い（15分〜1時間）	APIへのアクセス認証
Refresh Token	長い（7日〜30日）	Access Tokenの再発行

Refresh Token Rotation（ローテーション） を実装すると、Refresh Token使用のたびに新しいものを発行することで、トークン漏洩時のリスクを軽減できます。

セキュリティのベストプラクティス

1. 署名アルゴリズムの選択

アルゴリズム	種類	用途
HS256	対称鍵（共通鍵）	単一サービス向け
RS256	非対称鍵（公開鍵/秘密鍵）	マイクロサービス・複数サービス向け

alg: "none" は絶対に許可しない！
サーバー側で許可するアルゴリズムをホワイトリストで明示的に指定してください。攻撃者がヘッダーを "alg": "none" に書き換えて署名検証をバイパスする攻撃が存在します。

2. トークンの有効期限設定

// ❌ 悪い例：有効期限が長すぎる
const token = jwt.sign(payload, secret, { expiresIn: '365d' });

// ✅ 良い例：短い有効期限
const accessToken = jwt.sign(payload, secret, { expiresIn: '15m' });
const refreshToken = jwt.sign(payload, refreshSecret, { expiresIn: '7d' });

3. クレームの検証

トークン検証時は、署名だけでなく以下のクレームも必ず検証しましょう：

exp: 有効期限が切れていないか
iss: 信頼できる発行者か
aud: 正しい対象者か

まとめ

要点の振り返り

JWTは、ステートレスな認証を実現する強力なツールです。以下のポイントを押さえて安全に実装しましょう：

構造を理解する: Header, Payload, Signatureの3部構成
短い有効期限: Access Tokenは15分〜1時間程度に設定
Refresh Tokenを活用: 利便性とセキュリティのバランスを取る
アルゴリズムをホワイトリスト指定: noneアルゴリズム攻撃を防ぐ
機密情報は含めない: ペイロードは暗号化されていない
HttpOnly Cookieに保存: XSS攻撃からトークンを保護

参考リンク

この記事は2026年1月時点の情報に基づいています。各ライブラリのバージョンや推奨設定は変更される可能性があるため、公式ドキュメントも併せてご確認ください。