始めに
本記事は、本家JSON Web Tokens Introductionの和訳要約版です。その為、詳細にはまとめていない点はご了承ください。
JWTとは何か
- JSON Web Tokens(JWT)は
- RFC7519で定義されたオープンな仕様である。
- 情報を安全かつコンパクトに格納してJSONオブジェクトとして送信することができる
いつJSON Web Tokensを利用すべきか
認証
ユーザーがログインしたら、各リクエスト毎にJWTを要求し、トークンを利用することで、サービス、リソースにアクセスすることが許可される。異なるドメイン間でも使用できるため、今日では幅広く利用されている機能である。
情報交換
JWTは、当事者間で安全に情報交換が出来る方法である。JWTは、ヘッダーとペイロードを利用して署名が追加され、改ざんされていないか認証することができる。
JSON Web Tokensの構造
SON Web Tokens はドットで区切られた以下の３つの部品から成る。
- ヘッダー
- ペイロード
- 署名
それを結合して、 このようにxxxxx.yyyyy.zzzzz なっている。
各部分毎に説明する。
ヘッダー
ヘッダーは主に２つの部品からなる。
- typ: トークンの種別。
- alg:HMAC SHA256 や RSAなどの暗号化に使用したアルゴリズム
{
"alg": "HS256",
"typ": "JWT"
}
これは Base64Url でエンコードされ、JWTの最初の部分となる。
ペイロード
トークンの２番目の部分であるペイロードでは、メタデータなどの情報のクレームを含むことができる。クレームには、予約済みクレーム、公開クレーム、プライベートクレームの３つがある。
予約済みクレーム
予約済みのクレームで、情報交換時に便利な機能を提供する。
詳しくは後日。
公開クレーム
自由に定義できるが、名前が衝突しないように注意が必要。
プライベートクレーム
情報交換する際に当事者間の承諾のもとに作成するカスタムクレーム。
ペイロードの例
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
このペイロードも Base64Url でエンコードされ、JSON Web Tokenの２番目の部分となる。
署名
HMACSHA256を利用した署名の作り方は以下となる。この署名は、送信されてきたJWTが改ざんされていないかの認証用に使用される。またこの文字列はJWTの３番目の部分となる。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
JSON Web Tokensはどのようにして利用するのか？
ユーザー認証時にログインに成功したら、JSON Web Tokensを返し、セッションなどサーバーを利用せず、各デザイのローカル内（local storageやクッキーなど）に保存する。
保護されたリソースにアクセスしたい場合、ユーザーはAuthorizationヘッダーに、以下のようなBearerスキーマを送信する。
Authorization: Bearer <token>
これにより、サーバーに何も保存せずステートレスにAPIとやり取りが出来る。また異なるドメイン間でも通信ができ、CORSの心配もない。