🎯 1. はじめに
Webアプリを作っていると、必ず出てくるのが 認証（ログイン） の話。
その中でよく使われているのが JWT（JSON Web Token） と セッション認証。
「結局どっちを使えばいいの？」
「どういう違いがあるの？」
「JWTってなぜ人気なの？」
そんな疑問を、初心者向けにわかりやすく解説します！
✅ 2. この記事でわかること
-
JWT（JSON Web Token）とは？
-
2つの仕組みの具体的な違い
-
どんなシステムでどちらを使うべき？
-
セキュリティ上の注意点
🥇 3. 結論（まずはざっくり）
セッション認証
→ サーバー が「ログイン状態」を覚える方式。
→ 昔からある王道。シンプルで安全。
JWT認証（トークンベース認証の一種）
→ 「ログイン状態」をトークンとして クライアント に持たせる方式。
→ モバイルアプリ・APIサーバー・分散構成との相性が◎
🔐 セッション方式とは？
最も歴史ある認証方式です。
✔ 仕組みのイメージ
-
ユーザーがログイン情報を送信
-
サーバーが認証
-
サーバーが「セッションID」を発行
-
セッションIDを Cookie に保存
-
次回リクエストからは Cookie を自動送信
サーバー側の「セッションストア」と照合してログイン状態を判定。
詳しくはこちらの記事をご覧ください。
🔑 JWT（JSON Web Token）とは？
JWT は、ログイン情報をトークン化してクライアント側に持たせる方式です。
トークンは次の3つがドットでつながった文字列です：
Header.Payload.Signature
🔹 Header（ヘッダー）
「このトークンはどの方式で署名されていますか？」を示すメタ情報
例：
{
"alg": "HS256",
"typ": "JWT"
}
-
alg → 署名アルゴリズム（例：HS256 / RS256など）
-
typ → 形式（ほぼ常に JWT）
ヘッダーは 署名を検証するために必要な情報 が入っています。
🔸 Payload（ペイロード）
「どのユーザーのトークンですか？いつまで有効ですか？」を示す情報
例：
{
"sub": "123",
"name": "Alice",
"exp": 1700000000
}
よくある項目：
| キー | 内容 |
|---|---|
| sub | ユーザーID |
| exp | 有効期限（UNIX時間） |
| iat | 発行日時 |
| iss | 発行者 |
Payload は暗号化ではなく エンコード なだけ
→ 中身は誰でも読める（改ざんはできないが閲覧は可能）
つまり「パスワード」や「クレジットカード情報」など センシティブな情報 を入れてはいけない。
🔻 Signature（署名）
「このトークンはサーバーが発行した本物です」を保証する部分
Signature は次の材料から生成されます：
Signature = HMAC-SHA256(
Base64UrlEncode(Header) + "." + Base64UrlEncode(Payload),
サーバーの秘密鍵
)
ここを改ざんすると 必ず変わる 仕組みになっています。
Signature があることでできること
| できる | できない |
|---|---|
| 改ざんの検知 | Payload の秘匿（中身を隠すこと） |
| 本物かどうかの検証 | 盗まれた後の悪用防止 |
🔥 3つの関係をまとめると
| 部分 | 役割 |
|---|---|
| Header | 署名方式の案内 |
| Payload | ユーザー情報（誰のトークンか） |
| Signature | 改ざん防止・正当性の証明 |
4. 🎨 JWT を使ったログインの流れ
✔ JWTの特徴
-
サーバー側でログイン状態を持たない（＝ステートレス）
-
スケーラビリティが高い（サーバーを増やしてもOK）
-
モバイルアプリやSPAと相性が良い
-
トークンが盗まれると危険（有効期限まで使い放題）
有効期限（exp）は短い期間を設定する
5. 🔍 セッション方式と JWT の比較
| 項目 | セッション | JWT |
|---|---|---|
| 状態管理 | サーバー管理（ステートフル） | クライアント側（ステートレス） |
| スケール（サーバー増やす） | セッション共有が必要 | 何も不要 |
| セキュリティ | 比較的高い | 管理方法による |
| トークンの中身 | ない（IDだけ） | Payloadを含む（読める） |
| 失効のしやすさ | いつでも無効化可能 | トークンが期限切れまで残る |
| モバイルアプリ | △（Cookie前提） | ◎ |
| SPA（React/Vueなど） | ○ | ◎ |
6. 🧩 どっちを使えばいいの？
✔ セッション方式がおすすめのケース
-
サーバーが1台構成
-
通常の Web サイト（ページ遷移型・サーバーサイドレンダリング）
-
「ログインしたらずっと使う」系
例）社内向けシステム、WordPress、管理画面など
→ セキュリティが高く、管理もしやすいので初心者向け
✔ JWTがおすすめのケース
-
モバイルアプリ + APIサーバー
-
SPA（シングルページアプリケーション：React / Vue / Next.js）
-
サーバーが複数台・マイクロサービス構成
-
CDN・サーバーレスを使いたい場合
→ 分散型やAPI主体ならほぼJWT一択
7. ⚠ セキュリティ上の注意点
■ JWTをローカルストレージに保存してはいけない
- XSS（クロスサイトスクリプティング）で盗まれるから。
■ httpOnly Cookie で保存が安全
-
JavaScript から読み取れない
-
自動送信されるため使いやすい
※ また CSRF 対策（SameSite=Lax/Strict など） も忘れずに。
8. 🥽 まとめ
-
セッション方式は「サーバーが覚える」方式
-
JWT は「ログイン状態をトークンとして自分で持つ」方式
-
Webサイトはセッション、APIやSPAはJWTが向いている
-
JWTはXSS対策が超重要
どちらを使用しても大丈夫！ ただし用途によって向き不向きがあることを忘れずに。
9. さいごに
最後までご覧いただきありがとうございました。これからもいろいろな初心者向けの記事を作成していきますでの、よろしくお願いします。
よかったら他の記事もご覧いただけると嬉しいです。今後もよろしくお願いいたします。