Zenn
🐶

JWT（JSON Web Token）入門：仕組みと認証の流れをわかりやすく解説

に公開
JWT
初心者向け
認証
tech

はじめに

Web アプリや API を作っていると「JWT 認証」という言葉をよく耳にします。ログイン処理や API アクセス制御に使われる仕組みですが、実際にどう動いているのか理解しづらいところがあります。

この記事では JWT とは何か、どのように作られて検証されるのか を初心者にも分かりやすく解説します。

JWT とは？

JWT（JSON Web Token）は、認証や情報のやり取りに使われる 署名付きのトークン です。見た目はただの文字列ですが、次の3つの部分に分かれています。

header.payload.signature

それぞれを Base64 エンコードした文字列を . でつなげています。

例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTczNTY4OTYwMH0.CfRkJpHQ7sI3ZPQ-5s0nWbQO4TwX2lW2z7XkUuN0Zp8

JWT の構成

1. ヘッダー（Header）

署名アルゴリズムやトークンの種類を記述します。

{
  "alg": "HS256",  // 署名アルゴリズム
  "typ": "JWT"
}

2. ペイロード（Payload）

実際にやり取りしたいデータ。誰のトークンか（sub） や 有効期限（exp） がよく入ります。

{
  "sub": "12345",      // ユーザーID
  "name": "Alice",    // 任意の情報
  "role": "admin",    // 権限
  "exp": 1735689600    // 有効期限（UNIX時間）
}

3. 署名（Signature）

改ざんされていないかを保証する部分です。

Signature = HMAC-SHA256(
  base64(header) + "." + base64(payload),
  秘密鍵
)

完成した JWT はこんな形式になります：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImV4cCI6MTczNTY4OTYwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT の流れ

1. ログイン

ユーザーが ID / パスワードを使ってログインします。
サーバーは認証に成功したら JWT を発行します：

  • header + payload を作成
  • header と payload を Base64 エンコードしてつなげる
  • 秘密鍵で署名を生成する
  • JWT：header.payload.signatureを完成させて返す

2. クライアントが JWT を保存

クライアント（ブラウザやアプリ）は JWT を Cookie や LocalStorage に保存します。

3. API リクエストに JWT を添付

その後のリクエストでは、HTTP ヘッダーに JWT をつけて送ります：

Authorization: Bearer <JWT>

4. サーバー側で検証

サーバーはリクエストを受け取ると次の流れで検証します：

1. JWT を分解

  • header.payload.signature に分ける

2. header と payload を Base64 デコード

3. 署名を再計算

  • 受け取った header と payload をつなげる
  • サーバーが持つ秘密鍵と header に書かれたアルゴリズムで署名を再生成する
  • フロントから送られてきた signature と突き合わせる→ 一致すれば「改ざんナシ」と判断。
    4. 有効性チェック
  • payload 内の exp が現在時刻より未来か確認（期限切れじゃないか）
  • 問題なければ payload の sub（ユーザーID）を取り出して処理を続ける

まとめ

  • JWT は header, payload, signature の 3 部構成
  • signature は「header+payload を秘密鍵でハッシュ化」して作る
  • サーバは秘密鍵を 一つ持って使い回す
  • フロントはログイン時にもらった JWT を Authorization ヘッダに載せて送る
  • サーバは毎回 署名を再計算して一致確認 → 改ざんされていないか保証できる

JWT のメリットと注意点

メリット

  • セッション情報をサーバーに保存しなくてよい（ステートレス）
  • API と相性が良い（複数サービス間で共通利用できる）
  • ペイロードに情報を含められる

注意点

  • ペイロードは Base64 でエンコードされているだけなので、誰でも読める → 機密情報は入れない
  • exp（有効期限）を必ず設定すること
  • 秘密鍵は絶対に漏洩させないこと

まとめ

  • JWT は「header.payload.signature」の形式のトークン
  • header と payload を Base64 エンコード → 秘密鍵で署名 → 完成
  • サーバーは署名を検証して改ざんを防ぐ
  • 認証・認可に広く使われている

JWT はシンプルですが、**「何が署名されていて」「どこまで誰でも見られるのか」**を理解するのが重要です。これを押さえておけば、API の認証まわりをより安全に設計できます。

Discussion