- JWTとは、JSON形式の情報を署名付きでやり取りするための標準トークンのことだ。
- ログインのたびにサーバーへ問い合わせなくても、トークンそのものを見れば本人だと確認できる。だからAPI保護やSSOの実装で重宝される。
- これを押さえておけば、開発者が口にするJWTトークンという言葉に、もう身構えずに済むようになる。
この4コマは、認証システムを設計する現場で実際に起こりうる判断を、イベントのリストバンドに置き換えた事例です。コマ①のように利用者ごとにサーバーへ毎回問い合わせる方式は、アクセスが増えるほど確認の待ち行列が伸びていきます。トークン自体に情報と署名を持たせることで、この問い合わせを減らせる点がJWT導入の実務的な狙いです。
コマ③で偽造バンドが弾かれる場面は、署名検証のロジックそのものを表しています。改ざんされたトークンは署名が一致しないため、受信側は即座に拒否できます。ただし署名は改ざん検知の仕組みであって、中身を隠す暗号化ではありません。コマ④の助言が示す通り、ペイロードはBase64Urlでエンコードされているだけなので、デコードすれば誰でも読めてしまいます。
そのため、パスワードやクレジットカード番号のような機密情報をペイロードへ入れる設計は避けるべきでしょう。有効期限を短く設定し、不要になったトークンの扱いを決めておくことが、実運用でのリスクを下げる鍵になります。便利さと安全性のバランスを取る判断こそ、設計者に求められる視点と言えます。
JWTはどんな仕組みで本人確認をするのか?
この事実に驚く方は少なくありませんが、JWTはそもそも中身を隠すための道具ではなく、情報が途中で改ざんされていないことを保証するための道具です。1本のトークンはヘッダー・ペイロード・署名という3つの部品をピリオドで区切って構成され、xxxxx.yyyyy.zzzzz のような文字列になります。ペイロードに入れる情報はクレームと呼ばれ、2015年5月に公開されたRFC 7519では、発行者を表すissや有効期限を表すexpなど7種類の登録済みクレームが定義されています。
3つの部品のうち、本人確認の要になるのが末尾の署名です。トークンを受け取ったサーバーは、自分だけが知る鍵を使って署名を計算し直し、送られてきた署名と一致するかどうかを照合します。もし途中でペイロードが1文字でも書き換えられていれば署名は合わなくなり、そのトークンは弾かれます。この仕組みがあるおかげで、サーバーは利用者ごとの情報を抱え込まなくても、トークンを見るだけで正当性を判断できるというわけです。
JWTのよくある誤解
署名されているから中身も暗号化されている
署名と暗号化は役割がまったく違います。標準的なJWTのペイロードはBase64Urlでエンコードされているだけで、暗号化はされていません。オンラインのデコーダに貼り付ければ中身のクレームは丸見えになるため、パスワードやカード番号などの秘密情報を入れてはいけません。署名はあくまで、その内容が改ざんされていないことを保証するための仕組みです。
JWTを使えばログアウトも簡単にできる
これは意外と落とし穴になりやすいポイントです。JWTはサーバーに状態を持たせないステートレスな方式のため、一度発行したトークンを有効期限の前に取り消すのは簡単ではありません。ログアウトを厳密に実装したい場合は、有効期限を短くしたり、無効化したトークンの一覧を別途管理したりといった工夫が必要になります。
JWTとOAuthは同じもの
名前がセットで登場しがちなため混同されますが、両者は層が異なります。OAuthはアクセス権限を安全に受け渡すための枠組み(プロトコル)であり、JWTはそこでやり取りされるトークンの中身のフォーマットです。OAuth 2.0のアクセストークンとしてJWTが採用されることは多いものの、両者はイコールではありません。
会話での使われ方

認証はセッション方式ではなくJWTで組みます。サーバー側で状態を持たないので、アクセスが急増しても各サーバーが独立してトークンを検証できます。
ベンダーのエンジニアが、クライアント企業の情シス担当者に対して、新システムの認証設計の方針を説明している商談の場面です。

そのJWT、payloadにメアド生で入れてるけど、デコードすれば丸見えだよ。
新人が実装したAPIのコードレビューで、先輩エンジニアがSlack上で機密情報の扱いをやんわり指摘した場面です。

