JWT（SON Web Token）とは

Page content

JWT（JSON Web Token）とは、
ユーザーの認証情報や属性情報などを安全にやり取りするための、コンパクトなトークン形式のことです。
Webアプリ・API・モバイルアプリなどで幅広く使われています。

◆ JWTの基本構造

JWTは「ドット」で区切られた 3つの部分 から構成されます：

xxxxx.yyyyy.zzzzz

  1. Header（ヘッダー）
    ・署名方式などのメタ情報
    ・例：{"alg": "HS256", "typ": "JWT"}

  2. Payload（ペイロード）
    ・ユーザーIDや有効期限などの「クレーム（claims：情報）」
    ・例：{"sub": "12345", "name": "seiichi", "exp": 1735640000}

  3. Signature（署名）
    ・偽造されていないことを保証するための署名
    ・サーバー側が秘密鍵で作成する

◆ JWTがよく使われる理由（メリット）

✔ サーバーレスでセッション管理できる

サーバーでセッション情報を持つ必要がなく、トークン自体に必要な情報が入っているため、
負荷が軽い。

✔ API間の認証に向いている

フロントエンド（ブラウザ）→バックエンドAPI
モバイルアプリ → サーバー
マイクロサービス間 など
どこでも使える。

✔ JSON形式で扱いやすい

扱いやすく、構造がシンプル。

◆ JWTの注意点（デメリット）

⚠ 一度発行したら無効化しにくい

セッションのようにサーバー側で即無効化できない。
→ 対策：短い有効期限（exp） を設定し、リフレッシュトークンを使う。

⚠ ペイロードは暗号化されていない

Base64URLエンコードされているだけで、誰でも読める。
機密情報（パスワード・カード番号など）を入れてはいけない。

◆ どんな場面で使われる？

  • Webログイン（SPA + API）

  • モバイルアプリの認証

  • API Gateway や Auth0 などのIDサービス

  • マイクロサービス間通信

必要であれば以下も解説できます：

  • JWTとセッションの違い

  • アクセストークンとリフレッシュトークン

  • Auth0でのJWT運用

  • JWTのサンプルコード（Node/Python/Go）

JWT と セッション（Cookie セッション）は、「ログイン状態をどう保持するか」 の違う仕組みです。
それぞれの特徴を、分かりやすく整理します。

✅ JWT と セッションの違い（結論を先に）

比較項目 JWT セッション（Cookie セッション）
保持する場所 クライアント側（トークン） サーバー側（メモリ/DB）
無効化 しにくい 即時無効化できる
スケール スケールしやすい（ステートレス） スケールしにくい（ステートフル）
セキュリティ 署名で改ざん防止 サーバー保管で安全
主な用途 SPA・API・モバイルアプリ 伝統的なWebアプリ（HTML）
データ量 ペイロード内に情報を保持 サーバーに保存し ID だけをCookieに

最も大きな違いは
🔹 JWT＝ステートレス（サーバーが状態を持たない）
🔹 セッション＝ステートフル（サーバーが状態を持つ）

🔍 それぞれの仕組みを簡単に

◆ 1. セッション（Cookie セッション）

サーバーがユーザーのログイン状態を記録し、
ブラウザには 「そのID」だけを Cookie として渡す仕組み。

ブラウザ <—(session_id)—> サーバー

  • サーバー：session_id に紐づくユーザーデータを保持

  • ブラウザ：session_id のみ保持

  • 無効化：サーバー側で session を消すだけなので 即時無効

✔ メリット

  • 無効化が簡単で安全

  • サーバー側に情報があるので漏れにくい

  • 従来のWebアプリでは最も使いやすい

✔ デメリット

  • サーバーが状態を保持するため スケールしづらい
    → ロードバランサ＋複数サーバーだとセッション共有が必要

◆ 2. JWT（JSON Web Token）

ログイン情報を トークンの中に入れたままクライアントに保持 する仕組み。

ブラウザ <— JWT —> サーバー

サーバーは「署名が正しいか」だけをチェックし、状態を持たない。

✔ メリット

  • サーバーが状態を持たないので スケールしやすい（ステートレス）

  • モバイル・SPA・API などと相性がよい

  • 他サービスとの連携（マイクロサービス）に使いやすい

✔ デメリット

  • 一度発行した JWT を途中で無効化しにくい
    → 不正ログイン時に即ログアウトさせにくい

  • ペイロードは暗号化されていないので機密情報を入れられない

  • 長すぎる有効期限は危険

🤔 結局どっちを使うのがいい？

◆ HTMLベースの従来型Webアプリ

→ セッションでOK（最も安全で管理しやすい）

◆ SPA（React/Vue/Next.js）＋API構成

→ JWT が有利

  • サーバーが複数台でも楽

  • モバイルアプリとも共有しやすい

