JWT (JSON Web Token)は、認証・認可の情報をシステム間で安全にやり取りするための標準的な手法となります。
RFC 7519で定義されていて、そこの概要は以下の通りです。
JSON Web Token（JWT）は、2つのパーティ間で転送されるクレームを表す、コンパクトでURLセーフな手段です。JWTのクレームは、JSON Web Signature（JWS）構造のペイロードとして、またはJSON Web Encryption（JWE）構造のプレーンテキストとして使用されるJSONオブジェクトとしてエンコードされ、クレームにデジタル署名したり、メッセージ認証コード（MAC）で整合性を保護したり、暗号化したりすることを可能にします。
読み方
JWTは一般的に「ジョット(jot)」と読まれます。
RFC 7519で明確に定義されています。
RFC 7519: JSON Web Token (JWT)JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
IETF Datatracker
一言でいうと
一言でいうと、「改ざんを防ぐ仕組みがついた、デジタルな証明書」のようなものです。
テーマパークの「入場・再入場のスタンプ」で例えると、
- 入場する際に、チケットを見せてスタンプを押してもらう。（JWT発行）
- アトラクションに乗るときや再入場するときに、スタンプを見せて確認してもらう。（JWT提示・検証）
- 自分でスタンプを消す（JWT破棄）か、時間が経ってスタンプが消える。（JWTの有効期限切れ） のような流れでJWTは利用されるイメージです。
JWTの仕組み
JWTは下記のような形式で表現されます。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOmZhbHNlLCJpYXQiOjE1MTYyMzkwMjJ9.HO95GJZFIR0Qoj2cor4jVbJNu_-v15ip-Wl1z1FQ4o4
長い文字列が並んでいますが、内容としてはシンプルで、ドットで区切られた3つの部分に分かれています。
- ヘッダー
- ペイロード
- 署名
つまりヘッダー.ペイロード.署名の形式になっているということです。
ヘッダー・ペイロードはBase64UrlエンコードされたJSONオブジェクトで、署名はその内容を元に暗号学的ハッシュ関数や公開鍵暗号を使って作成されたものになります。
Base64Urlエンコードなので、ヘッダー・ペイロードはデコードすることが可能です。 なので、ヘッダーやペイロードに個人情報や機密情報を含める場合は注意が必要です。（後述するJWEの利用で技術的に対応は可能です）
例えば、上記のJWTをデコードすると以下のようなJSONオブジェクトが得られます。
ヘッダー
{
"alg": "HS256",
"typ": "JWT"
}algは必須で、署名のアルゴリズムを指定します。 HS256(共通鍵)、RS256(公開鍵)などがあります。 HS256は共通の秘密鍵を使って署名を行うアルゴリズムで、単一のサーバーで完結するWebアプリケーションなどでよく使われます。 RS256は公開鍵と秘密鍵のペアを使って署名を行うアルゴリズムで、複数のサーバー間で署名の検証を行う場合などに適しています。（マイクロサービス構成などでよく使われます）
typは任意で、トークンの種類を指定します。通常は”JWT”が設定されます。 “JWE”は暗号化されたJWTを表します。どうしてもトークンの内容を第三者に知られたくない場合や厳格なセキュリティ要件がある場合に使用されます。
ペイロード
{
"sub": "1234567890",
"name": "John Doe",
"admin": false,
"iat": 1516239022
}RFC 7519で定義された規格があります。参照: RFC 7519
上記の例でいうと”sub”,“iat”がRFC 7519で定義された登録済みクレームになり、“name”や”admin”は独自に定義されたクレームになります。
署名
署名はBase64Urlエンコードされたヘッダー.ペイロードを秘密鍵でハッシュ化したものです。これにより、JWTの内容が改ざんされていないことを検証することができます。
例えば、先ほどのペイロードのadminをfalseからtrueに変更すると、ヘッダー.ペイロードまではBase64Urlエンコードで生成が可能ですが、署名は秘密鍵を使って生成されるため、改ざんが検知されるということです。
便利なツール
JWTのデバッグには、jwt.io(Auth0/Okta)が便利です。ここでは、JWTのヘッダー、ペイロード、署名をそれぞれ確認したり、署名の検証を行ったりすることができます。
シーケンス図
ここまでは文字での説明ばかりになってしまったため、シーケンス図でJWTのやり取りの流れを視覚的に示します。
sequenceDiagram participant User participant Client participant Server participant Database User->>Client: ログイン情報の入力 Client->>Server: ログイン情報の送信 Server->>Database: ユーザー情報の照会 Database-->>Server: ユーザー情報の返却 Server-->>Client: JWT発行 Client->>Server: JWTを提示（アクセス要求） Server-->>Client: JWT検証後、アクセス許可 Client->>User: アクセス結果の表示 User->>Client: 再度アクセス要求（JWT提示） Client->>Server: JWTを提示（アクセス要求） Server-->>Client: JWT検証後、アクセス許可 Client->>User: アクセス結果の表示
JWTのメリット
この流れを踏まえると、JWTには以下のようなメリットがあります。
- サーバー側でセッション管理を行う必要がなくなる セッション方式だと、サーバー側に「誰がログイン中か」のような情報を保存しておく必要がありました。JWTであればトークン自体にユーザー情報や権限情報を含めることができるので、サーバー側でのセッション管理が不要になります。
- データベースへのアクセス回数が減るため、負荷が軽減される 初めにログイン→JWT発行でデータベースアクセスを行うのみで、以降のアクセスでは認証・認可はクライアントとサーバー間でのJWTのやり取りだけで完結します。
- サーバーの拡張性が向上する Redisなどのセッションストアに依存する必要がないため、サーバーの水平スケーリングが容易になる。
JWTのデメリット
メリットだけではなく、いくつかのデメリットもあります。
- 途中で無効化することが難しい JWTは一度発行されると有効期限まで無効化できないため、ユーザーのログアウトや権限変更の反映を即時行いたいときに困ることがあります。ブラックリスト方式で対応も可能ですが、DBやRedisなどのストアを用意する必要があり、メリットをなくしてしまうことがあります。
- トークンサイズの増加による通信コストの増大 セッションIDと比較すると、JWTはペイロードを含むためサイズが大きくなりがちで、HTTPヘッダーに含めて送信する際の通信コストが増加します。
- クライアント側でJWTを保持するため、適切な保護がされていないと盗まれるリスクがある。 例えば、ブラウザのローカルストレージに保存している場合、XSS攻撃によってトークンが盗まれる可能性があります。セキュリティを確保するためには、保存場所や送信方法に注意が必要です。
まとめ
JWTはサーバー側でのセッション管理を不要にし、データベースアクセスの負荷を軽減し、サーバーの拡張性を向上させるなどのメリットがあります。その一方で、途中で無効化することが難しい、トークンサイズが大きくなる、クライアント側での保護が必要などのデメリットも存在します。
JWTを利用する際は、これらのメリットとデメリットを理解した上で、システム要件にあった設計を選ぶのが大事になります。
理解度チェック（AI生成）
以下の4択問題で、JWTの理解度をチェックしてみましょう。答えは折りたたまれているので、クリックして確認してください。
Q1. JWTは一般的にどのように発音されるか？
- ジェイダブリューティー
- ジョット
- ジュワット
- ジェイウィット
答えを見る
正解: 2. ジョット RFC 7519で、JWTは英単語の”jot”と同じように発音することが明記されています。
Q2. JWTの構造として正しいものはどれか？
- ヘッダー.クレーム.シークレット
- トークン.ペイロード.ハッシュ
- ヘッダー.ペイロード.署名
- ヘッダー.署名.ペイロード
答えを見る
正解: 3. ヘッダー.ペイロード.署名 JWTはドットで区切られた「ヘッダー」「ペイロード」「署名」の3つの部分から構成されます。
Q3. HS256とRS256の違いに関する説明として正しいものはどれか？
- HS256は共通鍵暗号方式、RS256は公開鍵暗号方式である
- HS256は公開鍵暗号方式、RS256は共通鍵暗号方式である
- どちらも同じ鍵の仕組みで、呼び方が違うだけである
- HS256とRS256はどちらも署名ではなく暗号化のためのアルゴリズムである
答えを見る
正解: 1. HS256は共通鍵暗号方式、RS256は公開鍵暗号方式である HS256は単一サーバーで完結するアプリケーションでよく使われ、RS256は複数サーバー間で署名検証を行うマイクロサービス構成などに適しています。
Q4. JWTのデメリットとして誤っているものはどれか？
- 一度発行すると有効期限まで無効化するのが難しい
- セッションIDに比べてトークンサイズが大きくなりがちである
- サーバー側でのセッション管理が必須になり、スケーラビリティが低下する
- クライアント側の保存方法によっては、XSS攻撃でトークンが盗まれるリスクがある
答えを見る
正解: 3 JWTはトークン自体に情報を含められるため、むしろサーバー側でのセッション管理が不要になる点がメリットです。そのため3は誤った記述です。