開発者ツール · JWT デコーダー
対象者と発行者のチェック: JWT が他の場所で再生されないようにする
· なぜそれが重要なのか
jwt 認証 セキュリティ
あるサービスに対して発行されたトークンは、同じ発行者を共有する別のサービスに提示できます。この投稿では、aud チェックと iss チェックがそれを阻止する方法と、トークン内の両方のクレームを読み取る方法について説明します。
サービス B はサービス A 向けのトークンを受け入れます。これは、有効な署名では防止できないサービス間のリプレイです。
署名は、別のサービスに対して発行されたトークンに対して有効である場合があります。複数の API が同じ ID プラットフォームを信頼しているが、受信者のコンテキストを無視している場合、サービス A 向けの資格情報がサービス B で再生される可能性があります。暗号化の整合性だけでは、誰が資格情報を消費すべきかはわかりません。
ToolAcre は `iss` と `aud` を明らかにできるため、開発者は明らかな不一致を見つけることができます。これらの文字列は、署名が成功するまで検証されず、ブラウザ ツールがそのチェックを実行することはありません。実際のリソース サーバーは、発行者関係と対象読者の両方を強制する必要があります。
iss — サービスが信頼する発行者にトークンをバインドする、およびキー バインドなしでは文字列の一致だけでは不十分な理由
`iss` は、ペイロードがトークンを発行したと主張するエンティティを識別します。検証者は、独自の構成で予想される正確な発行者を必要とし、その ID を正しい鍵検出関係にバインドする必要があります。暗号化バインドなしでテキストを比較すると、攻撃者が予想される文字列をコピーする余地が残ります。
デコーダーは `iss` を「誰がトークンを作成したか」と説明しますが、これは登録された意味であり、貼り付けられた値に関する結果ではありません。判読可能な発行者のテキストは、設定をデバッグするための有用な証拠となります。任意のキー ソースを選択したり、自身を認証したりすることはできません。
aud — 対象の受信者を指定する文字列または配列、および検証者がその中で自分自身を見つける必要があるルール
`aud` は、対象となる受信者の名前を指定し、1 つの文字列またはコレクションとして表示されます。リソース サーバーのポリシーは、そのプロファイルで要求される正確な比較ルールを使用して、認証された値内でそれ自体を見つける必要があります。他のよく知られたサービスがリストされているという理由だけでトークンを受け入れるべきではありません。
ToolAcre は配列をクレーム テーブル内の JSON テキストとして保持し、検査用に表示される構造を保持します。現在の API の識別子がわからないため、一致を判断できません。この意図的な欠如により、汎用デコーダが所有していない認可コンテキストを発明することができなくなります。
azp とscope — 誰が何のためにトークンを使用できるかを絞り込む OpenID Connect および OAuth クレーム
`azp` および `scope` は、承認された当事者と要求された権限に関するコンテキストを、それらを定義するプロファイルに追加できます。これらは、対象者、発行者、または署名の小切手に代わるものではありません。スコープ名はアサーションであり、リソース サーバーが認証された値を独自のポリシーにマップするまではアクセス許可の付与ではありません。
現在のデコーダは、登録された記述テーブルが 7 つのコア名をカバーしているため、これらをアプリケーション固有のクレームとして扱います。値は表示されますが、OpenID Connect または OAuth セマンティクスは提供されません。決定に使用する前に、該当するプロファイルとプロバイダー契約を確認してください。
混乱した代理のパターン — オーディエンスがチェックされていない場合、正規のトークンがどのように攻撃になるか
混乱した副官が、意図しない状況で正当な権限を使用します。間違ったサービスによってトークンが受け入れられた場合、誰も署名を偽造していない場合でも、まさにそのパターンがトリガーされる可能性があります。対象者チェックは認証されたクレームを適用できる場所を制限しますが、発行者チェックはサービスが誰のアサーションを考慮するかを制限します。
これが、一般的な「署名有効」フラグではまだ不十分である理由です。承認は受信者と操作によって異なります。 ToolAcre は検証結果を報告しないことでその曖昧さを完全に回避し、利用するサービスは暗号化とコンテキスト ポリシーを組み合わせることができます。
動作した例 — ToolAcre JWT デコーダーの 2 つのトークンから iss と aud を読み取り、どのサービスがそれぞれを受け入れる必要があるかを決定します
デコードされたペイロードが `aud` だけが異なる 2 つの無害なトークンを作成します。1 つは `service-a` という名前で、もう 1 つは `service-b` という名前です。どちらも同じ発行者を主張しています。 ToolAcre は違いを目に見える形で示します。サービス A の検証者は、単にこの表示からどちらも受け入れるべきではなく、認証されたサービス B の視聴者を拒否すべきです。
次に、2 つの発行者文字列を使用して演習を逆に実行します。検証にその発行者にとって信頼できるキーが使用されない限り、予想されるテキストだけでは十分ではありません。これらの例は、検査と受け入れを区別し、正しく見えるクレームを偽造トークンにコピーしても信頼できるポリシーが変更されない理由を示しています。
これでカバーされないもの — デコーダーが決して実行しない署名検証。 aud および iss チェックは、署名が保持された後にのみ重要になります
対象者と発行者のチェックは、保護されたバイトが信頼できるキー マテリアルに対応していることが暗号検証によって確立された後にのみ重要になります。 ToolAcre はその検証を一切実行しません。その出力では、クレームがそのまま残っていることや、既知の発行者がクレームを作成したことを証明することはできません。
また、メタデータの取得、キーの選択、構成された受信者の比較も行いません。バックエンド テストとログを使用して、間違った発行者と間違った対象者が拒否されたことを証明します。デコーダ内の視覚的な一致はデバッグの手掛かりであり、十分な認証の証拠にはなりません。
要点: 誰が署名したかだけでなく、誰のためのものかを確認してください。ToolAcre JWT デコーダーは、比較する必要がある aud クレームと iss クレームを示します。
トークンに署名されている名前だけでなく、トークンが誰のためのものであるかを確認してください。堅牢なフローは、独立して信頼できる発行者関係に基づいて保護されたバイトを認証し、受け入れ可能な対象者を必要とし、サービス固有の認可ルールを適用します。
ToolAcre を使用して安全なテスト値を読み取り、次のサーバー側チェックを策定します。信頼できないヘッダーまたは要求データから検証キーを選択しないでください。また、完全な信頼できるフローなしで、表示された `iss`、`aud`、`azp`、または `scope` を許可に変えないでください。