JWT（JSON Web Token、ジョット）は2015年にRFC 7519として標準化された、クライアント・サーバ間でクレーム（claim、主張）をやり取りするためのトークン形式です。「ヘッダ.ペイロード.署名」の3部構成のBase64Url文字列で、URLにも安全に乗る軽さと、署名検証で改ざんを検出できる仕組みから、API認証・SSO・OpenID Connectなど広く使われています。
この記事の目次
- JWTの構造
- JWTの典型的な使われ方
- JWTの落とし穴
- JWTを使うべき場面・避ける場面
- まとめ
JWTの構造
JWTは「ヘッダ.ペイロード.署名」の3つをドット連結した文字列です。例: eyJhbGc...eyJzdWI...XyZ の形をしており、それぞれBase64UrlでエンコードされたヘッダJSON・ペイロードJSON・署名バイト列です。
ヘッダにはアルゴリズム（HS256, RS256など）、ペイロードには sub（誰）・exp（有効期限）・iat（発行時刻）等のクレームが入ります。署名は共有秘密鍵か公開鍵暗号で作られ、受信側が同じ鍵で検証することで「改ざんされていない」「正当な発行元から来た」ことを確認できます。
JWTの典型的な使われ方
もっとも多い用途は「ステートレスなAPI認証」です。ユーザーがログインしたら、サーバはJWTを発行してクライアントに返します。以降のAPI呼び出しではJWTを Authorization: Bearer ヘッダに付けて送り、サーバは署名を検証するだけで本人確認ができます。
サーバ側でセッション情報を持たなくて済むため、複数台のサーバへの水平スケールが容易になります。ただし「サーバで管理しない」ゆえにログアウトや即時失効が難しいという欠点もあるため、短い有効期限とリフレッシュトークンの併用が定石です。
JWTの落とし穴
JWTには有名な脆弱性パターンがいくつもあります。代表が「alg=none」攻撃で、ヘッダに alg: none と書いて署名なしで通そうとする悪用。ライブラリ次第ではうっかり受け入れてしまうので、許可するアルゴリズムを明示的に絞る必要があります。
ペイロードはBase64Urlで「エンコード」されているだけで「暗号化」ではないため、誰でも読めます。パスワード・クレジットカード番号等の機密はJWTに入れない、というのは基本のキ。暗号化が必要ならJWE（JSON Web Encryption）の出番ですが、用途は限定的です。
JWTを使うべき場面・避ける場面
JWTは万能ではなく、向き不向きがあります。ステートレスAPIや短命の認可情報運搬には強力ですが、「ログアウトを瞬時に反映したい」「Eコマースのカート状態を持たせたい」など長期かつ可変な状態の管理にはセッションIDの方が向きます。
「JWTは銀の弾丸ではない」というのは認証界隈の有名な格言。セキュリティ要件と運用要件を整理し、本当にステートレスにするメリットが上回るかを吟味して採用するのが正攻法です。
まとめ
JWTは現代のWeb認証・認可の流通言語として定着しました。仕組みは見た目より単純ですが、運用面の落とし穴は多いので、ライブラリ任せにせず構造と限界を理解して使うのが重要です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント