仕事で初めて JWT に触れる機会があったので、まとめる。
# JWT(Json Web Token)とは
主に認証が必要な REST APIや、シングルサインオンを実装する際にアクセストークンとして利用される。
トークンの中に任意の情報（Claim）を格納できる。（認証したユーザの ID やトークンの有効期限など）
トークン生成時に署名を付けることができ、それにより正規に生成されたトークンかどうかを検証することが可能。⇒改ざん検知できる。
# 利用例
ログインしてからプライベート API を実行するシンプルなケース。
# JWT を触ってみる
以下のサイトの「Debugger」で、JWT の生成/検証を試せる。
# ①JWT を生成してみる
以下の手順で JWT を生成することができる。
# ②JWT を検証してみる
不正な JWT を生成し、検証する。
# 構造
JWT は HEADER, PAYLOAD, SIGNATURE の 3 つの要素で構成され、「.(ピリオド)」で区切られている。
- HEADER
署名生成のアルゴリズムを格納する。
{ "alg" : "HS256", "typ" : "JWT" }
- PAYLOAD
ログインしているユーザの ID や権限など、サーバサイドに受け渡したい情報を格納する。
PAYLOAD には好きな情報を入れられるが、RFC 標準で定義されている項目もある。
標準で定義されている PAYLOAD 項目(一部)
項目名 用途 iss 発行者の識別子 sub ユーザ識別子。ログインしたユーザの ID などを入れる。 exp トークンの有効期限 iat トークン発行日時 ※PAYLOAD は暗号化されておらず、JWT を盗聴されると簡単に中身を確認可能なのでパスワード等の情報は入れないこと。
- VERIFY SIGNATURE
- 署名情報を格納する。
# メリット
# ステートレス
サーバ側は送られてきた JWT を検証するだけでよいため、セッション管理する必要がない。
ロードバランサによる分散環境や、他システムとのシングルサインオンの際に、セッション情報を同期する必要がなく便利。
# DB アクセスの削減
PAYLOAD にユーザの権限情報などを乗せておけば、DB に問い合わせるコストを削減できる。
# デメリット
# セキュリティ
一度発行してしまった JWT はサーバ側で制御ができない。盗聴された JWT を無効化することができない。
# 通信コスト
リクエストのたびに JWT を付加するため、PAYLOAD に情報を乗せすぎると通信コストがかさむ。
# その他ポイント
# クライアント側での JWT の扱い方
発行された JWT は、基本的には LocalStorage 等に保持し、リクエストのたびにインターセプタで Authorization ヘッダに付加する。
Authorization: Bearer [JWT文字列]