JSON Webトークン（JWT）を初めて見たときはよくわかりませんが、それ以来、多くの数を見てきました。訓練されていない私には、文字化けしたコンピューター出力のように見えます。
実際には、上記（およびJWT全般）は、クラウドとオンプレミスの両方で、セキュリティーに直接影響する重要な情報を保持しています。ユーザーを識別・認証するための情報です。JWT は、マイクロサービスベースのソリューションを機能させるために不可欠であり、 12 Factor Appを実現するための重要な構成要素です。
このブログ記事では、JWTの背景にある歴史を共有し、その基本概念を紹介し、IBM Cloudでの一般的なJWT使用シナリオについて見ていきます。
Thinkニュースレター
AI、サイバーセキュリティ、データ、自動化に関する厳選されたニュースをThinkニュースレターで購読しているセキュリティリーダーに加わりましょう。専門家によるチュートリアルと解説をメールで直接配信することで、手軽に学ぶことができます。IBMプライバシー・ステートメントをご覧ください。
サブスクリプションは英語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
JSON Web トークンの最初のドラフトはすでに 10 年以上前のものになります (2010 年 12 月)。初期ドラフトでは、「 JSON Web Token（JWT）は、二者間で転送されるクレームをエンコードできるトークン形式を定義します。JWT内のクレームは、デジタル署名されたJSONオブジェクトとしてエンコードされます。」と述べられています。
最新版のIETF RFC 7519では、次のように拡張されました。「 JSON Web トークン（JWT）は、2者間で転送されるクレームを表すための、コンパクトでURLセーフな手段です。JWT内のクレームは、JSON Web Signature（JWS）構造のペイロードとして、またはJSON Web Encryption（JWE）構造のプレーンテキストとして使用されるJSONオブジェクトとしてエンコードされ、クレームにデジタル署名を施したり、メッセージ認証コード（MAC）や暗号化によって整合性を保護したりできます。」
新しい説明では、JWT (多くの場合「ジョット」と発音されます) の 2 つの表現、つまりJSON Web Signature(JWS) またはJSON Web Encryption(JWE) 構造が示唆されています。JWS はRFC 7515で定義され、JWE はRFC 7516で定義されています。さらに関連する JSON ベースのセキュリティ標準もいくつかあり、すべてJOSE: JSON Object Signing and Encryptionと呼ばれるワークグループによって定義されています。
OAuth 2.0 は認証の業界標準です。詳細には立ち入りませんが、アクセストークンとリフレッシュトークンと呼ばれるものを含む、承認フローとコア概念を提供します。JWTは必須ではありませんが、最近では一般的に使用されています。前述したように、OAuthは認証に焦点を当てており、識別の処理にも悪用されることがありました。OpenID Connect は、パズルの欠けているピースを追加し、ID またはID トークンを導入します。ID トークンは JWT として表されます。
その歴史といくつかの基準を基盤として、上記のJWTをどのように処理し、どのような情報を保持しているのでしょうか?
上記のJWTは3つの部分で構成されており、それぞれがドット（「.」）で区切られています。
ヘッダーとペイロードは両方ともbase64urlでエンコードされており、パディングを考慮せずに次のようにデコードできます。
henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}
henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input
ヘッダーには、使用されているアルゴリズム（ここでは HS256（ HMAC SHA256））に関する情報が含まれます。ペイロードは、（アクセス/リフレッシュ/ID/…）トークンの種類によって異なり、クレームで構成されています。これらおよびその他の定義済み JOSE ヘッダーおよびペイロード フィールドは、 IANAによって管理されます。上記の例では、フィールドとクレームは、件名、名前、発行日時、および有効期限です。
署名は、指定されたアルゴリズムをヘッダー、「.」、ペイロードの連結に適用し、base64urlエンコードすることによって計算されます。その後、ドットで区切られた3つの部分がJWTを構成します。署名の導出方法の詳細は、 RFC 7515 で定義されています。
上記の JWT には、JTW.io のオンライン デバッガーでアクセスできます。まず、「署名が無効です」というメッセージが表示されます。表示されているデフォルトのシークレットを「!!!my-really-big-256-bit-secret!!!」に置き換えることで、この問題を解決できます。
IBM Cloud はカタログ内の多くのサービスを提供しており、独自のコンポーネントが多くあるインターネット・アプリであるため、トークンを多用します。おそらく、IBM Cloud コマンドラインインターフェース (CLI) とコマンドibmcloud iam oauth-tokens を使用したことがあるでしょう。
現在の CLI セッションの OAuth ベアラー トークン (アクセス トークン) を出力します。これは JWT として実装されます。これらの IAM トークンは、IAM 対応のクラウド・サービスにアクセスするために使用されます。
外部ユーザーをクラウド・アカウントに統合する場合は、JWTも使用します。トークンとそれに含まれるクレームは、ユーザーを識別するための認証のために交換されます。多くのソリューションは、セキュリティー サービスIBM Cloud App IDを活用しています。ユーザーを認証し、リソースを保護するのに役立ちます。これは、前述のOAuth 2.0 および OpenID Connect 標準を活用し、アクセストークン、IDトークン、およびリフレッシュトークンを処理します。
私の（そしてあなたの）お気に入りのサービスの 1 つは、チャットボットを構築するためのwatsonx Assistantです。Web チャットのセキュリティを強化したい場合 (つまり、交換されたメッセージをさらに保護し、メッセージの送信元を証明したい場合)、JWT が役に立ちます。
もちろん、JWTを利用して（セキュリティーの）クレームを容易にし、それによってクラウド・ソリューションのセキュリティーを強化する例は他にもたくさんあります。
JWTは、二者間でクレームを交換するための簡単で自己完結型の手段です。クラウドでもオンプレミスでも、広く普及しているデータ構造です。上記は、ご関心をお持ちいただけましたら幸いです（まだの方はご覧ください）。
JWT を自分で調べて調整したい場合は、まずhttps://jwt.io/のようなオンライン ツールを使用することをお勧めします。詳細を知りたい場合は、ネットワークモニターまたはブラウザーの開発者ツールを使用してJWTをチェックしてください。セキュリティー関連のチュートリアルが多数含まれているIBM Cloud チュートリアルをぜひご覧ください。
この投稿についてのフィードバック、提案、質問がある場合は、Twitter ( @data_henrik ) またはLinkedInで私に連絡してください。