開発者ツール · JWT デコーダー
ID トークンとアクセス トークン: OpenID Connect JWT が API キーではない理由
· 背景
jwt 認証 認証
どちらも同じプロバイダーの JWT である可能性がありますが、答えは異なります。この記事では、ID トークンとアクセス トークンにそれぞれ何が含まれているか、誰がそれらを使用する必要があるか、そしてデコードによってそれらを区別する方法について説明します。
API は、完全に有効に見えるトークンを拒否します。これは、API 向けではないためです。
API は、資格情報が別のコンシューマおよび目的のために発行されたため、整形式で正しく署名されたトークンを拒否する可能性があります。 「JWT です」は、可能な形式を説明するものであり、どこにでも送信する許可を示すものではありません。 ID トークンとアクセス トークンは、ID フロー内のさまざまな質問に答えます。
ToolAcre は、デバッグをサポートするヘッダーおよびペイロード パターンを公開できますが、トークンを認証したり、OpenID Connect プロファイルを検証したりすることはできません。最終的な分類は、目視検査ではなく、プロバイダー契約、発行フロー、および信頼できる検証結果に基づいて決定される必要があります。
ID トークンの主張は ID の使用を示唆する場合があります。この汎用デコーダは OpenID Connect プロファイルを検証しません
ID トークンは、サインインを要求したクライアントに認証情報を伝えます。プロファイルによっては、表示されるクレームには、ノンス、認証時間、認証方法、または別のトークンに関連するハッシュが含まれる場合があります。これらのフィールドは汎用 API 認可付与ではありません。
デコーダは `auth_time` を時間型フィールドとして扱い、コア 7 に含まれない限り、他の名前をアプリケーション固有として表示します。 nonce、`at_hash`、`amr`、またはクライアント オーディエンスのセマンティクスは検証されません。読み取り可能な ID ペイロードは、クライアントが正しく検証するまで信頼されないままになります。
アクセス トークンは JWT または不透明です。このデコーダに適合するのは 3 部構成の JWT のみです
アクセス トークンは、認可システムに基づいてリソース サーバーへの呼び出しを認可します。 JWT または不透明な文字列の場合があります。 ToolAcre のルートに適合するのは、3 つの部分からなる署名付き形状のみです。不透明なトークンには、デコードするための一般的なクライアント側構造がないため、このツールを強制的に使用しないでください。
JWT アクセス トークンは対象者とスコープの情報を運ぶことができますが、それらの値には認証された検証とリソース ポリシーが必要です。ブラウザ パネルにはリソース サーバーが実装されていないため、スコープで特定の操作が許可されているかどうかを判断できません。
リフレッシュ トークン — 通常は不透明で、デコードされることも、API に送信されることもありません。
リフレッシュ トークンは、プロバイダー ルールに基づく置換アクセス資格情報の取得をサポートします。これは一般に不透明であり、リソース API 向けではありません。これは価値の高い認証情報でもあるため、デコーダに貼り付けると、信頼性の高い診断上の利点が得られずにリスクが生じます。
すべてのトークン型の値をデコードする必要があると推測しないでください。更新の失敗には、プロバイダー ツールと管理されたログを使用します。 ToolAcre のプロダクション トークンに対する明示的な警告は、ここでは特に強く適用され、その 3 セグメント パーサーは更新操作を提供しません。
対象ユーザーが異なります - ID トークン内のクライアント ID とアクセス トークン内のリソース
対象とする消費者は異なるため、視聴者は強力な手がかりとなります。多くの場合、ID トークンはクライアントをターゲットにし、アクセス トークンはリソースをターゲットとします。正確な識別子と表現はプロバイダーとプロファイルに依存するため、この記事は普遍的な文字列パターンを考案するものではありません。
ヘッダー `typ` も明示的なラベルを提供できますが、検証されるまでトークン管理されたデータのままです。 ToolAcre は、文字列 `typ` が `JWT` と異なる場合にのみ警告します。すべてのプロファイル ラベルを認識したり、プロファイル ラベルを承認の決定に変換したりするわけではありません。
実用的な例: 表示されているフィールドをトークン タイプの証拠として扱わずに比較する
2 つの合成例をデコードします。1 つはクライアント指向の認証クレームを伝え、もう 1 つはリソース オーディエンスとスコープを伝えます。 `aud`、`typ`、およびペイロード名の違いを記録します。この演習では、どちらの例の身元を証明する方法ではなく、発行者に何を尋ねるべきかを学びます。
偽造されたトークンは同じラベルをコピーでき、実際のトークンはプロバイダー固有の規則を使用できます。発行応答とドキュメントからタイプを確認し、対象の消費者に検証してもらいます。デコーダーの出力は証拠を裏付けるものであり、決定権を与えるものではありません。
これでカバーされないもの — これらのトークンを発行する OAuth フローについては、別のトピックとして説明します
この比較では、トークンを発行する認証コード、デバイス、またはその他のフローについては説明しません。また、プロバイダー固有の検証手順、不透明なアクセス トークンのイントロスペクション、または更新ローテーションについても説明しません。これらの主題は、選択したエコシステムとデプロイメントによって異なります。
当面のデバッグに関する質問は絞り込んでください: クライアントが受け取った資格情報はどれか、その対象となる消費者は誰で、どの信頼できるコンポーネントが資格情報を検証するか?これら 3 つの質問に答えることで、汎用の JWT 形状がプロトコルの役割を消去することを防ぎます。
要点: 送信する前に aud を見て入力してください。ToolAcre JWT デコーダーを使用すると、保有しているトークンの種類を確認できます。
トークンを送信する前に対象ユーザーを調べて入力しますが、検証が成功するまではどちらのフィールドも信頼しないでください。 ID トークンはクライアント検証境界に属します。アクセス トークンはそのリソース サーバーに属します。リフレッシュ トークンは、API ではなく、プロバイダーのリフレッシュ プロセスに属します。
ToolAcre は、3 部構成の例を安全に読み取るのに役立ちますが、それらを分類または検証するとは主張しません。これを使用して間違いの可能性を特定し、文書化されたフローと個別に構成された検証ツールによって資格情報の本当の目的を確立します。