「JWT」と「セッション」の違いは？Cookie・ログイン状態・トークン認証との関係もわかりやすく解説

「ログイン状態はセッションで管理する」

「API認証にはJWTを使う」

Web開発や認証について調べていると、「JWT」と「セッション」という言葉をよく目にします。

そのため、

「JWTとセッションはどちらを使えばいい？」

「JWTならセッションは不要？」

「Cookieとセッションは同じ？」

「JWTはCookieの代わり？」

「JWTにユーザー情報を入れればサーバー保存は不要？」

「JWTの中身は暗号化されている？」

と迷うことがあります。

結論からいうと、「JWT」と「セッション」は本来、直接対になる言葉ではありません。

JWTは、

情報（Claims）をJSON形式で表現し、署名や暗号化を利用できるトークン形式

です。

一方、セッションは、

複数回のHTTP通信をひとまとまりとして扱い、利用者のログイン状態などを継続して管理する考え方・仕組み

です。

Web開発で「JWTとセッションの違い」と比較される場合、多くは、

「JWTなどにユーザー情報・権限情報を持たせる方式」

と、

「ブラウザにはランダムなセッションIDだけを持たせ、状態をサーバー側で管理する方式」

の違いを指しています。

一言で覚えるなら、

JWT＝「情報を運ぶトークンの形式」

セッション＝「一定期間、利用者の状態を管理する仕組み」

です。

RFC 7519では、JWT（JSON Web Token）を、2者間でClaimsを転送するためのコンパクトでURLセーフな方法と定義しています。

一方、OWASPはWebセッションについて、同じユーザーに関連付けられた一連のHTTPリクエスト・レスポンスをまとめて扱い、認証状態やアクセス権限などを複数のリクエスト間で維持する仕組みとして説明しています。

この記事では、「JWT」と「セッション」の基本的な違いから、セッションID、Cookie、アクセストークン、IDトークン、ステートレス、ログアウト、失効、localStorageとの関係まで詳しく解説します。

  1. 「JWT」と「セッション」の違い【結論】
  2. そもそも「セッション」とは？
    1. 複数のHTTP通信を同じ利用者の一連の操作として扱う仕組み
  3. 典型的な「サーバー側セッション」の仕組み
  4. 「JWT」とは？
    1. Claimsを受け渡すためのコンパクトなトークン形式
  5. JWTは通常どんな形をしている？
  6. JWTのPayloadは暗号化されている？
  7. JWTにパスワードを書いてもいい？
  8. JWTは「ログイン状態を保存する仕組み」なの？
  9. JWTとセッションIDの違い
  10. 「ステートフル」と「ステートレス」の違い
  11. JWTでもサーバー側のデータを使うことがある
  12. JWTとCookieの違い
  13. セッションとCookieの違い
  14. 「JWTをCookieに保存」と「セッションIDをCookieに保存」はどう違う？
  15. JWTはlocalStorageに保存するもの？
  16. HttpOnly Cookieとは？
  17. Secure Cookieとは？
  18. SameSiteとは？
  19. JWTならCSRF対策は不要？
  20. JWTならXSSに強い？
  21. 「JWT＝署名されているから安全」ではない
  22. JWTの代表的なClaims
  23. JWTとアクセストークンは同じ？
  24. JWTとIDトークンは同じ？
  25. JWTならデータベースを毎回見なくてよい？
  26. セッション方式のメリット
  27. セッション方式のデメリット
  28. JWT方式のメリット
  29. JWT方式のデメリット
  30. JWTはログアウトできない？
  31. セッションIDを盗まれた場合は安全？
  32. JWTを盗まれた場合は？
  33. 「JWT・セッション」で迷ったときの3秒判定
  34. 「JWT」を使った例文
  35. 「セッション」を使った例文
  36. 具体例で比較：一般的な会員サイト
  37. 具体例で比較：APIでJWTを利用
  38. よくある間違い1：「JWTとセッションは完全な二者択一」と思う
  39. よくある間違い2：「JWTなら必ずステートレス」と思う
  40. よくある間違い3：「JWTは暗号化されている」と思う
  41. よくある間違い4：「JWTとCookieはどちらかを選ぶ」と思う
  42. よくある間違い5：「JWTならデータベースは不要」と思う
  43. よくある間違い6：「セッションIDは単なる番号なので盗まれても安全」と思う
  44. よくある間違い7：「署名済みJWTなら盗まれても使えない」と思う
  45. 「JWT」と「セッション」に関するよくある質問
    1. Q1. 「JWT」と「セッション」の一番簡単な違いは？
    2. Q2. JWTを使えばセッションは不要ですか？
    3. Q3. セッションとCookieは同じですか？
    4. Q4. JWTとCookieは同じですか？
    5. Q5. JWTの中身は誰でも読めますか？
    6. Q6. JWTの署名は何のためにありますか？
    7. Q7. JWTならログアウトできないのですか？
    8. Q8. アクセストークンは必ずJWTですか？
    9. Q9. IDトークンはJWTですか？
    10. Q10. JWTとサーバー側セッション、どちらが優れていますか？
  46. まとめ
  47. 参考リンク・出典

