🔐

技術面接で聞かれる認証方式の違いを理解する

に公開
面接
Security
JWT
session
認証
idea

はじめに

技術面接で頻出する質問のひとつに 「セッション認証とトークン認証（JWT）の違い」 があります。
私もかつて某有名 IT 企業の技術面接で聞かれました。
実務で使ったことはあっても、いざ口頭で説明しようとすると

  • どこから話せばよいのか？
  • それぞれの本質的な違いは何か？
  • 面接官はどこを評価しているのか？

という点で詰まりがちです。

本記事では、セッション認証と JWT 認証の違いを 本質（ステート管理） から理解し、 面接でもそのまま話せる説明方法を整理しておきます。

1. 認証方式を分ける「本質」はどこか？

セッション認証とトークン認証（JWT）の違いは、一言でまとめると 「状態（ステート）をどこに持つか」 の違いです。

方式 状態を保持する場所 特徴
セッション認証 サーバー Stateful／即時無効化に強い
トークン認証（JWT） クライアント Stateless／スケーラブル

2. セッション認証：サーバーが管理する方式

セッション認証は、古くからある一般的な認証方式です。
Stateful であり、サーバー側が「誰がログイン中か」という状態を管理します。

サーバー側で状態を集中管理できるため、ログアウト処理や強制的なセッション無効化（アカウント BAN など）が即座に反映できる点が強みです。

2.1 セッション認証の仕組みを一言で言うと？

  • サーバー：荷物（ユーザー情報）を預かり、台帳（セッションストア）で管理する
  • ブラウザ：中身のない番号札（セッション ID）だけを持つ
  • リクエスト時に番号札を見せると、サーバーが奥から荷物（ユーザー情報）を出してくる

2.2 処理フロー

  1. ユーザーがログイン
  2. サーバーがメモリや DB にユーザー情報を保存（セッション作成）
  3. セッション ID を発行し、Cookie に入れる
  4. ブラウザは次回以降、リクエストと共に Cookie を送る
  5. サーバーが受け取った ID をキーにして、サーバー上の情報を参照する

2.3 メリット

  • 即時ログアウト・無効化が容易（サーバー側のデータを消すだけ）
  • ID はただのランダム文字列なので、万が一漏れても中身（属性情報）はバレない
  • 通信量が少ない（ID のみ）

2.4 デメリット

  • スケールさせるのが難しい
    ロードバランサーで負荷分散する場合、どのサーバーにも同じセッション情報が必要です。Redis 等の KVS でセッションストアを外部化する構成が必要になり、インフラ構成が少し複雑になります。
  • サーバーのリソースを消費する
    アクティブユーザーが増えるほど、サーバー側のメモリやストレージを圧迫します。

3. トークン認証（JWT）：クライアントが証明書を持つ方式

近年、SPA（Single Page Application）やマイクロサービスアーキテクチャの普及に伴い、JWT（JSON Web Token） を用いた認証が主流になっています。

本来「トークン認証」とは、認証済みであることを示す文字列（トークン）を使う方式全般を指します。現在は 「トークン自体に JSON 形式のデータを含めることができる規格」である JWT を使うのが一般的です。

最大の特徴は Stateless であること。サーバーは「ログイン中」という状態を保存しません。

3.1 トークン認証の仕組みを一言で言うと？

  • サーバー：パスポート（JWT）を発行するだけ。発行したことは忘れて良い。
  • クライアント：顔写真や有効期限が書かれたパスポートそのものを保存する。
  • リクエスト時にパスポートを提示し、サーバーは「偽造されていないか（署名）」だけを確認する。

3.2 JWT の構造

JWT は . で区切られた 3 つの部分で構成されています。

  1. Header: アルゴリズムやトークンのタイプが記載
  2. Payload: ユーザー ID や有効期限などのデータ（Base64Url エンコードされているだけで、暗号化ではないため誰でも読める点に注意）
  3. Signature: 秘密鍵を用いて生成された署名。改ざん検知に使われる

