JWT (JSON Web トークン) のマスター: ディープダイブ-jsチュートリアル-php.cn

JSON Web Token (JWT): クロスドメイン認証の一般的なソリューション

この記事では、現在最も人気のあるクロスドメイン認証ソリューションである JSON Web Token (JWT) の原理と使用法を紹介します。

1. クロスドメイン認証の課題

インターネットサービスはユーザー認証と切り離せません。従来のプロセスは次のとおりです:

ユーザーはユーザー名とパスワードをサーバーに送信します。
サーバー認証が成功すると、ユーザーの役割、ログイン時間、その他の関連データが現在のセッションに保存されます。
サーバーはユーザーに session_id を返し、それをユーザーの Cookie に書き込みます。
ユーザーによる後続のリクエストはすべて、Cookie を通じて session_id をサーバーに送り返します。
サーバーは session_id を受信した後、ユーザーを識別するために事前に保存されたデータを探します。

このモデルには拡張性がありません。単一マシン環境は問題ありませんが、サーバークラスターまたはクロスドメインのサービス指向アーキテクチャではセッションデータの共有が必要であり、各サーバーはセッションを読み取ることができます。たとえば、Web サイト A と Web サイト B は同じ会社の関連サービスであり、ユーザーは一方の Web サイトにログインした後、もう一方の Web サイトにアクセスすると自動的にログインできます。 1 つの解決策は、セッションデータを永続化し、それをデータベースまたは他の永続層に書き込み、各サービスがリクエストを受信した後に永続層からデータをリクエストすることです。このソリューションのアーキテクチャは明確ですが、ワークロードが大きく、永続層の障害が単一障害点につながります。もう 1 つのオプションは、サーバーがセッションデータをまったく保存せず、すべてのデータがクライアントに保存され、リクエストごとにサーバーに送り返されるというものです。 JWT はこのアプローチを表しています。

2. JWT の原則

JWT の原理は、サーバーが検証後に JSON オブジェクトを生成し、それをユーザーに返すことです。次に例を示します。

<code class="language-json">{"name": "Alice", "role": "admin", "expiration time": "2024年7月1日0:00"}</code>

ログイン後にコピー

その後、ユーザーがサーバーと通信するときに、この JSON オブジェクトを返す必要があり、サーバーはこのオブジェクトに基づいてユーザーの ID を完全に判断します。ユーザーによるデータの改ざんを防ぐために、サーバーはこのオブジェクトの生成時に署名を追加します (詳細は後述)。サーバーはセッションデータを保存しなくなります。つまり、サーバーはステートレスになり、拡張が容易になります。

3. JWT データ構造

実際の JWT は次のようになります:

Mastering JWT (JSON Web Tokens): A Deep Dive

ドット (.) で 3 つの部分に区切られた長い文字列です。 JWT 内には改行がないことに注意してください。ここでの改行は表示を容易にするためだけです。 JWT の 3 つの部分は次のとおりです:

ヘッダー
ペイロード
署名

1 行は Header.Payload.Signature として表現されます

Mastering JWT (JSON Web Tokens): A Deep Dive

これら 3 つの部分を以下に紹介します。

3.1 ヘッダー

ヘッダー部分は、JWT のメタデータを記述する JSON オブジェクトで、通常は次のようになります。

<code class="language-json">{"alg": "HS256", "typ": "JWT"}</code>

ログイン後にコピー

alg 属性は署名アルゴリズムを表し、デフォルトは HMAC SHA256 (HS256) です。typ 属性はこのトークンのタイプを表し、JWT トークンは一律に JWT として書き込まれます。この JSON オブジェクトは、最終的に Base64URL アルゴリズムを使用して文字列に変換されます (詳細は以下を参照)。

3.2 ペイロード

ペイロード部分も、送信する必要がある実際のデータを保存するために使用される JSON オブジェクトです。 JWT は 7 つの公式オプションフィールドを定義します:

iss (発行者): 発行者
exp (有効期限): 有効期限
サブ (件名): 件名
aud (聴衆): 聴衆
nbf (Not Before): 有効時間
iat (発行時刻)：発行時刻
jti (JWT ID): シリアル番号

公式フィールドに加えて、プライベートフィールドもカスタマイズできます。例:

<code class="language-json">{"name": "Alice", "role": "admin", "expiration time": "2024年7月1日0:00"}</code>

ログイン後にコピー

JWT はデフォルトでは暗号化されておらず、誰でも読み取ることができるため、このセクションには秘密情報を入力しないでください。この JSON オブジェクトも、Base64URL アルゴリズムを使用して文字列に変換する必要があります。

3.3 署名

署名部分は最初の 2 つの部分の署名であり、データの改ざんを防ぐために使用されます。まず、シークレットを指定する必要があります。このシークレットはサーバーのみが知っており、ユーザーに漏洩することはできません。次に、ヘッダーで指定された署名アルゴリズム (デフォルトは HMAC SHA256) を使用して、次の式に従って署名を生成します。

<code class="language-json">{"alg": "HS256", "typ": "JWT"}</code>

ログイン後にコピー

署名が計算された後、ヘッダー、ペイロード、署名の 3 つの部分が 1 つの文字列に結合され、各部分は「ドット」 (.) で区切られ、ユーザーに返されます。

3.4 Base64URL

前述したように、ヘッダーとペイロードのシリアル化アルゴリズムは Base64URL です。このアルゴリズムは基本的に Base64 アルゴリズムと似ていますが、いくつかの小さな違いがあります。 JWT はトークンとして URL に配置されることがあります (api.example.com/?token=xxx など)。Base64 の 3 文字、/ および = は URL 内で特別な意味を持っているため、置き換える必要があります。省略して - に置き換え、/ を _ に置き換えます。これは Base64URL アルゴリズムです。

4.JWTの使い方

クライアントは、サーバーから返された JWT を受信した後、それを Cookie または localStorage に保存できます。クライアントは、サーバーと通信するたびにこの JWT を運ぶ必要があります。これを Cookie に入れて自動的に送信することはできますが、ドメインをまたいで行うことはできません。より良い方法は、HTTP リクエストヘッダーの Authorization フィールドにそれを置くことです:

権限: ベアラー

もう 1 つのアプローチは、ドメインをまたぐときに POST リクエストの本文に JWT を入れることです。

5. JWT のいくつかの特徴

(1) JWT はデフォルトでは暗号化されませんが、暗号化することもできます。元のトークンが生成された後、キーを使用して再度暗号化できます。

(2) JWTが暗号化されていない場合、機密データを書き込むことができません。

(3) JWTは本人確認だけでなく情報交換にも利用できます。 JWT を効果的に使用すると、サーバーがデータベースにクエリを実行する回数を減らすことができます。

(4) JWT の最大の欠点は、サーバーがセッション状態を保存せず、使用中にトークンを取り消したり、トークンの権限を変更したりできないことです。つまり、JWT が発行されると、サーバーが追加のロジックをデプロイしない限り、有効期限が切れるまで有効なままになります。

(5) JWT自体に認証情報が含まれており、一度漏洩すると誰でもトークンの全ての権限を取得できてしまいます。盗難を減らすために、JWT の有効期間は比較的短く設定する必要があります。より重要な権限については、ユーザーが使用するときに再度認証する必要があります。

(6) 盗難を減らすために、JWT は HTTP プロトコルを使用して平文で送信されるべきではなく、HTTPS プロトコルを使用して送信される必要があります。

Leapcell: 最高のサーバーレス Web ホスティングプラットフォーム

Mastering JWT (JSON Web Tokens): A Deep Dive