「JWT」と「セッション」の違い【結論】

比較項目 JWT セッション
正式名称・意味 JSON Web Token 一連の通信・利用状態を継続して管理する仕組み
分類 トークン形式 状態管理の概念・仕組み
主な用途 Claimsの受け渡し、認証・認可関連のトークンなど ログイン状態、権限、カート、設定等の維持
データの場所 トークン自身にClaimsを含められる 方式による。典型的にはサーバー側に状態を保存し、ブラウザはセッションIDを保持
Cookieとの関係 Cookieに保存することもできる セッションIDをCookieで保持することが多い
サーバー側状態 自己完結型として利用すれば減らせる場合がある 典型的なサーバーセッションでは保持する
失効 設計によっては即時失効に追加の仕組みが必要 サーバー側セッションを削除・無効化しやすい

3秒で判断するなら、

「情報をClaimsとして持ち運ぶトークン形式？」 → JWT

「ログイン状態を複数の通信にわたって維持する仕組み？」 → セッション

と考えてください。

そもそも「セッション」とは？

複数のHTTP通信を同じ利用者の一連の操作として扱う仕組み

HTTPは基本的にステートレスなプロトコルです。

つまり、HTTPそのものは、前のリクエストと次のリクエストが同じ利用者から送られたものなのかを自動的に記憶してくれるわけではありません。

しかし実際のWebサービスでは、

  • ログイン状態
  • ショッピングカート
  • 表示言語
  • アクセス権限
  • 利用者ごとの設定

などを、ページを移動しても維持する必要があります。

そこで利用されるのが、

セッション管理

です。

MDNも、HTTPには個別のリクエストを関連付ける仕組みが組み込まれていないため、Webサイト側で一連のリクエストを同じクライアントのセッションとして扱う仕組みが必要になると説明しています。

典型的な「サーバー側セッション」の仕組み

一般的なWebアプリでは、次のような方法があります。

  1. 利用者がID・パスワードなどでログインする
  2. サーバーが本人確認を行う
  3. サーバーがランダムなセッションIDを発行する
  4. ブラウザがセッションIDをCookieなどに保存する
  5. 以後のアクセスでブラウザがセッションIDを送信する
  6. サーバーがセッションIDに対応するユーザー情報・権限等を確認する

たとえばブラウザ側には、

abc123xyz…

のような意味を持たないセッションIDだけを保存します。

一方、サーバー側では、

  • セッションID
  • ユーザーID
  • 権限
  • ログイン時刻
  • 有効期限

などを対応付けて管理します。

OWASPは、クライアント側のセッションIDには利用者情報などの意味を持たせず、実際のセッション情報はサーバー側のセッション管理領域に保存する方式を説明しています。

「JWT」とは？

Claimsを受け渡すためのコンパクトなトークン形式

JWTは、

JSON Web Token

の略です。

RFC 7519では、JWTを、

2者間でClaimsを転送するための、コンパクトでURLセーフな方法

として標準化しています。

Claim（クレーム）とは、主体やトークンについての情報です。

たとえば、

  • 誰に関するトークンか
  • 誰が発行したか
  • 誰向けか
  • いつまで有効か

といった情報を表せます。

JWTは通常どんな形をしている？

JWS形式で署名された一般的なJWTは、

xxxxx.yyyyy.zzzzz

のように、ピリオドで区切られた3つの部分を持ちます。