ログアウトしてもトークンって有効なままなの?
社内の技術勉強会が終わったあと、参加者どうしがJWTの無効化のしにくさについて、ざっくばらんに質問し合っている雑談の場面です。
JWTの歴史
JWTがどのような流れで標準化され、現在の定番技術になったのかを振り返ると、なぜこれほど広く使われているのかが見えてきます。
| 年 | 出来事 |
|---|---|
| 2010年代前半 | スマホアプリやWeb APIの普及により、サーバーに状態を持たせないステートレスな認証・認可の需要が高まる。 |
| 2015年5月 | JSON Web TokenがIETFのRFC 7519として標準化され、iss・exp・subなど登録済みクレームの仕様が定義される。 |
| 現在 | OAuth 2.0のアクセストークンやSSO、API保護の実装で、定番のトークン形式として広く使われている。 |
JWTとセッションの違い
JWTとセッションは、どちらもログイン状態を保つための仕組みですが、情報をどこに置くかという設計思想が正反対のため混同されがちです。以下の表で要点を整理します。
| 比較観点 | JWT | セッション |
|---|---|---|
| 情報の保存場所 | トークン自体に情報を格納し、主にクライアント側が保持する | 情報はサーバー側に保存し、クライアントはIDだけを持つ |
| サーバーの状態管理 | 状態を持たないステートレスな方式 | 状態を持つステートフルな方式 |
| 複数サーバーへの拡張 | 各サーバーが署名を検証でき、拡張しやすい | サーバー間でセッション情報を共有する仕組みが必要 |
| ログアウト・無効化 | 有効期限まで取り消しにくく、工夫が必要 | サーバー側で該当情報を消せば即座に無効化できる |
【まとめ】JWTの3つのポイント
- 正体は改ざん防止つきの通行証:JSON形式の情報を署名付きで運ぶ、コンパクトな標準トークンです。
- 問い合わせを減らして身軽に検証:サーバーが状態を持たずに本人確認でき、API保護やSSOの実装を軽くできます。
- 中身は隠れないと心得る:ペイロードは誰でも読めるため、秘密情報を入れず有効期限を短くする運用が安全につながります。
よくある質問
-
QJWTの読み方は何ですか?
-
A
ジョット、またはジェイダブリューティーと読みます。JSON Web Tokenの略で、開発の会話では単にJWTトークンと呼ばれることも多いです。どちらの読み方でも通じるので、社内で使われている方に合わせれば問題ありません。
-
QJWTの中身は誰でも見られてしまうのですか?
-
A
はい、標準的なJWTのペイロードはトークンを入手した人ならデコードして読めてしまいます。暗号化ではなくBase64Urlというエンコードがかかっているだけだからです。そのため、パスワードや個人情報などの秘密にすべき値をペイロードに入れない設計が鉄則になります。
-
QJWTは何のために使われるのですか?
-
A
もっとも多い用途は、ログイン後の認可、つまりどのユーザーがどの機能を使ってよいかを確認する場面です。一度ログインすれば複数サービスを使い回せるSSOや、外部からのAPI呼び出しを保護する用途でも活躍します。当事者間で改ざんされていない情報を安全に受け渡す手段としても使われます。
-
QJWTとセッションとの違いは何ですか?
-
A
大きな違いは、ログイン情報をどこに置くかにあります。JWTは情報そのものをトークンに詰めてクライアントが持ち歩くステートレス方式で、サーバーは状態を保持しません。一方セッションは情報をサーバー側に保存し、クライアントはIDだけを持つステートフル方式です。拡張のしやすさではJWT、ログアウトの即時性ではセッションに分があります。
JWTと一緒に知っておきたい用語
| 用語 | JWTとの関連 |
|---|---|
| OAuth | アクセス権限を委譲するOAuth 2.0で、JWTがアクセストークンの形式としてよく採用される |
| シングルサインオン(SSO) | 一度のログインで複数サービスを使うSSOの実装に、JWTが活用される |
| トークン | JWTはトークンの一種で、その中身を標準化した具体的なフォーマット |
| 多要素認証(MFA) | 本人確認を強化するMFA。認証を通過した後の状態管理でJWTが使われることがある |
| セッション | サーバー側で状態を管理する認証方式で、ステートレスなJWTと対比される代表格 |
【出典】参考URL
https://datatracker.ietf.org/doc/html/rfc7519 :JWTの標準規格RFC 7519の定義、登録済みクレーム、2015年5月公開という根拠
https://jwt.io/introduction :ヘッダー・ペイロード・署名の3構造、Base64Urlエンコード、認可・情報交換という用途、署名アルゴリズムの根拠
https://e-words.jp/w/JWT.html :読み方、IETFによる標準化、署名による改ざん検知・なりすまし防止という日本語の定義の根拠

コメント