開発者ツール · JWT デコーダー
JWE の説明: 暗号化された JWT には 5 つの部分があり、読み取り可能なペイロードがない理由
· 背景
jwt 暗号化 データ形式
一部のトークンには、2 つではなく 4 つのドットがあり、ペイロードが JSON ではありません。この投稿では、JWE コンパクト シリアル化、その 5 つの部分のそれぞれが何を保持しているのか、そしてデコード専用ツールがその主張を表示できない理由について説明します。
4 つの点と JSON ではないペイロード — JWS ではなく JWE を保持していることを示します
4 つのドットと 5 つのセグメントは、よく知られた 3 部構成の署名付きフォームとは異なるコンパクトなエンベロープを示します。 JWT が主張するように中間バイトを解析しようとしても、内容は暗号文であり、平文 JSON の Base64URL スペルではないため、ナンセンスになります。
ToolAcre はデコード前にセグメント数をチェックします。 5 つの部分により、JWE を識別する INVALID_JWT メッセージがトリガーされ、復号化キーがないとこのデコード専用ルートに何も表示されない理由が説明されます。これは、曖昧な解析の失敗ではなく、正確な境界です。
5 つの部分 — 保護されたヘッダー、暗号化されたキー、初期化ベクトル、暗号文、および認証タグ
コンパクトな JWE パーツは、保護されたヘッダー、暗号化されたキー マテリアル、初期化値、暗号文、および認証タグを表します。それぞれに異なる暗号化の役割があります。セグメントの位置だけでは、2 番目または 4 番目のフィールドが読み取り可能な JWT ペイロードになりません。
デコーダーは一部のバイトを分割してbase64url デコードできますが、生のバイトは復号されません。これらをテキストとして表示すると、置換文字や誤解を招く断片が作成されます。正しいアクションは、エンベロープを特定し、承認された受信者の実装に移行することです。
alg と enc — キー管理とコンテンツ暗号化、および JWE ヘッダーで 2 つのアルゴリズムが名前付けされている理由
JWE ヘッダーには、キー管理用の `alg` とコンテンツ暗号化用の `enc` を含めることができます。これらのラベルはさまざまな操作を説明します。署名付きトークンと同様、ヘッダー値は、トークンが任意のアルゴリズムを選択する許可ではなく、受信者ポリシーに一致する必要がある入力です。
ToolAcre の 3 部構成のアルゴリズム ノートは JWE 処理を実装しておらず、5 部構成の分岐はヘッダー解析前に終了します。したがって、このページでは特定の暗号化アルゴリズムを表示または推奨するものではありません。サポートされている選択肢については、受信側のライブラリと発行者の契約を参照してください。
コンテンツ暗号化キー — ランダムなキーがペイロードを保護し、それ自体が受信者のためにラップされる方法
コンテンツ暗号化では通常、生成されたコンテンツ暗号化キーが使用されますが、暗号化キー セグメントは受信者の取り決めに基づいてそのキーを伝達または導出します。この分離により、ペイロード バイトをコンテンツ暗号で保護できる一方で、キー管理ポリシーによって誰がキーを回復できるかを決定できます。
この概念モデルは、コンパクトな文字列を所有するだけでは平文の復元に不十分である理由を説明します。必要な受信者の秘密とポリシーは、自由に使用できる命令としてエンコードされません。公開デコーダはそれらを発明することはできず、ユーザーに秘密の復号化キーを一般的なページに貼り付けるように要求してはなりません。
発行者が JWE を選択した場合 — クライアントまたは仲介者に対して秘密にしておく必要があるクレーム
発行者は、署名付きトークンを閲覧できる所有者または仲介者に対してクレームを機密にしておく必要がある場合、暗号化を選択できます。それが正しい選択かどうかは、脅威モデル、キーの配布、および運用要件によって異なります。不必要なデータを暗号化するよりも、請求内容を最小限に抑える方が望ましい場合もあります。
暗号化によって、承認、検証、またはメタデータの問題が解消されるわけではありません。受信者は、保護されたコンテンツを認証し、復号化後にトークン ポリシーを適用する必要があります。許可された受信者によって取得された読み取り可能な結果は、すべてのサービスで自動的に受け入れられるわけではありません。
デコードがヘッダーで停止する理由 — ペイロードは暗号文であるため、キーの所有者のみがそれを読み取ることができます
ペイロードとなるセグメントが暗号文であるため、デコードは構造で停止します。 ToolAcre は、任意のバイナリを JSON として表示することを意図的に回避し、代わりに特定のメッセージを表示します。これにより、ユーザーが意味不明な内容を、本来は有効な暗号化されたエンベロープの破損として解釈することがなくなります。
あなたが受信者である場合は、適切なキーとアルゴリズムで構成された管理されたソフトウェアを使用してください。そうでない場合、読み取り不能なペイロードは予期されるセキュリティ プロパティです。パディング トリックや代替文字デコーダを復号化に置き換えることはできません。
これでカバーされないもの — 署名されて暗号化されるネストされた JWT、および JWE JSON シリアル化
ネストされた構造では、コンテンツに署名してから結果を暗号化することも、定義されたプロファイルの下でレイヤーを結合することもできます。 JWE には、コンパクトな 5 部構成の文字列を超える表現もあります。 ToolAcre はそのようなケースを処理しません。また、この記事ではヘッダー ラベルだけからネストを推測することはありません。
トラブルシューティングを行う前に、システムがどの層を想定しているかを文書化してください。そうしないと、チームが暗号文の署名検証を試みたり、認証されていない内部トークンをデコードしたりする可能性があります。選択した JOSE ライブラリが明示的なポリシーに基づいて順序付けを処理できるようにします。
要点: デコーダーは、暗号化されていないもののみを表示できます。ToolAcre JWT デコーダーは、署名付きトークンのヘッダーとペイロードを表示します。 JWE のペイロードは設計上読み取り不可能です
デコーダーは、暗号化されていないもののみを表示できます。 ToolAcre は 3 部構成の署名付き入力のヘッダーとペイロードから JSON を読み取りますが、5 つのセグメントにより説明停止が発生します。この区別により、デコード専用インターフェイスが受信者機能があるかのように装うことができなくなります。
信頼結果ではなく、ルーティングの手がかりとしてセグメント数を使用します。 3 つの読み取り可能な部分は依然として署名検証が必要です。 5 つの暗号化部分には、承認された復号化と検証が必要です。どちらの場合も、視覚的な出力だけで主張を認証したり、アクセスを許可したりすることはできません。