代表的には、

  1. Header
  2. Payload
  3. Signature

です。

部分 主な内容
Header トークン種別や署名アルゴリズムなど
Payload Claims
Signature 改ざん検出・署名検証に利用

ただしJWTはJWSによる署名だけでなく、JWEによって暗号化された形で利用することもできます。

JWTのPayloadは暗号化されている？

必ずしも暗号化されていません。

非常に重要なポイントです。

一般的な署名付きJWTのHeaderやPayloadは、Base64url形式でエンコードされています。

エンコードは暗号化ではありません。

そのため、JWTを入手した人がPayloadの内容を読み取れる場合があります。

署名の役割は主に、

「内容が改ざんされていないことを検証する」

ことであり、

「中身を読めなくする」

ことではありません。

内容自体を秘匿する必要がある場合には、JWEなど適切な暗号化方式を利用する必要があります。

JWTにパスワードを書いてもいい？

原則として避けるべきです。

JWTのPayloadは暗号化されていない場合があるため、

  • パスワード
  • クレジットカード番号
  • 秘密鍵
  • 不必要な個人情報

などの機密情報を安易に格納すべきではありません。

JWTには、その用途に必要な最小限のClaimsだけを含めることが基本です。

JWTは「ログイン状態を保存する仕組み」なの？

JWT自体は、ログイン状態を管理する仕組みそのものではありません。

あくまでトークン形式です。

しかしJWTを、

  • アクセストークン
  • IDトークン
  • アプリ独自のログイン用トークン

などとして利用し、結果的にユーザーのログイン状態を維持するシステムを構築することはできます。

そのため実務では、

「JWT認証」

「JWTセッション」

などと呼ばれることがあります。

ただし技術的には、

JWT＝認証方式そのもの

ではありません。

JWTとセッションIDの違い

実際に比較すると分かりやすくなります。

典型的なサーバー側セッションでは、ブラウザが保持するセッションIDそのものには大きな意味を持たせません。

たとえば、

session_id=8fX92k…

のようなランダム値です。

サーバーはその値をキーにして、サーバー側のデータベースなどから、

  • ユーザーID
  • 権限
  • ログイン状態

を調べます。

一方、自己完結型JWTでは、トークン自身に、

  • sub
  • iss
  • aud
  • exp
  • その他のClaims

を持たせ、署名を検証して利用できます。

「ステートフル」と「ステートレス」の違い

JWTとセッションを比較するときによく登場するのが、

ステートフル

と、

ステートレス

です。

典型的なサーバー側セッションでは、サーバーがセッション状態を保存するため、

ステートフル

と説明されます。

一方、JWTに必要なClaimsを含め、サーバーがトークンを検証するだけで処理できる構成なら、サーバー側のセッション保存を減らし、

ステートレス

な設計にしやすくなります。

ただし、

JWTを使えば必ず完全にステートレスになる

わけではありません。

JWTでもサーバー側のデータを使うことがある

JWTを利用していても、

  • ユーザーが無効になっていないか
  • トークンを強制失効していないか
  • 現在の権限は何か
  • セッションを終了させたか

などを確認するため、サーバー側データを参照する設計があります。

失効リストを保持すれば、それ自体がサーバー側状態です。

したがって、

「JWT＝ステートレス」「セッション＝ステートフル」

と完全に二分するのは正確ではありません。

JWTとCookieの違い

JWTとCookieもよく混同されますが、分類が異なります。

JWT＝トークンのデータ形式

Cookie＝ブラウザとサーバー間で小さなデータを保存・送信するHTTPの仕組み

です。

したがって、JWTをCookieに保存することもできます。

つまり、

「JWTかCookieか」

という二者択一ではありません。

セッションとCookieの違い

セッションとCookieも同じものではありません。

典型的なサーバー側セッションでは、

セッションIDをCookieに保存する

方式が広く使われます。

MDNも、基本的なログインシステムの例として、サーバーがセッションIDを含むCookieをブラウザへ送り、その後のリクエストでブラウザがCookieを送り返す仕組みを説明しています。

つまり、

セッション＝状態を管理する仕組み

Cookie＝セッションID等をブラウザに保持・送信する手段

です。

「JWTをCookieに保存」と「セッションIDをCookieに保存」はどう違う？

