JWT認証を体系的に理解する

はじめに

職場でJWT認証の仕組みについて話題になり、改めて調べてみました。
未来の後輩のために自分の理解をまとめておきます。

「JWT認証」とは？

JWT(Json Web Token)というトークンを使った認証方法です。

JWT認証を理解するために、以下の順番で紐解いていきます。

1. 認証と認可の違い
2. トークンを使った認証とは
3. JWTとは何か
4. JWT認証の流れ

1. 認証と認可の違い

突然ですが、認証と認可の違いをご存知でしょうか。
認証と認可の違いを理解できれば、認証の基本概念は自ずと理解できます。

認証（Authentication）

認証とは、通信の相手が誰（何）であるかを確認することです。
マイナンバーカードでの本人確認のようなイメージです。

認証の３要素

認証を行うための要素は３つです。

1. WHAT YOU ARE (inherence factor)
   声、指紋など、その人だけが持っているものを提示することによって認証します。
   
   
2. WHAT YOU HAVE (possession factor)
   身分証、携帯電話等、その人だけが持っているものを提示することによって認証をします。
   
   
3. WHAT YOU KNOW (knowledge factor)
   パスワード、秘密の質問等、その人だけが知っていることを提示して認証をします。

一般に３つのうちどれかを満たせば認証は完了します。

認可（Authorization）

認可とは、特定の条件を満たした上で、リソースアクセスの権限を与えることです。
「家の鍵を渡す」イメージです。
鍵があれば家に入れます。「誰であるか」は関係ありません。

まとめ　「1. 認証と認可の違い」

• 認証とは、相手の身元を確認すること
• 認可とは、権限を与えること

2.トークンを使った認証とは

トークンを使った認証 = トークン認証です。
トークン認証は、セッション認証と対比すると理解しやすいです。

ざっくり言うと、セッション認証はサーバー側主体の認証方法であり、トークン認証はブラウザ側主体の認証方法です。

画像引用元：https://zenn.dev/kingdom0927/articles/a9ff114b1ee57f


どちらの認証でも、ログインに成功したら、サーバーがセッションIDまたはアクセストークンを発行します。セッションIDまたはアクセストークンはブラウザに保存され、リクエストの度にサーバへ送られることも共通しています。

違いは、リクエストを受け取った際の検証方法です。

セッション認証では、 送られてきたセッションIDとサーバにあるユーザ情報が一致しているかを確認します。サーバがユーザ情報を保持するため、負荷がかかります。

トークン認証では、 アクセストークンの中身を解読して改ざんなどの問題がないかを確認します。サーバはユーザ情報を保持しません。

まとめ　「2.トークンを使った認証とは」

トークン認証では、サーバがユーザ情報を保持しない

3. JWT(Json Web Token)とは何か

ざっくり言うと、「JSONデータをコンパクトに表現した文字列」です。
JWTは長い文字列ですが、「.」（ドット）で３つに区切られています。

ヘッダには、署名に使うアルゴリズムなどのメタ情報、
ペイロードには、有効期限などのメイン情報があり、
それぞれBASE64URLエンコードを行い、JSONデータをコンパクトに変換します。

署名は、ヘッダ+ペイロードを暗号化したものです。
ヘッダ+ペイロードを、ヘッダで指定したアルゴリズムと秘密鍵で署名します。
その署名をさらにBASE64URLエンコードします。

画像引用元：https://qiita.com/asagohan2301/items/cef8bcb969fef9064a5c#3-jwt%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9

JWTの検証では、まず署名部分をBASE64URLデコードし秘密鍵（または公開鍵）で復号化します。
改ざん等がなければ、ヘッダ＋ペイロードのハッシュ値となるはずなので、
ヘッダ＋ペイロードをハッシュ化した値と一致するかどうかを検証します。

まとめ　「3. JWT(Json Web Token)とは何か」

• JSONデータをコンパクトに表現した文字列
• ヘッダ（メタ情報）＋ ペイロード(メイン情報）＋ 署名（ヘッダ＋ペイロードの暗号化）で構成される

4. JWT認証の流れ

アプリ側で認証を行う場合と、シングルサインオンのようにGoogleなどのIDプロバイダが認証を行う場合の２パターンに分けて説明します。

アプリ側でログインを行う場合

• 1つの秘密鍵で署名の作成と検証どちらも行います(共通鍵方式)
• アプリ側が秘密鍵を持っています
• アプリ側がJWTの発行と検証を両方行います

GoogleなどのIDプロバイダがログインを行う場合

• 秘密鍵で署名の作成、公開鍵で署名の検証を行います（公開鍵方式）
• IDプロバイダだけが秘密鍵を持っています
• IDプロバイダは公開鍵を外部に公開します
• IDプロバイダがJWTの発行を行います
• アプリ側がJWTの検証を行います

まとめ　「4. JWT認証の流れ」

• アプリ側でログインを行う場合、共通の秘密鍵でJWTの発行と検証を行う
• IDプロバイダがログインを行う場合、IDプロバイダの秘密鍵でJWTを発行しアプリ側がIDプロバイダの公開鍵を使ってJWTの検証を行う

まとめ

JWT認証を理解するにあたり、認証と認可の違いやセッションやCookieについても深掘りできました。
これで未来の後輩から質問されても大丈夫かも？。

参考文献