シェア:
){kind=small}
スタンダップ・コメディーの学位論文を持つ俳優の訓練を受け、ミートアップ・シーンを経てPHP開発に携わるようになった。技術について話したり書いたり、レコード・コレクションから変わったレコードを再生したり買ったりしています。
JWT：JWTとは何か？
デベロッパー・エクスペリエンス・チームがチュートリアルを書く際の原則のひとつに、次のようなものがあります。 決してということだ。これは私が忘れがちなことで、定期的に自分に言い聞かせる必要がある。もしあなたが 罪悪感この方程式の反対側で罪悪感に苛まれることがあれば、私はいつもこの常緑のベン図に戻ってくると便利だと思う：
私の仕事の一部として、PHP SDKを開発するために、JWTを常に、毎日扱っています。JWTの使い方を調べたら、それで終わりでした。 しかし、しかし、私の「知識を前提としない」という原則のもと、以下のような人がたくさんいることに気づきました。 多くの人ががいることに気づいた。さらに、ある程度の経験（APIの構築や利用においてでさえ）を持つ開発者の中には、JWTをまだ使ったことがない、あるいは聞いたことすらないという人もいる。API技術の進化のペースは、多くの人が思っているよりも、大規模なビジネスやスケールアップしたビジネスではずっと遅い傾向がある。この記事を書いている時点で2023年だが、多くの銀行や製薬会社はいまだにSOAPを使っている。
JWTの解剖学に飛び込む前に、この記事にはコードを使った例が含まれていることに注意してください。JWTを作成するために私たちのツールのいくつかを代わりに使いたいのであれば、次の記事をご覧ください。 Benjamin Aronovによるこの記事をご覧ください。Vonage Dashboard内でJWTを生成する方法が紹介されています。
JWTはJSON Web Tokenの略である。少し紛らわしい頭字語のスパゲッティ・シナリオだが、厳密にはJavaScript Object Notation Web Tokenを完全な形で表している。2011年7月のドラフトで導入されるまで、ウェブAPIの認証の最も一般的な形式は、リクエストのクエリー文字列に暗号化されていないAPIキーとシークレットを追加するか、APIキーまたはシークレット（またはその両方）のいずれかが、通常はbase64エンコーディングでハッシュ化され、ヘッダーとして渡されるBasic認証であった。JWTはリクエストのヘッダーに含まれるハッシュで（あるいはボディに含まれることもあるが、あまり一般的ではない）、旧来の認証スタイルに取って代わるものだ。
では、なぜ新しい認証技術が必要なのか？
これが最も重要な要素だ。全てのリクエストのヘッダー（またはクエリー文字列）に暗号化されていないAPI KeyやSecretを送信することは、かなり大きなセキュリティのベクトルを開くことになる。同じクレデンシャルでより多くのトラフィックがスニッフィングされる可能性があり、これらのキーが漏洩した時点で、アプリケーションやアカウント全体がオープンになってしまう。
ベーシック認証には罠がありがちだ。{ユーザー名}:{パスワード}を文字列として受け取り、それをbase64エンコードするというスタイルだ。API認証に慣れていない開発者の多くは、出来上がったハッシュを見て「安全そうだ！」と思うかもしれないが、実際は2つの秘密の部分に簡単にデコードされてしまう。例えば https://emn178.github.io/online-tools/base64_decode.htmlにアクセスし c2VlLXRoYXQtd2FzOmVhc3k=.
これらの方法を使用する際に作成できる唯一の本当のセキュリティ層は、キーをローテーションすることだ。API製品にもよるが、大きなレガシー・コードベースではメイン・キーとシークレットの組み合わせをローテーションする機能すらないかもしれない（特にアカウント作成時にアカウントに直接紐付けられている場合）。
以前は、基本的なタイプの認証では、新しい鍵をポートフォリオに追加していた。 に追加していた。新しい鍵は、プライマリ・キーの上にポートフォリオに追加される。 スコープ.その結果、様々な製品や特定のクエリに使用されるキーのコレクションが膨大になり、大量のキーを定期的にローテーションすることが非常に面倒になります。
スコープと同様、このような固定シークレットも、ユーザーの権限、スコープ、APIアクセス権がサーバー内に保存されている。このため、リクエストを受け取る際に考慮すべきパラメータが多く、より複雑なAPIを使用する場合には、シークレットは静的で柔軟性がありません。
JWTは、これら3つの懸念事項すべてに対処することを目的としている。JWTの構造はこうだ：
ヘッダー」という場合、これはJWTのヘッダーであることに注意すべきである。 JWTのヘッダーのヘッダーであり、HTTPリクエストのヘッダーではないことに注意する必要がある。
サーバーは、JWTがどのように作成されたかについての情報を必要とする。この要求の結果、ヘッダーはJWTがどのように作成されたかについての情報を2つのキーで含むことになる：
alg多くの場合、デフォルトはHS256となる。typトークンをJWTとして識別する（標準が進化するにつれて、トークン・タイプの反復や新しいバージョンが存在する可能性がある）。
JWTのペイロードは、次のような形になっている。 クレームこれはJWTに関する情報を含む一連のキーと値のペアである。最も一般的な予約（または*登録クレーム名）は以下の通り：
issJWTの送信元（アプリケーション、組織など）。sub他のクレームがJWTの文脈で参照する、発行者に固有の値。expJWTの有効期限iat: JWTが作成された（発行された）日時jtiこの JWT の一意な識別子。
JWTは、それを消費するアプリケーションに関連するカスタム・クレームを追加できるので、認証にとても便利です。例えば Vonage JWT- を使用する場合、JWT認証をサポートする当社のAPIでは、カスタムクレームが使用されます、 application_idが使用されます。VonageはJWTをあなたのアカウントのSSH秘密鍵（これはリクエストクライアント側でJWTを生成するために使用された）と照合することができ、有効であれば、リクエストはVonage API内の正しいアプリケーションインスタンスに素早くルーティングされます。
私のチーム専属のPHP開発者として、できるだけ少ないコード行数で有効なJWTを生成し、比較的簡単に始められることを示す。必要なものは以下の通りだ：
ダッシュボードのアプリケーションID。
アプリケーションの秘密鍵のコピーがダッシュボードからダウンロードされた。
どちらもアプリケーションの設定から取得できます：
ここでは、GitHubにあるVonage社のPHP JWT creatorを使用する。インストールにはcomposerが必要です。
そして次はコードだ：
<?php
require_once "vendor/autoload.php";
$applicationId = "78d335fa-323d-0114-9c3d-d6f0d48968cf";
$privateKey = file_get_contents('private.key');
$generator = new Vonage\JWT\TokenGenerator($applicationId, $privateKey);
$jwt = $generator->generate();
完了した！
リクエストでこれを使うには、ヘッダーとして追加する必要があります。そのためには PSR-18準拠のHTTPクライアントが必要です。少ない行数でできることを示すために、symfonyのHTTPClientを選びました。これらをインストールするには、composerでプロジェクトに追加します：
そして、リクエストを Vonage Messages API にリクエストを POST します。にリクエストをPOSTします：
use Symfony\Component\HttpClient\HttpClient;
$payload = [
'message_type' => 'text',
'text' => 'Using a JWT to send Vonage a request!',
'to' => '44779999999',
'from' => '44779499999',
'channel' => 'sms'
]
$client = HttpClient::create();
$client->request('POST', 'https://api.nexmo.com/v1/messages/', [
'headers' => [
'Authorization' => 'Bearer ' . $jwt,
'Content-Type' => 'application/json',
],
'json' => $payload
])
これで完成だ！もちろん、これは生の例です。もし完全な統合をしたいのであれば、私たちのCore PHP SDKを使うことをお勧めします。PHPがお好みでなくても大丈夫です！Node、Java、Python、Ruby、NET SDKもあります！