方式 Cookieに入るもの 主な情報の場所
サーバー側セッション ランダムなセッションID 主にサーバー側
JWT利用 JWTそのものを入れることがある ClaimsをJWT内部に持てる

どちらもCookieを利用できます。

違うのは、Cookieという保存手段ではなく、

Cookieに何を入れ、サーバー側でどのように状態を管理するか

です。

JWTはlocalStorageに保存するもの？

JWTだからlocalStorageへ保存しなければならない、という決まりはありません。

JWTはトークン形式なので、保存方法は別の設計問題です。

ブラウザでは、

  • Cookie
  • メモリ
  • localStorage
  • sessionStorage

など、複数の方法が考えられます。

ただしセキュリティ特性が異なります。

MDNは、認証済みセッションのセッション識別子を保存する方法としてCookieを推奨し、その理由の一つとして、HttpOnly属性によってJavaScriptからCookieへアクセスできないようにできることを挙げています。

一方、localStorageの値は同一オリジンのJavaScriptから読み取れるため、XSSへの対策を含めて慎重な設計が必要です。

HttpOnly Cookieとは？

Cookieには、

HttpOnly

という属性があります。

HttpOnlyを付けることで、そのCookieへJavaScriptから直接アクセスできないようにできます。

セッションIDなどをCookieで管理する際、XSSによってトークンそのものを盗まれるリスクを減らすために重要な設定です。

ただし、HttpOnlyを付ければXSSの影響が完全になくなるわけではありません。

悪意あるJavaScriptが利用者のブラウザから不正なリクエストを実行できる場合もあるため、XSSそのものへの対策も必要です。

Secure Cookieとは？

Cookieには、

Secure

属性もあります。

Secure属性を設定すると、そのCookieは基本的にHTTPSの安全な接続を通して送信されます。

認証やセッションに関わるCookieでは、通信経路上での窃取を防ぐために重要な設定です。

SameSiteとは？

Cookieの、

SameSite

属性は、クロスサイトリクエストでCookieをどのように送信するか制御するために利用されます。

CSRF（Cross-Site Request Forgery）などのリスク低減にも関係します。

したがって、

「Cookieは危険だからJWTをlocalStorageへ保存すれば安全」

という単純な考え方は適切ではありません。

どの保存方式でも、その方式に応じた脅威と対策を考える必要があります。

JWTならCSRF対策は不要？

保存・送信方法によります。

JWTをAuthorizationヘッダーへ明示的に付ける方式と、JWTをCookieに格納してブラウザが自動送信する方式では、考えるべき攻撃モデルが異なります。

JWTという形式そのものがCSRFを防ぐわけではありません。

重要なのは、

「JWTかどうか」ではなく、「認証情報をどのように保存し、どのように送信するか」

です。

JWTならXSSに強い？

JWTというだけでXSSへ強くなるわけではありません。

たとえばJWTをlocalStorageへ保存し、攻撃者のJavaScriptから読み取れる状態であれば、XSSによってトークンを盗まれるリスクがあります。

一方、HttpOnly CookieならJavaScriptからCookieの値そのものを直接読み取ることはできません。

ただし前述のとおり、HttpOnly CookieもXSSの影響を完全に無効にするわけではありません。

「JWT＝署名されているから安全」ではない

JWTは正しく検証されなければ安全ではありません。

RFC 8725「JSON Web Token Best Current Practices」では、JWTの実装で、

  • 署名アルゴリズムを正しく検証する
  • 安全な暗号アルゴリズムだけを許可する
  • すべての暗号処理を検証する
  • issuerを確認する
  • audienceを確認する
  • 用途の異なるJWTを混同しない

などが重要なベストプラクティスとして示されています。

JWT形式を採用しただけで安全性が保証されるわけではありません。

JWTの代表的なClaims

RFC 7519では、代表的な登録済みClaimとして次のようなものがあります。

Claim 意味
iss Issuer：発行者
sub Subject：主体
aud Audience：想定される受信者
exp Expiration Time：有効期限
nbf Not Before：利用開始可能時刻
iat Issued At：発行時刻
jti JWT ID：JWTの識別子

用途に応じて独自Claimを追加することも可能です。

JWTとアクセストークンは同じ？

