JSON Web トークン (JWT) とは何ですか? API がそれらを使用する理由

JSON Web Tokens (JWT)標準では、検証可能なデータ転送のためのコンパクトな方法について説明しています。各トークンには、発行者がメッセージの完全性を検証できるようにする署名が含まれています。

この記事では、JWT フレームワークに含まれるものと、独自のカスタム トークンを作成する方法について説明します。JWT はシンプルで自己完結型であるため、API を保護し、ユーザー セッションを認証するための一般的な方法です。

JWT の仕組み

API で最も一般的なタスクの 1 つは、ユーザーが本人であることを確認することです。認証は通常、クライアントがサーバーに送信するリクエストに API キーを含めるときに行われます。キーには、ユーザーを識別する埋め込み情報が含まれています。これにはまだ 1 つの大きな疑問が残っています。そもそもサーバーがキーを発行したことをどのように確認できるのでしょうか?

JWT は、シークレットを使用して各トークンに署名することで、この問題を便利に解決します。サーバーは、プライベート シークレットを使用して送信された署名を再計算することで、トークンの有効性を検証できます。干渉があると、チェックが失敗します。

JWT 形式

JWT は、次の 3 つの個別のコンポーネントで構成されています。

• ヘッダー – 使用される署名アルゴリズムなど、トークン自体に関するメタデータが含まれます。
• ペイロード – トークンのペイロードは、システムに関連する任意のデータにすることができます。これには、ユーザー ID と、ユーザーが操作できる機能のリストが含まれる場合があります。
• 署名 – 署名により、将来のトークンの整合性を検証できます。これは、サーバーだけが知っている秘密の値を使用してヘッダーとペイロードに署名することによって作成されます。

これら 3 つのコンポーネントをドットで組み合わせて JWT を取得します。

header.payload.signature

各部分は Base-64 を使用してエンコードされます。完全なトークンは、プログラミング環境で簡単に使用でき、HTTP 要求で送信できるテキストの文字列です。

JWT を作成する

JWT を作成する手順は、すべてのプログラミング言語で実装できます。この例では PHP を使用していますが、プロセスは独自のシステムでも同様です。

ヘッダーの作成から始めます。これには通常、次の 2 つのフィールドが含まれalgますtyp。

• alg– 署名の作成に使用されるハッシュ アルゴリズム。これは通常、HMAC SHA256 ( HS256) です。
• typ– 生成されたトークンのタイプ。である必要がありますJWT。

ヘッダーを定義する JSON は次のとおりです。

JSON ヘッダーは、次のように Base64 でエンコードする必要があります。

次に、トークン ペイロードを別の JSON オブジェクトとして定義します。アプリケーションによって異なります。この例では、認証されたユーザーのアカウントに関する情報と、トークン自体に関する情報が提供されます。exp、iatおよびnbfは、時間に発行され、(初期) 時間の前に無効化されるトークンの有効期限を指定するために規則によって使用されるフィールドです。ペイロードも Base64 でエンコードする必要があります。

署名を作成するだけです。これを作成するには、まずヘッダーとペイロードを 1 つの文字で区切られた文字列に連結します.。

次に、署名キーとして使用する一意のシークレットを生成する必要があります。シークレットはサーバーに安全に保管する必要があり、決してクライアントに送信してはなりません。この値を公開すると、誰でも有効なトークンを作成できるようになります。

シークレットを使用して、ヘッダーで指定されたハッシュ アルゴリズムを使用して結合されたヘッダーとペイロード文字列に署名することにより、プロセスを終了します。出力署名は、他のコンポーネントと同様に Base64 でエンコードする必要があります。

これで、タイトル、ペイロード、およびキャプションが個別のテキスト コンポーネントとして表示されます。それらをすべて区切り記号で連結し.て、クライアントに送信する JWT を作成します。

受信 JWT の検証

クライアント アプリケーションは、トークンのペイロードをデコードすることで、ユーザーが使用できる機能を判断できます。JavaScript の例を次に示します。

攻撃者は、このデータがプレーン テキストであり、簡単に変更できるように見えることを理解できます。次のリクエストでトークン ペイロードを変更することで、ボーナス機能があることをサーバーに納得させることができます。

サーバーがこれらの攻撃に対してどのように防御するかという質問に対する答えは、署名の生成に使用される方法にあります。署名値では、トークン ヘッダーとペイロードが考慮されます。この例のようにペイロードを変更すると、署名が無効になります。

サーバー コードは、署名を再計算することにより、着信 JWT を検証します。クライアントから送信された署名がサーバーで生成された値と一致しない場合、トークンは偽造されています。

攻撃者は、サーバーのシークレットにアクセスしないと有効なトークンを生成できません。また、シークレットの偶発的な損失 (または意図的なローテーション) により、以前に発行されたすべてのトークンが直ちに無効になることも意味します。

実際の状況では、認証コードはトークン ペイロードの有効期限と「前」のタイムスタンプもチェックする必要があります。これらは、ユーザーのセッションが有効かどうかを判断するために使用されます。

JWT を使用する場合

JWT は、サーバーでの実装、クライアントでの使用、およびネットワーク境界を越えた転送が容易であるため、API 認証によく使用されます。シンプルであるにもかかわらず、各トークンはサーバーの秘密鍵を使用して署名されているため、セキュリティは良好です。

JWT はステートレス メカニズムであるため、発行されたトークンに関する情報をサーバーに記録する必要はありません。データベース ルックアップを実行する代わりに、トークンのペイロードから JWT を表すクライアントに関する情報を取得できます。この情報は、トークンの署名が検証されると信頼できます。

JWT の使用は、干渉のリスクなしに 2 つのパーティ間で情報を交換する必要がある場合に適しています。ただし、注意すべき弱点があります。サーバーの秘密鍵が漏洩したり、署名検証コードにバグがあると、システム全体が危険にさらされます。このため、多くの開発者はオープン ソース ライブラリを使用して JWT の生成と検証を実装することを好みます。オプションは、すべての一般的なプログラミング言語で利用できます。トークンを自分で検証する際の見落としのリスクを排除します。

概要

JWT 標準は、組み込みの整合性チェックを含むデータ交換形式です。JWT は、API サーバーとクライアント アプリケーション間の通信をセキュリティで保護するためによく使用されます。サーバーは、署名を再現できる場合、着信トークンを信頼できます。これにより、トークンのペイロードから取得した情報を使用して安全にアクションを実行できます。

JWT は便利ですが、いくつかの欠点があります。JWT の Base64 でエンコードされたテキスト表現は、ペイロード フィールドが複数ある場合、すぐに大きくなる可能性があります。クライアントがすべてのリクエストで JWT を送信する必要がある場合、これは許容できないオーバーヘッドになる可能性があります。

JWT のステートレス性も潜在的な欠点です。一度発行されたトークンは不変であり、有効期限が切れるまでそのまま使用する必要があります。JWT ペイロードを使用してユーザー権限またはライセンス機能を決定するクライアントは、割り当てが変更されるたびに、バックエンドから新しいトークンを受け取る必要があります。