開発者ツール · JWT デコーダー
デコードと検証: JWT 署名が証明するものと、デコーダーが署名をスキップする理由
· 仕組み
jwt セキュリティ 暗号化
デコードにはキーは必要ありません。正しいものが必要であることを確認します。この投稿では、署名の対象範囲、HMAC 検証と非対称検証の違い、およびデコード専用ツールが何も証明しない理由について説明します。
正常にデコードされたため、有効である必要があります。これが、偽造トークンの受け入れにつながる仮定です。
攻撃者が新しいペイロードを書き込み、任意のテキストを 3 番目のセグメントとして添付した後、トークンは完全にデコードできます。 Base64url および JSON 解析はパブリック変換です。どちらも、誰が文字列を組み立てたかをチェックしません。したがって、「クレームが画面に表示された」ということは、発行者がクレームを作成または承認したという証拠にはなりません。
ToolAcre は、いくつかの場所でこの境界を強化します。結果には常に `signatureVerified: false` が含まれ、UI は出力の横に未確認クレームのアラートを繰り返し、テストでは `valid` または `verify` サーフェスが存在しないとアサートされます。それは意図的な誠実さであり、便利な機能が欠けているわけではありません。
署名の内容 - ドットで結合された、エンコードされたヘッダーとペイロードの正確なバイト
コンパクト JWS の場合、署名入力は、エンコードされた保護ヘッダー セグメント、リテラル ドット、およびエンコードされたペイロード セグメントです。検証は、新しくきれいに印刷された JSON ではなく、正確にエンコードされたバイトに関係します。プロパティの順序を変更したり空白を変更すると、人間が同等のオブジェクトを見ている場合でも、異なるバイトが作成される可能性があります。
3 番目のセグメントは、その入力上で生成されたエンコードされた署名または MAC バイトを伝送します。 ToolAcre は生のセグメントを保存し、そのバイト長を報告する場合がありますが、暗号化チェックは実行しません。データ形状を測定しても、予想されるキーによってデータ形状が作成されたのか、最初の 2 つのセグメントが変更されていないのかを確認することはできません。
HMAC と非対称 — 検証できる人なら誰でも偽造できる共有秘密と、検証しかできない公開鍵
HMAC では、共有秘密は MAC の作成と確認の両方をサポートします。そのシークレットを使用して検証できる当事者は、別のトークンを作成することもできるため、シークレットの配布によって信頼境界が定義されます。 ToolAcre のメモでは、認識されている HS アルゴリズムのラベルについてこの結果が明示されています。
非対称署名は、プライベートな署名機能をパブリックな検証資料から分離します。公開鍵を所有すると、署名権限を付与せずに検査をサポートできます。この区別は、ヘッダーで宣言された非対称ラベルを信頼できるものにするものではありません。検証者は、どのアルゴリズムと発行者キーが受け入れられるかをすでに知っている必要があります。
キーの出所 — 共有シークレットの構成、公開キーの JWKS エンドポイント、子供によって照合される
共有シークレットは、トークン テキストではなく、保護されたサービス構成から取得する必要があります。公開検証キーは、信頼できる発行者の関係と管理されたキー セットから取得される場合があります。 `kid` は、そのセット内での選択に役立ちますが、任意の信頼できないヘッダー コンテンツをファイル、データベース、またはネットワーク ルックアップに変換してはなりません。
ToolAcre には発行者の構成がなく、キーも要求しないため、責任を持って検証を実行することは不可能です。一般的な Web ページでは、どの組織を信頼しているか、どの視聴者にサービスを提供しているか、アプリケーションがどのアルゴリズムを許可しているかを推測することはできません。これらはアプリケーション ポリシーの入力であり、デコードによって検出できるプロパティではありません。
デコードにキーが必要ない理由 — Base64url は暗号化ではなくエンコードであるため、誰でもクレームを読み取ることができます
Base64url は暗号化ではなく可逆エンコードであるため、デコードにキーは必要ありません。ヘッダーとペイロードはトークンと一緒に移動することを目的としており、どの所有者でも回収できます。これにより、有用な検査が可能になりますが、機密情報がエンコードされた文字の視覚的なノイズの背後に隠れてはいけないことも意味します。
JSON 解析では構造のみが追加されます。これにより、`roles` が配列であるか、`exp` が数値であることがわかりますが、どちらかの値が本物であるというわけではありません。 ToolAcre は、構造化された値をテキストとしてレンダリングし、登録された説明をドキュメントとしてレンダリングしますが、承認はポリシーを検証して強制できるシステムに任せます。
うまくいった例 — ペイロード文字が 1 つ変更されたトークンでも完全にデコードされます。確認通知のみ
ペイロードが `{"sub":"demo","role":"reader"}` である合成トークンから始めます。エンコードされたペイロード文字を 1 つ変更して、バイトが引き続き有効な JSON を形成し、おそらく別の役割が生成されるようにします。どちらのバージョンも分割、デコード、整形印刷が可能です。デコード パスには、変更されたバージョンを拒否する理由はありません。
正しく構成された検証器は、変更された署名入力に対する暗号結果を再計算またはチェックし、不一致を拒否します。この比較は、正確な境界を示しています。デコーダーの成功は構文をカバーしますが、検証者の成功は、クレーム ポリシーが評価される前に、信頼できるキーと許可されたアルゴリズムに対する整合性を確立できます。
これでカバーされないこと — ToolAcre JWT デコーダーは、仕様上、署名を検証しません。トークンが本物であることを証明するものは何もありません
ToolAcre は署名を検証しません。空のセグメントは警告を受け取り、不正な形式の署名エンコーディングは別の警告を受け取り、測定可能なバイトは存在するが検証されていないと報告されます。これらのブランチはどれも本物のトークンの判定を生成しません。この実装には、隠しキーの取得やアルゴリズムの実行パスはありません。
暗号検証が成功しても、アクションが自動的に承認されるわけではありません。消費側サービスには、発行者、対象者、時間、およびアプリケーション固有のチェックが依然として必要です。サポートとデフォルトが異なるため、この記事はライブラリの構成前で終了します。サービスで使用されている正確な検証ツールとバージョンを確認してください。
要点: デコードして検査し、検証して信頼する — 最初の場合は ToolAcre JWT デコーダーを使用し、2 番目の場合は適切なキーを持つサーバー側ライブラリを使用します。
デコードして、信頼する前に検査および検証します。ヘッダー フィールド、ペイロード値、時間変換、構造上の警告を確認する必要がある場合は、期限切れのトークンまたは合成トークンのブラウザ ツールを使用します。読み取り可能な出力をアクセス決定に直接流さないでください。
独自に提供された鍵マテリアル、ピン留めされたアルゴリズム、およびサービス ポリシーを使用して、結果として生じる作業を信頼できる検証者に移動します。そのパスのみが信頼性と整合性をテストでき、その後のクレーム チェックのみが承認を決定できます。デコーダがこれらのジョブを曖昧にすることを拒否するのは、セキュリティ機能です。