開発者ツール · JWT デコーダー
Base64 と jq を使用して JWT ペイロードを手動でデコードする方法
· 仕組み
jwt コマンドライン 開発者ワークフロー
ヘッドレス ボックスでも、cut、tr、base64、および jq を使用してトークンを読み取ることができます。この投稿では、コマンドを示し、各コマンドが実行する Base64URL 変換について説明し、落とし穴をリストします。
SSH 経由でのトークンの読み取り - ブラウザーが使用できない場合
ヘッドレス サーバーでは、トークン型の文字列が残され、ブラウザ UI が表示されない場合があります。必要な検査作業はまだ小規模です。1 つのセグメントを分離し、base64url のスペルを変換し、パディングを復元し、バイトをデコードし、JSON を解析します。シェルの履歴には生きた資格情報が保存される可能性があるため、この危険は計算上のものではなく、運用上のものです。
可能な限り、期限切れのトークンまたは合成トークンを使用してください。インシデント対応で実際の値を調べる必要がある場合は、組織の資格情報の処理制御に従い、共有履歴やログに記録されないようにして、公開後にローテーションしてください。コマンドラインのデコードは検査のみに留まります。検証キーや信頼ポリシーは提供されません。
ドットでの分割 — ペイロード セグメントを分離するための Cut または awk
コンパクトな JWS 形状の JWT には、ドットで区切られた 3 つのフィールドがあります。ペイロードは 2 番目です。シェルは区切り文字対応ツールを使用して分割できますが、シェルが文字を展開したり空白を分割したりしないように変数を引用符で囲みます。先頭の `Bearer ` ラベルは HTTP 構文に属しているため、フィールドを選択する前に削除してください。
フィールド 2 をやみくもに取得するのではなく、フィールドを数えます。 ToolAcre は 3 つの部分以外のものを拒否し、5 つの部分からなる暗号化された入力を個別に識別します。シェル パイプラインにも同様の構造上の注意を払う必要があります。不正な入力からセグメントを受信すると、元のトークンが切り捨てられたことを隠しながら、もっともらしい JSON が生成される可能性があります。
アルファベットの変換 - ハイフンとアンダースコアをプラスとスラッシュに戻す tr
標準のコマンドライン Base64 実装では、通常、JWT セグメントにハイフンとアンダースコアが含まれる場合がある場合、プラスとスラッシュが必要です。 `-` を `+` に、`_` を `/` に変換すると、表現された 6 ビット値を変更せずに、URL セーフ シンボルが標準の位置にマッピングされます。
オプション解析で先頭のハイフンをフラグと誤認できない変換コマンドを使用し、データを引用符で囲まれた変数または標準入力に保持します。アルファベット変換は可逆的なエンコード作業です。クレームは復号化されず、成功してもトークンが指定された発行者からのものであることは証明されません。
パディングの復元 - 適切な数の等号を追加する算術
変換後、4 を法とする長さを計算します。剰余 0 には等号は必要ありません、剰余 2 には 2 が必要で、剰余 3 には 1 が必要です。残り 1 は切り捨てを示し、パイプラインを停止する必要があります。ユーティリティが問題を報告しなくなるまで任意のパディングを追加すると、損傷を診断するのではなく、隠すことができます。
ToolAcre は、`base64ToBytes` でまさにこの長さルールを使用し、不可能な剰余を拒否します。シェル ユーティリティは省略されたパディングを受け入れるかどうかが異なるため、最初に入力を正規化することでパイプラインが明示的かつ概念上移植可能になりますが、コマンド フラグはオペレーティング システム間で異なる場合があります。
デコードと整形印刷 — Base64 -d を jq にパイプ接続
パディングされた値をプラットフォームの Base64 デコーダーにパイプしてから、`jq` に渡します。最初のコマンドはバイトを回復します。 2 番目の場合は、これらのバイトが JSON を形成する必要があります。 Base64 コマンドが成功した後に jq 解析エラーが発生した場合は、エンコードは構造的にはデコード可能だが、そのコンテンツが JSON ペイロードではなかったことを意味します。
この区別は、ToolAcre のエラー パスを反映しています。最初に無効なbase64urlまたはUTF-8を報告し、次に無効なJSONを個別に報告し、JWTヘッダーまたはペイロードがこのツールのオブジェクトである必要があるため、null、配列、およびプリミティブを拒否します。ステージを分離しておくと、失敗が対処可能になります。
実用的な例 — サンプル トークンの完全なパイプラインと各ステージの出力
合成例の場合、ペイロード セグメント `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9` にはアルファベット変換やパディングは必要ありません。デコードすると `{"sub":"demo","role":"reader"}` が生成され、そのオブジェクトが複数行にわたって jq 形式でフォーマットされます。表示される役割は、トークンによって提供される単なる文字列です。
ここで、JSON を変更し、再度エンコードして、3 番目のセグメントをアタッチします。パイプラインは変更されたオブジェクトを引き続き出力します。これは、デコード コマンドが有効性チェックとして機能できない理由を証明しています。別の検証者が署名をチェックしない限り、正規のクレームと捏造されたクレームの両方が同じパブリック変換を通過します。
落とし穴 — トークンをキャプチャするシェル履歴、パディングの欠落を拒否する Base64 実装、先頭に 'Bearer' が付いているトークン
一般的な失敗には、HTTP プレフィックスの保持、間違ったドット区切りフィールドの選択、コピー中の末尾文字の損失、パディングを必要とする Base64 実装の使用などが含まれます。もう 1 つの落とし穴は、プロセス リストや履歴にトークン全体が保持される可能性があるコマンド ラインにトークン全体を直接配置することです。
適切な制御の下で標準入力および一時変数を優先し、便宜上、実稼働トークンをチャット、チケット、または共有端末に貼り付けないでください。また、3 番目のセグメントは JSON ではなくバイナリ署名素材であるため、jq を介して送信すると失敗し、署名の有効性については何も通知されないことにも注意してください。
要点: どの環境でも同じデコード - ブラウザがある場合、ToolAcre JWT デコーダーは何もアップロードせずにローカルでこれを実行します。
シェル パイプラインと ToolAcre は、異なる環境で同じデコード専用シーケンス (分割、正規化、パディング、UTF-8 のデコード、JSON の解析) を実行します。検査および制御できる環境を使用し、機密データではないデータをデフォルトとして使用します。
どちらのパスも信頼性を検証したり、呼び出し元を承認したりしません。ペイロードの形状を読み取った後、サービスの信頼できる検証ツールとログに移動して、暗号化とポリシーの決定を行います。かなりの JSON を生成するコマンドは、セキュリティの判断ではなく、フォーマット タスクを完了しました。