同じではありません。

JWTは形式

であり、

アクセストークンは用途

です。

OAuthのアクセストークンがJWT形式で発行されることはあります。

しかしOAuth 2.0では、アクセストークンが必ずJWTでなければならないとは定められていません。

サーバーにとってだけ意味のあるランダムな文字列、いわゆるOpaque Tokenを使うこともできます。

JWTとIDトークンは同じ？

これも完全な同義ではありません。

OpenID Connectでは、

ID TokenはJWT

として定義されています。

つまり、

IDトークン＝JWTを利用した特定用途のトークン

です。

しかし、すべてのJWTがIDトークンというわけではありません。

JWTならデータベースを毎回見なくてよい？

自己完結型JWTを使うメリットの一つとして、トークン内のClaimsと署名を検証することで、毎回セッションストアへ問い合わせなくても処理できる場合があります。

これは分散システムやAPIで便利な場合があります。

しかし、

  • アカウントが停止された
  • 権限が途中で変更された
  • ユーザーが強制ログアウトされた
  • トークンが漏えいした

場合に、発行済みJWTをどう扱うかという問題が生じます。

最新状態を毎回確認するなら、結局サーバー側データへの問い合わせが必要になることもあります。

セッション方式のメリット

典型的なサーバー側セッションには、次のような利点があります。

  • クライアント側には意味のないセッションIDだけを持たせられる
  • ユーザー情報・権限などをサーバー側で変更しやすい
  • セッションをサーバー側で即座に無効化しやすい
  • トークン内に多くの情報を入れる必要がない

特に、

「今すぐこの利用者をログアウトさせたい」

という場面では、サーバー側のセッションを削除・無効化できる構成が扱いやすい場合があります。

セッション方式のデメリット

一方で、サーバー側にセッション情報を保持するため、

  • セッションストアが必要
  • 複数サーバー間で状態を共有する必要がある場合がある
  • 大量ユーザー時のセッション管理を考える必要がある

といった点があります。

ただしRedis等の共有セッションストアなど、一般的な解決方法もあります。

JWT方式のメリット

自己完結型JWTには、

  • Claimsをトークン自身に含められる
  • 複数サービスで署名を検証できる
  • セッションストアへの問い合わせを減らせる場合がある
  • OAuth・OpenID Connectなどとの相性がよい

といった特徴があります。

特にAPIや複数サービスをまたぐシステムで役立つ場合があります。

JWT方式のデメリット

JWTにも注意点があります。

  • 発行済みトークンの即時失効が難しい場合がある
  • Claimsを増やすとトークンサイズが大きくなる
  • Payloadが暗号化されていると誤解されやすい
  • 署名・Issuer・Audience・有効期限等を正しく検証する必要がある
  • 用途の異なるJWTを混同すると脆弱性につながる

OWASPも、JWTはさまざまな用途で使われる一方、「ステートレスなユーザーセッション」へ安易に利用することには注意が必要であるとしています。

JWTはログアウトできない？

正確には、

「自己完結型JWTは、発行後の即時失効に工夫が必要になる場合がある」

と考えるのが適切です。

有効期限が30分残っているJWTなら、署名とClaimsだけを確認する完全なステートレス構成では、サーバーはその30分間トークンを有効と判断する可能性があります。

対策として、

  • アクセストークンの有効期限を短くする
  • 失効リストを利用する
  • サーバー側でセッション状態を持つ
  • Refresh Tokenを適切に管理する
  • 鍵やトークンバージョンを管理する

など、システムに応じた設計が必要です。

セッションIDを盗まれた場合は安全？

安全ではありません。

有効なセッションIDを攻撃者に盗まれると、そのセッションを乗っ取られる可能性があります。

OWASPは、認証済みセッションのセッションID・トークンは、その利用者が行った強力な認証と一時的に同等の価値を持つと説明しています。

そのため、

  • HTTPS
  • Secure Cookie
  • HttpOnly
  • SameSite
  • 適切な有効期限
  • ログイン時のセッションID更新

などの対策が重要です。

JWTを盗まれた場合は？

JWTも、Bearer Tokenとして利用している場合、盗んだ人が有効期限内にそのトークンを提示できれば、不正利用される可能性があります。

署名付きだから盗まれても問題ない、ということではありません。

