JWT（JSON Web Token）についてまとめてみた
認証方式の種類
Webアプリケーションの認証方式は大きく以下の2つに分けられる。
- セッションベース認証
- トークンベース認証（JWT）
セッションベース認証とは
セッションベース認証では、サーバー側がユーザーの状態を保持する。
- ログイン成功時にセッションを作成
- セッションIDを Cookie に保存
- リクエストごとにセッションIDを照合
特徴
- サーバーがユーザー情報を保持する（ステートフル）
- スケールしにくい（サーバー増設時に共有が必要）
トークンベース認証とは
トークンベース認証では、サーバーはユーザーの状態を保持しない。
- ログイン時にトークン（JWT）を発行
- クライアントは リクエストごとにトークンを送信
- サーバーはトークンを検証するだけ
特徴
- ステートレス
- API・SPA・マイクロサービスと相性が良い
JWTとは
JWT（JSON Web Token）は、
自己完結型の認証情報を持つトークンで、以下の3つの部分から構成される。
- ヘッダ
- ペイロード
- 署名
JWTの構造
ヘッダ（Header）
{
"alg": "HS256",
"typ": "JWT"
}
- alg: 署名アルゴリズム
- typ: トークンの種類
ペイロード（Payload）
{
"sub": "123",
"role": "admin",
"exp": 1700000000
}
- sub: ユーザー識別子
- role: 権限情報
- exp: 有効期限（UNIX時間）
JWTはエンコードされているだけで、
誰でもデコードして中身を見ることができるため、
パスワードなどの機密情報は含めてはいけない
署名（Signature）
署名は以下の情報を元に生成される。
- Base64URL エンコードされたヘッダ
- Base64URL エンコードされたペイロード
JWTのヘッドとペイロードをヘッダのalgで指定したアルゴリズムと秘密鍵で署名
署名をさらにエンコード
- 秘密鍵
まとめると以下
これにより 改ざん検知が可能になる。
JWTの改ざん検知の仕組み
JWTを受け取ったサーバーは、
- ヘッダとペイロードから署名を再生成
- 受け取った署名と比較
一致しなければ改ざんと判断する。
秘密鍵を知らない（知られない）限り、正しい署名は作れない
JWT認証の流れ
- ユーザーがログイン
- 認証サーバーが JWT を発行
- クライアントが JWT を保存
- リクエストごとに JWT を送信
- サーバーが JWT を検証
JWTの弱み
- トークンの 即時無効化ができない
- 漏洩すると有効期限まで使われる
Refresh Token による解決
Access Token の有効期限を短くすると UX が悪化する。
そこで Refresh Token を使う。
- Access Token：短命
- Refresh Token：長命
- Refresh Token を使って新しい Access Token を再発行
Refresh Token によるJWT認証の流れ
JWTの保存先
❌ 非推奨
- localStorage
- sessionStorage
（XSS に弱い）
✅ 推奨
- HttpOnly Cookie
- CSRF 対策（SameSite / CSRF Token）が必須
まとめ
- JWTはステートレスな認証方式
- 改ざん検知はできるが暗号化ではない
- 保存場所と失効戦略が重要
- Refresh Token と組み合わせて使うのが実践的