JWTとは｜仕組みと、安全に使うための注意点

JWT（JSON Web Token、ジョット）とは、「誰が」「いつまで」といった情報をJSONで表し、改ざんされていないことを署名で確かめられるようにした文字列です。ログインしたユーザーの情報をサーバーからクライアントに渡し、以降のリクエストでそのトークンを送ることで、サーバーは「このリクエストは誰からのものか」を確認できます。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGUiOiJtZW1iZXIi...

JWTは便利な一方で、「中身は誰でも読める」「一度発行すると取り消しにくい」といった性質を理解せずに使うと、思わぬ問題につながります。この記事では、Python（PyJWT）で実際にトークンを作り、改ざんや期限切れを検証した結果を使って仕組みを解説し、安全に使うための注意点をまとめます。

JWTの早見表

JWTの3つの部分

JWTは、ヘッダー・ペイロード・署名の3つを . でつないだものです。

ペイロードでよく使う項目（登録済みクレーム）

実際にJWTを作って中身を見る

PythonのPyJWTで、トークンを作ります。

import jwt
from datetime import datetime, timedelta, timezone

SECRET = "change-me-to-a-long-random-secret-32bytes!!"
now = datetime.now(timezone.utc)
payload = {
    "sub": "user-123",
    "role": "member",
    "iat": now,
    "exp": now + timedelta(minutes=15),
}
token = jwt.encode(payload, SECRET, algorithm="HS256")

できたトークンの1つ目と2つ目の部分を、秘密鍵を使わずにBase64URLでデコードしてみます。

import base64
h, p, s = token.split(".")
pad = lambda x: x + "=" * (-len(x) % 4)
print(base64.urlsafe_b64decode(pad(h)).decode())
print(base64.urlsafe_b64decode(pad(p)).decode())

{"alg":"HS256","typ":"JWT"}
{"sub":"user-123","role":"member","iat":1790525729,"exp":1790526629}

秘密鍵がなくても、中身はそのまま読めました。JWTの署名は「改ざんされていないこと」を保証するもので、「中身を隠す」ものではありません。パスワード、個人情報、社内の機密情報をペイロードに入れてはいけません。

署名が改ざんを検出する仕組み

正しいトークンを検証する

jwt.decode(token, SECRET, algorithms=["HS256"])
# {'sub': 'user-123', 'role': 'member', 'iat': 1790525729, 'exp': 1790526629}

ペイロードを書き換えてみる

ペイロードの role を member から admin に書き換え、元の署名のまま送ってみます。

import json
d = json.loads(base64.urlsafe_b64decode(pad(p)))
d["role"] = "admin"
p2 = base64.urlsafe_b64encode(json.dumps(d, separators=(",", ":")).encode()).rstrip(b"=").decode()
jwt.decode(f"{h}.{p2}.{s}", SECRET, algorithms=["HS256"])

jwt.exceptions.InvalidSignatureError: Signature verification failed

中身を1文字でも変えると、署名が合わなくなり、検証に失敗します。秘密鍵を知らない人は、正しい署名を作れません。これが、JWTが改ざんを防げる理由です。

その他の検証結果

alg: none の問題

JWTの仕様には、署名なし（"alg": "none"）という方式もあります。

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJ1Iiwicm9sZSI6ImFkbWluIn0.

最後の署名の部分が空です。もしサーバーが「トークンのヘッダーに書かれた方式を、そのまま信じて検証する」実装になっていると、攻撃者は署名なしで "role":"admin" のトークンを作れてしまいます。

PyJWTで、HS256だけを許可して検証した結果です。

jwt.decode(none_token, SECRET, algorithms=["HS256"])
# jwt.exceptions.InvalidAlgorithmError: The specified alg value is not allowed

検証するときは、許可するアルゴリズムを必ずサーバー側で指定します。現在の主要なライブラリは、PyJWTのように指定を必須にしているものが多いですが、ライブラリの使い方を確認しておくことが大切です。

HS256とRS256の違い

RS256やES256では、検証する側は公開鍵だけを持てばよいため、秘密鍵を配る必要がありません。認証サーバーとAPIサーバーが分かれている構成では、こちらが向いています。

アクセストークンとリフレッシュトークン

JWTは、一度発行すると、有効期限まで取り消しにくいという性質があります。そのため、実務では2種類のトークンを組み合わせるのが一般的です。

アクセストークンの期限を短くすることで、盗まれても使われる時間を短くできます。リフレッシュトークンはサーバー側で管理し、使うたびに新しいものに交換する（ローテーション）と、盗まれたリフレッシュトークンが使われたことを検出しやすくなります。

トークンの保存場所

ブラウザでJWTを使う場合、どこに保存するかは重要な判断です。

一般的には、リフレッシュトークンは HttpOnly のCookie、アクセストークンはメモリに置く構成が、安全性と使いやすさのバランスがよいとされています。どの方法を選んでも、XSSを防ぐこと自体が最も重要です。

ログアウトと失効の考え方

JWTはサーバーに保存しないため、「ログアウトしたら、そのトークンを無効にする」ことが、セッション方式ほど簡単ではありません。

失効リストを使うと、結局サーバー側で状態を持つことになります。「すぐに無効にしたい」要件が強い場合は、セッション方式の方が素直なこともあります。

セッション方式との使い分け

1つのWebアプリで完結するなら、従来のセッション方式で十分なことも多いです。JWTを選ぶのは、複数のサービスで認証を共有したいときなど、JWTの長所が活きる場面に絞ると、設計がシンプルになります。

安全に使うためのチェックリスト

よくある質問

Q. JWTの中身を暗号化することはできますか？ A. できます。JWE（JSON Web Encryption）という仕様を使うと、中身を暗号化できます。ただし実装が複雑になるため、多くの場合は「秘密の情報をそもそも入れない」ことで対応します。

Q. jwt.ioにトークンを貼り付けても大丈夫ですか？ A. jwt.ioはブラウザの中でデコードする仕組みですが、本番環境のトークンを外部のサイトに貼り付けるのは避けた方が安全です。中身の確認は、この記事のようにローカルでデコードできます。

Q. OAuthやOpenID Connectとの関係は？ A. OpenID ConnectのIDトークンはJWTの形式です。OAuthのアクセストークンは、JWTの場合も、ランダムな文字列の場合もあります。JWTはトークンの「形式」で、OAuthやOpenID Connectは認可・認証の「仕組み」と考えると整理しやすくなります。

まとめ

• JWTは、ヘッダー・ペイロード・署名を . でつないだ、改ざんを検出できるトークン
• 中身は誰でも読める。秘密の情報を入れない
• 検証では、許可するアルゴリズムを指定し、有効期限を必ず確認する
• アクセストークンは短い期限にし、リフレッシュトークンと組み合わせる
• 保存場所は、XSS・CSRFのリスクを踏まえて決める
• すぐに無効にしたい要件が強いなら、セッション方式も選択肢に入れる

株式会社RJCでは、安全なWebアプリを作るための知識を、実際に手を動かして確かめながら仲間と学んでいます。こうした知識を共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。