JWT とは？JSON Web Token 完全ガイド

2026-07-25· タグ: what-is-jwt, jwt-authentication, jwt-guide, api-security, token-based-auth

JWT とは？

JSON Web Token（JWT）は、JSON オブジェクトとして当事者間で情報を安全に送信するための、コンパクトで自己完結型の方法を定義するオープンスタンダード（RFC 7519）です。JWT は現代の Web アプリケーションで支配的なトークン形式であり、ユーザー認証や API 認可からマイクロサービス間の安全なデータ交換まで、あらゆる用途に使用されています。

JWT 認証の仕組み

JWT 認証はステートレスなパターンに従い、サーバー側のセッションストレージを不要にします。このフローを理解することは、JWT が現代の API セキュリティのデフォルトの選択肢になった理由を理解する鍵です。

認証フロー

ユーザーがログインする — クライアントが認証情報（ユーザー名とパスワード）を認証サーバーに送信します。
サーバーが JWT を作成する — サーバーが認証情報を検証し、ユーザーの ID と権限を含む JWT を作成して、秘密鍵または公開鍵で署名し、クライアントに返します。
クライアントがトークンを保存する — クライアントは JWT を、通常は localStorage、sessionStorage、または HTTP-only クッキーに保存します。
クライアントが各リクエストでトークンを送信する — その後のすべての API リクエストで、クライアントは Bearer スキームを使用して Authorization ヘッダーに JWT を含めます: Authorization: Bearer <token>。
サーバーがトークンを検証する — サーバーは JWT 署名を検証し、有効期限を確認し、ユーザークレームを抽出してリクエストを認可します。
セッションルックアップが不要 — JWT に必要な情報がすべて含まれているため、サーバーはユーザーを識別するためにデータベースやキャッシュを照会する必要がありません。

なぜこれが重要なのか

従来のセッションベースの認証は、セッション ID をサーバーのメモリまたはデータベースに保存します。認証された各リクエストにはルックアップが必要です。JWT はこのルックアップを排除します — トークン自体がユーザーの ID を証明します。これにより、クラスター内のどのサーバーでも共有セッション状態なしでトークンを検証できるため、JWT ベースのシステムは本質的にスケーラブルになります。

JWT とセッションベース認証の比較

| 項目 | JWT 認証 | セッションベース認証 | |--------|--------------------|------------------------------| | ストレージ | クライアント側（トークン内） | サーバー側（メモリまたは DB） | | スケーラビリティ | 共有セッションストア不要 | インスタンス間で共有セッションストアが必要 | | クロスドメイン | ドメインをまたいで自然に機能 | セッション共有が困難 | | モバイル対応 | 対応（クッキー不要） | クッキーサポートが必要 | | 失効 | 困難（トークンが期限切れになるまで） | 容易（ストアからセッションを削除） | | ペイロードサイズ | リクエストごとに大きい（ヘッダー内のトークン） | 最小限（セッション ID のみ） |

JWT が API セキュリティに使用される理由

JWT を認証に適したものにする特性は、API の保護にも理想的です。

ステートレスでスケーラブル

すべての JWT には、リクエストを認可するためにサーバーが必要とするすべての情報が含まれています。照会するセッションデータベースも、確認するキャッシュも、サーバー間で同期する状態もありません。ロードバランサーは調整なしでリクエストを任意のサーバーインスタンスにルーティングできます。

クロスドメインとクロスオリジン

JWT は異なるドメインやオリジンをまたいで自然に機能します。auth.example.com によって発行されたトークンは、api.example.com と admin.example.com へのアクセスに使用できます。これにより、JWT はシングルサインオン（SSO）システムの基盤となります。

きめ細かい認可

JWT ペイロードには、ロール、権限、組織メンバーシップのカスタムクレームを含めることができます:

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

API サーバーは、追加のルックアップなしでこれらのクレームをトークンから直接読み取ります。

シングルサインオン（SSO）のための JWT

シングルサインオンは、JWT の最も一般的なユースケースの 1 つです。典型的な SSO アーキテクチャでは:

ユーザーが ID プロバイダー（IdP）— Auth0、Okta、Keycloak など — にログインします。
IdP が秘密鍵で署名した JWT を発行します。
ユーザーがこの JWT を複数のアプリケーションに提示します。
各アプリケーションが IdP の公開鍵を使用して署名を検証します。
各アプリケーションは、リクエストごとに IdP と通信することなくトークンを信頼します。

このパターンにより、1 回のログインで多数のサービス（メール、ファイルストレージ、プロジェクト管理、人事システム）へのアクセスが許可され、各サービスが独自のログインフローを実装する必要がなくなります。

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

JWT は API セキュリティの強固な基盤を提供しますが、正しい実装が不可欠です。

トークンの有効期間を短くする

exp（有効期限）クレームを短い期間 — アクセストークンでは 15 分から 1 時間 — に設定します。有効期間の長いリフレッシュトークン（数日または数週間）を使用して、ユーザーに再認証を要求せずに新しいアクセストークンを取得します。

常に HTTPS を使用する

JWT はペイロードを暗号化しません。トークンを傍受した人は誰でも内容をデコードして読むことができます。傍受を防ぐため、常に HTTPS 経由で JWT を送信してください。

すべてを検証する

常に署名を検証し、トークンが期限切れでないことを確認し、aud（オーディエンス）がアプリケーションと一致することを確認し、予期しないアルゴリズムのトークンを拒否してください。

トークンを安全に保存する

クライアント側では、可能な場合は HTTP-only クッキーに JWT を保存し、シングルページアプリケーションではメモリに保存してください。機密データへのアクセスを提供するトークンには localStorage を避けてください。

JWT に関するよくある誤解

「JWT は暗号化されている。」 — いいえ。JWT は署名されており、暗号化はされていません。ペイロードは base64url エンコードされており、これは可逆です。JWE（JSON Web Encryption）は暗号化を提供しますが、これは標準の JWT ではカバーされない別の仕様です。

「JWT は CSRF を防ぐ。」 — それ単体では防ぎません。Authorization ヘッダー内の JWT は役立ちますが、トークンがクッキー内にある場合、CSRF 保護は依然として必要です。

「JWT は認証専用である。」 — JWT は認証に使用されますが、認可データの交換、ステートフルセッション、サービス間の安全な情報共有にも使用されます。

JWT をオンラインでデコードして調べる

JWT デコーダーツールを使用して、任意の JSON Web Token を検査します。トークンを貼り付けると、デコードされたヘッダー、ペイロード、署名アルゴリズムが即座に表示されます。このツールは、トークンがどのようなデータを保持しているかを理解し、正しく構造化されているかを検証するのに役立ちます。