開発者ツール · JWT デコーダー
Base64 と Base64url: JWT が標準 Base64 デコーダーで失敗する理由
· 仕組み
jwt base64 エンコード
JWT セグメントを通常の Base64 デコーダに貼り付けると、文字またはパディングに関してエラーが発生する可能性があります。この投稿では、base64url バリアントの JWS 義務と、この 2 つの間で変換する方法について説明します。
無効な文字、不正なパディング — Base64 が Base64url と一致するときに表示されるエラー
「無効な文字」または「不正なパディング」メッセージは、通常の Base64 を期待するデコーダーに JWT セグメントが与えられたことを意味します。トークンは正しくコピーされる可能性があります。その表現は、base64url 規則に従いますが、受信側ユーティリティは、関連するが同一ではないアルファベットを受け入れるか、明示的なパディングを要求します。
ToolAcre は、ヘッダーとペイロードの不一致を回避します。そのバイト デコーダは空白を削除し、URL セーフなシンボルを変換し、長さが許せば省略されたパディングを復元し、バイトを厳密な UTF-8 として変換します。どの段階でも失敗すると、生のブラウザ例外ではなく INVALID_JWT エラーになります。
2 つのアルファベット — プラスとスラッシュ、ハイフンとアンダースコア、および URL が変更を強制した理由
標準 Base64 では、アルファベットの最後の 2 つの位置にプラスとスラッシュを使用します。 Base64url は、ハイフンとアンダースコアを同じ位置に割り当てます。基礎となる 6 ビット値は変更されないため、`-` を `+` に、`_` を `/` に変換すると、デコードされたすべてのバイトが保持されます。輸送に安全なスペルのみが変更されます。
これらの置換は、プラスまたはスラッシュがすでに構文を持つチャネルで重要です。 URL セーフなスペルにより、フォームまたはパスの処理による誤った解釈が減少します。秘密性、完全性、信頼性を追加するものではありません。セグメントを受信した人は誰でも、暗号キーを使用せずに置換を元に戻し、同じバイトを復元できます。
パディング — JWS が等号を削除する理由と、厳密なデコーダー用に等号を復元する方法
ToolAcre は省略されたパディングを受け入れます。アルファベットの正規化後、セグメント長のモジュロ 4 が検査されます。 2 の余りには 2 つの等号が必要で、3 の余りには 1 つの等号が必要です。 1 の余りは完全な Base64 値では不可能であり、形状を推測するのではなく、切り詰められた文字列として拒否されます。
パディングの回復は機械的なフレーム化であり、トークンの修復ではありません。等号を追加しても、コピー中に失われた文字を復元することはできません。また、バイトのデコードが成功しても、そのバイトが発行者からのものであることはわかりません。この実装では、`atob` を呼び出す前に、ブラウザ デコーダが必要とする正規の長さを再構築するだけです。
トークン全体を一度にデコードする - 最初にドットで分割しなかったという間違い
コンパクト署名トークンは、セグメントをデコードする前にドットで分割する必要があります。 `header.payload.signature` を Base64 関数に渡すと、Base64 アルファベットではなく、JWT シリアル化に属するドットが導入されます。 ToolAcre は、この JWS 形状の入力に正確に 3 つのセグメントを必要とし、その構造が存在しない場合に観測された数を報告します。
暗号化されたコンパクトなシリアル化は同じオブジェクトではないため、5 つの部分からなるケースは別の JWE メッセージを受け取ります。代わりに、2 つまたは 4 つの部分は切り捨てまたは間違った入力を示唆します。この構造チェックは JSON 解釈の前に行われ、コピー エラーを不正な形式のエンコード テキストや不正な形式の JSON と区別します。
実用的な例 — 1 つのセグメントを Base64url から Base64 に変換し、パディングして JSON にデコードします
変換が成功した場合は、`eyJhbGciOiJIUzI1NiJ9` を使用します。バリアント間で異なるアルファベットは含まれていませんが、パディングが欠けていることでパイプラインが示されています。その長さによりパッドの復元が可能です。デコードにより `{"alg":"HS256"}` の UTF-8 バイトが生成され、JSON 解析により 1 つの `alg` プロパティを持つオブジェクトが生成されます。
ハイフンまたはアンダースコアを含むセグメントは、最初に 2 つの記号が置換された同じシーケンスに従います。 ToolAcre はこれらの操作を `base64ToBytes` 内で実行し、その後 `decodeSegment` が結果のテキストを解析します。表示されるアルゴリズムは、未検証ヘッダーで宣言されているものです。検証ポリシーとして選択されません。
クレーム内の Unicode — 名前を正しく表示するには、デコードされたバイトを UTF-8 として読み取る必要がある理由
クレームにはアクセント記号、CJK 文字、または絵文字が含まれる場合があります。 Base64 はバイトで動作するため、デコードされた各バイトを独立した文字として扱うと、マルチバイト テキストが破損します。正しいパスは、シンボルをバイトにエンコードしてから、UTF-8 デコーダーに至るパスです。 ToolAcre は致命的モードで `TextDecoder` を構築するため、無効な UTF-8 は大規模に失敗します。
テストは `Zoë 世界 🙂` を含むペイロードを対象としており、デコード後に正確な文字列が期待されます。この結果は、バイトからテキストへのパイプラインがこのテスト値を保存したことを証明しています。ペイロードで指定された人物が存在するかどうか、発行者が要求を承認したかどうか、トークンが変更されたかどうかについては、依然として何も述べられていません。
これでカバーされないもの — 署名セグメント。テキストではなくバイトにデコードされ、何かを意味するにはキーが必要です。
署名セグメントは JSON パスの外にあります。 ToolAcre は元のエンコード形式を保持し、デコードされたバイト長のみを測定しようとします。無効な署名 Base64 では警告が生成されますが、ヘッダーとペイロードの検査は妨げられません。 3 番目のセグメントが空の場合は、署名バイトが存在しないという別の警告が生成されます。
どちらの結果も検証結果ではありません。意味のある署名の検証には、信頼できる鍵マテリアル、攻撃者が制御する入力とは独立して選択された許可されたアルゴリズム、およびアプリケーションのチェックが必要です。バイト数は形状を診断するときに役立ちますが、測定された 0 バイトまたは 32 バイトではリクエストを承認したり、発行者を確立したりすることはできません。
要点: Base64url を話すデコーダーを使用します。ToolAcre JWT デコーダーは、ヘッダーとペイロードのアルファベットとパディングを処理します。
即時ジョブが JSON を検査している場合は、base64url を理解するデコーダーを使用します。 ToolAcre は、最初の 2 つのセグメントについて、アルファベット、省略されたパディング、厳密な UTF-8 およびオブジェクトのみの JSON を処理します。また、不可能な長さを拒否し、ヘッダーまたはペイロードが失敗したかどうかを識別するメッセージ内に解析失敗をラップします。
その境界で停止します。クリーンなデコードは、文字列に回復可能なバイトと適切な JSON オブジェクトがあったことを意味します。それは、その主張が信頼できる、認証されている、承認されている、または修正されていないことを意味するものではありません。個別に構成された検証機能のみがこれらの質問に答えることができ、このブラウザ ツールは意図的に検証操作を公開しません。