🎯 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. さいごに

最後までご覧いただきありがとうございました。これからもいろいろな初心者向けの記事を作成していきますでの、よろしくお願いします。
よかったら他の記事もご覧いただけると嬉しいです。今後もよろしくお願いいたします。