2026-01-12
JWTについて
JWT(JSON Web Token)
JSON形式の情報をURLセーフな文字列にしたトークン形式
URLセーフ
予約文字（?,&,=,/,+,%,#）を除いた、URLが壊れない文字で構成された文字列のこと
構造
header.payload.signature
- header: メタ情報（どのアルゴリズムで署名・暗号化されているか、トークン種別など）
- payload: ユーザー情報、権限、有効期限など
- signature: 改ざん検知用の署名情報（JWSの場合に使用）
何が嬉しいのか？
- ステートレス（サーバに状態を持たない）ため、認証自体を高速かつスケールしやすい
a. 高速: セッション認証方式だと、DBにアクセスしてセッションIDに対応したIDを引っ張ってくるため、DBアクセスしない分処理が高速
b. スケールしやすい: JWT認証方式ではDBアクセスがない分、サーバを増やしてもDB部分がボトルネックになりにくい、JWT自体に認証に必要な情報を詰め込んでいるので、サーバを増やしやすい - 色々な環境に使いやすい
a. セッション認証方式では、以下の手順で認証をしているためCookieに依存している。
ⅰ. ログイン時にsession_id発行
ⅱ. サーバ側はブラウザ側にSet-Cookieヘッダを送信
ⅲ. ブラウザ側がSet-Cookieを受け取り、Cookieにセット
ⅳ. 認証後リクエストはCookieからsession_idを取得してサーバ側で処理
JWTの弱点
- 即時制御、状態同期が苦手
- JWT取得→ログアウトしても、JWT期限が有効なうちは、そのJWTで認証が通る
- サーバでJWTを保存していないので、無効化したかどうかはそのJWTでは分からない
- 攻撃されて盗まれると情報漏洩、意図しない操作に繋がる
- 権限変更・BANをしても、同様にそれ以前に取得したJWTでは認証が通る
- JWT取得→ログアウトしても、JWT期限が有効なうちは、そのJWTで認証が通る
対策
- そもそも即時ログアウト（無効化）が厳密にはできないことを許容する設計にする
- JWTの有効期限を短く設定