// シス担のミカタ
認証・ID管理

JWT（JSON Web Token） じぇいだぶりゅーてぃー

認証トークンOAuthセッション管理署名Base64クレーム
JWTについて教えて

簡単に言うとこんな感じ！

JWTは「改ざんできない電子の身分証明書」だよ！ログイン後にサーバーが発行する小さなデータの塊で、「あなたは〇〇さんです、権限はこれです」って情報を安全に持ち運べるんだ。パスポートみたいなイメージ！

JWTとは

JWT（JSON Web Token） は、2者間で情報を安全にやり取りするための、コンパクトで自己完結型のトークン形式です。RFC 7519 で標準化されており、Webサービスのログイン認証やAPIアクセス制御に広く使われています。

最大の特徴は「サーバー側でセッション情報を保存しなくていい」点です。従来のセッション管理では、ログイン情報をサーバーのメモリやデータベースに保存し、ユーザーがリクエストするたびに照合していました。JWTではその情報をトークン自体に埋め込んでデジタル署名するため、サーバーは署名を検証するだけで本物かどうか判断できます。

ビジネスの現場では、社内システムのシングルサインオン（SSO）やスマホアプリのAPI認証など、複数のサービスをまたいで認証情報を受け渡す場面で特に活躍しています。

JWTの構造：3つのパーツ

JWTは .（ドット）で区切られた3つのパーツから成り立っています。実際のトークンはこんな見た目です：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IuWxseeUsOWkqiIsImV4cCI6MTcwMDAwMDAwMH0
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
パーツ名前中身の例役割
第1部ヘッダー{"alg":"HS256","typ":"JWT"}署名アルゴリズムの種類
第2部ペイロード{"sub":"user123","name":"山田太郎","exp":1700000000}ユーザー情報・有効期限など
第3部署名ヘッダー＋ペイロードをシークレットキーで署名した値改ざん検出

各パーツは Base64URL という方式でエンコード（人間には読みにくい文字列に変換）されています。ペイロードの内容は暗号化ではないので、デコードすれば中身が見えます。機密情報（パスワード等）は入れてはいけません。

覚え方：「頭・中身・ハンコ」

「ヘッダー（頭）」「ペイロード（中身）」「署名（ハンコ）」と覚えましょう。書類に例えると、頭に書式のルール、中身に内容、最後に公式のハンコを押したもの、と考えると分かりやすいです。

ペイロードに入れられるクレームの例

クレーム（Claim） とはペイロードに入れる情報の単位です。

クレーム名意味例
subSubject（誰についての情報か）"user123"
expExpiration（有効期限）UNIXタイムスタンプ
iatIssued At（発行日時）UNIXタイムスタンプ
issIssuer（発行者）"auth.example.com"
role独自クレーム（権限）"admin"

歴史と背景

  • 2010年代初頭 — スマートフォンの普及でモバイルアプリのAPI認証需要が急増。Cookieベースのセッション管理がモバイル環境と相性が悪く、新しい認証方式が求められた
  • 2015年 — IETF（インターネット標準化団体）が RFC 7519 としてJWTを正式に標準化
  • 同年 — OAuth 2.0 や OpenID Connect との組み合わせが普及し、GoogleやFacebookなど大手のSSO（シングルサインオン）にも採用される
  • 2016年〜 — マイクロサービスアーキテクチャの台頭とともに、サービス間の認証手段としてJWTが事実上の標準に
  • 現在 — AWSやAzure、Auth0 など主要なクラウド・認証サービスが標準対応。ほぼすべてのWebフレームワークにライブラリが存在する

セッション方式 vs JWT方式

従来のセッション認証と比較することで、JWTのメリット・デメリットが見えてきます。

セッション認証 vs JWT認証 従来のセッション認証 JWT認証 ① ユーザーがID/PW送信 ② サーバーがセッションIDを生成しDB保存 ① ユーザーがID/PW送信 ② サーバーがJWTを生成して返却 ③ セッションIDをCookieで保存 ④ 次回リクエストにCookieを添付 ③ JWTをブラウザ/アプリに保存 ④ 次回リクエストにJWTを添付 ⑤ サーバーがDBでセッションを照合 ⑥ 一致すればOK ⑤ サーバーが署名を検証するだけ ⑥ DB不要でOK判定 項目 セッション JWT サーバー負荷 DB照合あり（高め） 署名検証のみ（低め） ログアウト即時反映 簡単（DBから削除） 難しい（有効期限まで有効） 複数サービス対応 難しい（DB共有が必要） 簡単（トークンを渡すだけ）

JWTの注意点

  • ペイロードは暗号化されていない — デコードすれば誰でも中身を読める。パスワードや個人情報は絶対に入れない
  • 有効期限が切れるまで無効化が難しい — 強制ログアウト機能が必要な場合は「トークンブラックリスト」などの追加実装が必要
  • トークンが長い — 情報を埋め込むほどサイズが増え、毎回のリクエストに含めるコストが上がる
  • 署名アルゴリズムの選択が重要 — 脆弱な none アルゴリズムを許可する実装はセキュリティホールになるため、必ず HS256 や RS256 を指定する

関連する規格・RFC

規格・RFC番号内容
RFC 7519JWT本体の仕様
RFC 7515JWS（JSON Web Signature）：署名の仕様
RFC 7516JWE（JSON Web Encryption）：暗号化の仕様
RFC 7517JWK（JSON Web Key）：鍵の表現形式
RFC 6749OAuth 2.0：JWTが多用される認可フレームワーク
OpenID Connect 1.0OAuth 2.0の上に構築されたID連携仕様。IDトークンにJWTを使用

関連用語