◆ マイクロサービスやAPI Gateway（Auth0やCognito）など

→ JWT が標準

🔰 よくある質問：JWTのログアウトが難しいのはなぜ？

JWTは「署名済みトークン」であり、
発行後は有効期限まで正しいトークンとして扱われるため。

無効化したい場合は：

  • 有効期限を短くする（5〜10分）

  • リフレッシュトークン方式を使う

  • ブラックリストを別途管理する

という工夫が必要。

⭐ まとめ

■ セッション
→ サーバー側で管理（安全・無効化しやすい）
→ ただしスケールしない

■ JWT
→ クライアント側で管理（ステートレス・スケールしやすい）
→ 無効化が難しいので短い有効期限＋リフレッシュ必須

必要であれば、以下も説明できます：

  • アクセストークン＋リフレッシュトークンの実装パターン

  • Auth0の場合の違い

  • Cookie で JWT を安全に使う方法（HTTPOnly / Secure）

Auth0 を使うと、JWT を使ったログイン処理の“やるべき作業”が大幅に減る、というのが最大の違いです。
自前実装と Auth0 の違いを、分かりやすく整理します。

🔍 Auth0 を使った場合の JWT ログインフローの違い（ざっくり）

自前の JWT 認証 → すべて自分で作る
Auth0 → 認証部分は Auth0 に丸投げして、アプリは JWT を受け取るだけ

✅ 自前（カスタム実装） vs Auth0 の違い

項目 カスタム JWT 実装 Auth0
ユーザー認証（メール/パスワード検証） 自前で実装 Auth0 が担当
OAuth / Google / LINE ログイン 自前実装は大変 Auth0 の設定で即対応
パスワードリセット・メール認証 自前で実装 Auth0 が自動提供
JWT 発行 自分で署名・生成 Auth0 が自動生成
JWT の署名鍵管理 自分で秘密鍵管理 Auth0 側で安全に管理
トークン検証 サーバーで署名検証 Auth0 の公開鍵で検証するだけ
ログアウト 自分でトークン無効化設計 Auth0 のセッションを削除
UI（ログイン画面） 自作 Auth0 の完備された UI 使用可

🧩 Auth0 のログインフロー（図解で説明）

通常の JWT の流れはこうでした：

  1. ユーザーが ID/Pass をアプリに送る

  2. サーバーがチェック

  3. JWT を発行

  4. API へアクセス

⭐ Auth0 の場合の流れ

あなたのアプリは パスワードを一切受け取らない。

Auth0 JWT ログインフロー（簡易版）

  1. アプリ → Auth0 にリダイレクト
    → ログインページは Auth0 が提供

  2. Auth0 で認証（メール/パスワード、SNSログインなど）

  3. Auth0 が JWT（ID Token / Access Token）を発行

  4. アプリは Auth0 から Token を受け取る

  5. API にアクセスするとき、その JWT をヘッダーにつける
    Authorization: Bearer xxxx.yyyy.zzzz

🔐 Auth0 が発行する 2 種類のトークン

Auth0 では JWT が2種類出てくるのが特徴です：

トークン 用途
ID Token（JWT） フロントエンドがユーザー情報を取得するため
Access Token（JWT） API へアクセスするため

👉 API には Access Token が必要
👉 ID Token は API では使わない

（ここが初心者がよく間違えるポイント）

🛡 Auth0 が提供するセキュリティ機能（自前より圧倒的に強い）

Auth0 では自動で以下が付いてきます：

  • パスワードポリシー

  • 多要素認証（MFA）

  • 不正ログイン検知

  • 攻撃防止（Brute-force protection）

  • メール認証

  • SSO（シングルサインオン）

  • ログの可視化

  • ユーザー管理画面

すべて自前実装すると超大変な部分。

📌 Auth0 での JWT 検証が少し違う点

Auth0 は秘密鍵を持っており、公開鍵を以下から取得します：

https://YOUR_DOMAIN/.well-known/jwks.json

あなたの API サーバーは、この公開鍵を使って
Auth0 が発行した JWT が正しいか検証します。

つまり：

  • 秘密鍵は Auth0 が保持

  • アプリ側は公開鍵だけ使用

この構造がセキュアで便利。

🎯 まとめ：Auth0 を使うと何が変わる？

✔ ログイン処理を「自前で作らなくてよくなる」

✔ JWT の管理・発行は Auth0 に任せられる

✔ API は受け取った Access Token を検証するだけ

✔ 豊富なセキュリティ機能を自動で利用できる

✔ Google / Twitter / LINE ログインも簡単に追加

必要であれば、以下も用意します：

  • Auth0 + Next.js の構成図

  • Auth0 を使った API 認証コード例（Node / Python / Go）

  • ID Token と Access Token の図解

  • SPA 向け “Authorization Code Flow with PKCE” の解説