署名は、

「攻撃者がトークンを書き換えにくくする」

ためのものであり、

「盗まれた正規トークンを使用できなくする」

機能とは別です。

「JWT・セッション」で迷ったときの3秒判定

こんな場合 答え
ClaimsをJSON形式で運ぶトークン JWT
ログイン状態を複数リクエスト間で維持 セッション
ランダムなIDをサーバー側状態と対応付ける 典型的なサーバー側セッション
iss・sub・aud・exp等をトークンに含める JWT
セッションIDをブラウザへ保存する Cookieがよく使われる
JWTをブラウザへ保存する Cookie等を利用できる
ID Token OpenID Connectで使われるJWT

最も簡単に覚えるなら、

JWT＝「トークンの形式」

セッション＝「状態を続けて管理する仕組み」

です。

「JWT」を使った例文

  • APIのアクセストークンとしてJWTを利用する。
  • JWTの署名と有効期限を検証する。
  • JWTのPayloadに必要なClaimsを含める。
  • IDトークンとしてJWTを受け取る。
  • JWTのAudienceが想定したサービスと一致するか確認する。

「セッション」を使った例文

  • ログイン後にセッションを作成する。
  • セッションの有効期限を設定する。
  • ログアウト時にセッションを無効化する。
  • CookieへセッションIDを保存する。
  • 長時間操作がなかったためセッションが切れた。

具体例で比較：一般的な会員サイト

会員サイトへログインするとします。

サーバーはログインに成功すると、ランダムなセッションIDを作成します。

ブラウザにはセッションIDをCookieで渡し、サーバー側には、

セッションID → ユーザーA

という対応関係を保存します。

次にページを開くと、ブラウザがセッションIDを送信し、サーバーが、

「この通信はユーザーAのセッションである」

と判断します。

これが典型的なサーバー側セッション方式です。

具体例で比較：APIでJWTを利用

API利用時にJWT形式のアクセストークンが発行されたとします。

JWTには、

  • 発行者
  • ユーザーやクライアントの識別子
  • Audience
  • 有効期限
  • 権限に関係するClaims

などが含まれる場合があります。

API側はJWTの署名・Issuer・Audience・有効期限等を検証し、アクセスを許可するか判断します。

この構成では、毎回中央のセッションストアへ問い合わせず処理できる場合があります。

よくある間違い1：「JWTとセッションは完全な二者択一」と思う

違います。

JWTはトークン形式、セッションは状態管理の概念です。

JWTを利用したセッション管理も可能です。

よくある間違い2：「JWTなら必ずステートレス」と思う

JWTを利用していても、失効リスト・ユーザー状態・権限等をサーバー側で確認する構成があります。

JWTを使っただけで完全にステートレスになるわけではありません。

よくある間違い3：「JWTは暗号化されている」と思う

署名付きJWTのPayloadは通常、暗号化ではなくBase64urlエンコードされています。

機密情報を安易に格納してはいけません。

よくある間違い4：「JWTとCookieはどちらかを選ぶ」と思う

JWTをCookieへ保存できます。

JWTはデータ形式、Cookieはブラウザとサーバー間でデータを保持・送信する仕組みなので、分類が異なります。

よくある間違い5：「JWTならデータベースは不要」と思う

システムによります。

ユーザー情報・権限・失効状態などを最新状態で確認する必要があれば、サーバー側データを利用する場合があります。

よくある間違い6：「セッションIDは単なる番号なので盗まれても安全」と思う

有効なセッションIDを盗まれると、利用者になりすまされる可能性があります。

セッションID自体を重要な認証情報として保護する必要があります。

よくある間違い7：「署名済みJWTなら盗まれても使えない」と思う

署名は改ざん検知・真正性確認のための仕組みです。

有効なBearer Tokenとして使われているJWTを盗まれれば、攻撃者に再利用される可能性があります。

「JWT」と「セッション」に関するよくある質問

Q1. 「JWT」と「セッション」の一番簡単な違いは？

JWTは情報を運ぶトークン形式、セッションは利用者の状態を複数の通信にわたって維持する仕組みです。

Q2. JWTを使えばセッションは不要ですか？

必ずしもそうではありません。