3.3 処理フロー

  1. ログイン成功
  2. サーバーが秘密鍵を使って署名付き JWT を生成
  3. クライアントに JWT を渡す（Cookie / localStorage 等）
  4. リクエストごとに JWT を HTTP ヘッダー（Authorization: Bearer ~）等に乗せて送る
  5. サーバーは 署名を検証するだけ で、改ざんされていなければ正しいユーザーとみなす

3.4 メリット

  • スケーラビリティが高い
    サーバーは状態を持たないため、DB や Redis を参照する必要がなく、スケールしやすい。
  • マイクロサービス・マルチデバイスに強い
    発行されたトークンがあれば、別の API サーバーやモバイルアプリでも共通して認証できる。

3.5 デメリット

  • 即時ログアウト（無効化）が難しい
    一度発行したパスポートは、有効期限が切れるまで使い続けられてしまう。
    → リフレッシュトークンを併用することでリスク低減（3.6 参照）
  • セキュリティ設計の責任がクライアント寄りになる
    JWT 自体に重要な情報を含めない、XSS 対策（localStorage ではなく HttpOnly Cookie を使う等）など、保存場所と扱いにより注意が必要。

3.6 【重要】トークン認証の弱点を補う「リフレッシュトークン」

JWT の「一度発行すると無効化しにくい」というデメリットを解消するために、実際は 「アクセストークン」と「リフレッシュトークン」の 2 本立て で運用するのが一般的です。

種類 有効期限 役割 保存場所の例
Access Token 短い (例: 30 分) API へのアクセス証 メモリ / JS 変数
Refresh Token 長い (例: 2 週間) アクセストークンの再発行 HttpOnly Cookie

なぜ分けるのか？

  1. セキュリティ向上: アクセストークンの寿命を極端に短くすることで、万が一盗まれても被害を最小限に抑えられます。
  2. UX の維持: 有効期限が切れても、裏でリフレッシュトークンを使って新しいアクセストークンを取得すれば、ユーザーはログインし直す必要がありません。
  3. 擬似的な強制ログアウト: サーバー側で「リフレッシュトークンの無効化」を行えば、次の更新タイミングで再発行ができなくなり、実質的な強制ログアウトが可能になります。

4. 両者の比較まとめ

観点 セッション認証 JWT 認証
状態管理 サーバー (Stateful) クライアント (Stateless)
本質のイメージ クロークの番号札 パスポート
データの場所 サーバーにある クライアント（トークン）内にある
改ざん対策 不要（ID は無意味） 署名(Signature)で検知
スケーラビリティ 中（工夫が必要） 高
即時ログアウト ◎（容易） △（難しい）

「どちらが優れているか？」ではなく、要件による使い分けが重要です。

社内管理システムや B2B 業務アプリのように、利用者が特定されており、「退職時や紛失時に即座にアカウントを停止させたい（強制ログアウト）」という要件が強いシステムであれば、セッション認証の方が安全かつ確実です。

一方で、SNS や EC サイトのように不特定多数がアクセスし、スマホアプリとも連携するような大規模サービスなら、スケーラビリティに優れた JWT が適しています。

5. 面接での模範回答例

両者の最大の違いは 認証状態（ステート）をどこで管理するか だと理解しています。

セッション認証はサーバー側で状態を管理する方式です。『ホテルのクローク』のように、番号札だけでやり取りするため、サーバー側で強制ログアウトなどの制御が容易ですが、スケール時にはセッション共有の仕組みが必要になります。

JWT 認証はクライアント側に情報を持たせる『パスポート』のような方式です。サーバーはステートレスになり、スケーラビリティが高くマイクロサービス等に適しています。

一方で、JWT は即時無効化が難しいため、「有効期限の短いアクセストークン」と「再発行用のリフレッシュトークン」を組み合わせる構成をとるのが一般的だと理解しています。これならセキュリティリスクを抑えつつ、スケーラビリティも享受できるからです。

サービスの規模や要件に応じて、これらを適切に選定・使い分けることが重要だと考えています。

6. まとめ

  • セッション認証とトークン認証の違いは “状態管理の場所”
  • セッション認証は Stateful、トークン認証は Stateless
  • JWT は実務では リフレッシュトークン とセットで使うことが多い

本記事が、技術面接に向けた理解整理と、日々の開発設計の参考になれば幸いです。

参考文献

GitHubで編集を提案

Discussion