JWT 概要説明

現在勤務している、開発会社でJWTを扱う機会があり色々と調べたので。まとめたいと思います。

想定読者はCookieとSessionの前提知識が既にある人です。

JWTはなんの略？

JWTは"Jason Web Token"の略になります。

JWTの発音は？

最初はジェーダブルティーとドヤ顔で言っていたのですが正式には"Jot"と発音します。
日本語では「ジョット」と発音します。

   The suggested pronunciation of JWT is the same as the English word
   "jot".

JWTとはそもそも何？

JWTとはJSONデータ構造で表現したトークンで、認証サービスなどに利用される。

JWTの認証フロー

画像参考サイト

1. 認証サーバへのサインイン

まずユーザーはユーザー名、パスワードなどを入力し認証サーバーへサインインします。

2.　認証サーバーからユーザへJWTを渡す

認証が完了すれば。認証サーバーで作成されたJWTがユーザーに渡されます。

JWT情報の保存先はLocalStorageかCookieを選択出来ます。

3. APIを叩く時にJWTも一緒に渡す

ユーザーがAPIコールする時と同時にJWTをアプリケーションサーバーに渡します。

（JWTはHTTPリクエストのAuthorizationヘッダーのBearerスキームに設定します）

4. JWTの内容を確認し、問題なければAPIコールを返す

アプリケーションサーバーは受け取ったJWTが内容改善されていないことを確認します。

CookieとSessionと何が違うの？

Cookie & sessionもJWTも同じ認証システムですが、Cookieはサーバー側でsession情報を保存しており、リクエストの度にひもづくサーバー側のsessionデータを参照しています。

一方、JWTはクライアント側で認証に成功したという情報をもつだけでサーバー側で何か情報を持ちません。

ここが大きな違いだと思います。

JWTの構成

JWTは①header ②payload ③signatureの３つのパートで構成されています。

header

headerでは署名検証を行うための情報を確認するためのパートです。

サンプル例

{
  "alg": "HS256",
  "type": "JWT"
}

alg -> 署名アルゴリズムを示しています。このトークンにはHS256が利用されていることが理解できます。

type -> トークンタイプを表します。”JWT”の文字列からJwtトークンタイプであることが理解できます。

payload

やりとりに必要な情報が格納されているパートです。API連携に必要な情報がここのパート見れば内容把握することができます。

サンプル例

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

sub -> JWT発行社から発行された、ユーザー識別子
name -> ユーザの名前
iat -> 発行日時

ここで注意なのはクレームデータについては、予約済のクレーム名が存在しています。
これらはすでに役割が定義されております。上記の例でいうとsubとiatが予約済にクレーム名になります。

予約語例

signature

サンプル例

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),

your-256-bit-secret

) secret base64 encoded

署名情報は内容改ざんのチェックにしか使われないので、開発者（プログラマー）は特に何も意識せずに実装することができます。

JWTのメリット

上記でも述べたようにCookie & sessionを利用したユーザー認証システムだと、サーバー側でユーザーの認証情報を管理する必要があります。よって、ユーザー数が増えてきたりすると、ロードバランサーで分散管理するなどの処置が必要で管理が大変です。

一方JWTは送られてきたトークンを検証するだけなので、Cookie & sessionと違って並行分散処理が簡単でサービスをスケールしやすいというメリットがあります。

JWTのデメリット

JWTの中身はBase64でエンコードされただけなので、デコードすると簡単に中身を確認することができます。
つまり、個人情報などの流失した時に問題になりそうな情報を含めることは出来ません。
（厳密にいうと、含めることはできるがオススメはしない）

１から学ぶJWT