JWTを使ってログイン状態を管理することも一種のセッション管理と考えられますし、失効・権限確認などのためサーバー側状態を併用する場合もあります。

Q3. セッションとCookieは同じですか？

違います。

セッションは状態管理の仕組みで、CookieはセッションIDなどをブラウザへ保存・送信するために利用できる仕組みです。

Q4. JWTとCookieは同じですか？

違います。

JWTはトークン形式、CookieはHTTPの状態管理・データ送受信の仕組みです。

JWTをCookieに格納することもできます。

Q5. JWTの中身は誰でも読めますか？

署名付きJWTのPayloadは暗号化されていないことが多く、Base64urlをデコードすれば読み取れる場合があります。

機密情報を入れる場合は適切な暗号化方式を検討する必要があります。

Q6. JWTの署名は何のためにありますか？

主にトークンが不正に変更されていないことや、適切な発行者によって生成されたことを検証するために利用します。

内容を見えなくすることとは別です。

Q7. JWTならログアウトできないのですか？

ログアウト自体は実装できます。

ただし完全に自己完結型の長寿命JWTでは、発行済みトークンを即座に無効化するため、失効リストなど追加の仕組みが必要になる場合があります。

Q8. アクセストークンは必ずJWTですか？

いいえ。

アクセストークンは用途を表す言葉で、JWT形式の場合もあれば、サーバーだけが意味を解釈できるOpaque Tokenの場合もあります。

Q9. IDトークンはJWTですか？

OpenID Connectでは、IDトークンはJWTとして定義されています。

ただし、すべてのJWTがIDトークンという意味ではありません。

Q10. JWTとサーバー側セッション、どちらが優れていますか？

一律にどちらが優れているとはいえません。

アプリケーションの規模、API構成、失効要件、セキュリティ要件、運用方法などによって適切な方式は異なります。

「流行しているからJWT」「昔からあるからセッション」ではなく、要件に合わせて選択することが重要です。

まとめ

「JWT」と「セッション」は、Web認証で一緒に語られることが多い言葉ですが、本来は同じ分類の技術ではありません。

JWT セッション
JSON Web Token 一連の通信・状態を管理する仕組み
トークン形式 状態管理の概念
Claimsを含められる ログイン状態等を維持する
署名・MAC・暗号化等を利用可能 典型的にはセッションIDを利用
OAuth・OpenID Connect等でも利用 一般的なWebログインで広く利用

最も簡単な覚え方は、

JWT＝「情報を運ぶトークンの形式」

セッション＝「利用者の状態を継続して管理する仕組み」

です。

典型的なサーバー側セッションでは、ブラウザへランダムなセッションIDを渡し、ユーザー情報・権限などの状態をサーバー側で管理します。

一方、JWTを自己完結型トークンとして利用すれば、

ユーザー識別子

発行者

Audience

有効期限

などのClaimsをトークン自身に持たせられます。

ただし、

JWT＝セッション不要

JWT＝必ずステートレス

JWT＝暗号化されていて中身を読めない

JWT＝Cookieの代わり

という理解はいずれも正確ではありません。

また、JWTでもセッションIDでも、盗まれれば不正利用される可能性があります。

トークン形式だけで安全性が決まるわけではなく、

  • HTTPS
  • 安全な保存方法
  • 適切な有効期限
  • 失効設計
  • 署名検証
  • Issuer・Audienceの検証
  • XSS・CSRF対策

などを含めたシステム全体の設計が重要です。

参考リンク・出典

※本記事では、Web開発で一般に「JWT対セッション」と呼ばれる比較を扱っています。ただしJWTはトークン形式、セッションは状態管理の概念であるため、本来は完全な対義関係ではありません。

※JWTは必ずしも暗号化されません。JWS形式で署名されたJWTのPayloadは読み取れる場合があります。機密情報の格納には十分注意してください。

※JWTをアクセストークンとして利用するか、セッションID方式を利用するかは、システム要件によって適切な選択が異なります。

※トークンをCookie・localStorage・メモリ等のどこへ保存するかによって、XSS・CSRF等に対するリスクと対策が異なります。

※JWT・セッション管理に関するセキュリティ上の推奨事項は更新される場合があります。実装時にはRFC、OWASP、利用するフレームワーク等の最新資料を確認してください。

タイトルとURLをコピーしました