開発者ツール・JWTデコーダー
JWT の構造: ドットの分割と Base64url のデコード
· 仕組み
jwt エンコーディング セキュリティ
JWT は、ドットで区切られた 3 つの Base64url セグメントです。この投稿では、各部分を手動でデコードし、署名セグメントがテキストではない理由を説明し、デコーダーが何を伝えられるのか、何が伝えられないのかを示します。
Authorization ヘッダーの長い文字列 - 表示されている内容と、ドットが 2 つある理由
ベアラー トークンは、多くの場合、コンパクトなドット区切りの文字列として Authorization ヘッダーに届きます。コンパクトな JWS 形式の一般的な署名付き JWT には 3 つのセグメントがあり、したがって 2 つの区切られたドットがあります。アクティブなトークンは資格情報です。実稼働トークンをデモに貼り付けないでください。
コンパクトなシリアル化 - 3 つの Base64URL セグメントとしてのヘッダー、ペイロード、署名
コンパクトな JWS シリアル化では、最初のセグメントは保護されたヘッダー、2 番目のセグメントはペイロード、3 番目のセグメントは署名または MAC です。署名は、ドットで結合された、エンコードされた最初の 2 つのセグメントをカバーします。文字列を分割するとセグメントが特定されます。信頼を確立することはできません。
パディングなしの Base64url — JWS が使用するアルファベットと、セグメントの末尾に等号がない理由
Base64url では、通常の Base64 の + と / の代わりに - と _ が使用されます。コンパクト JWS は末尾の = パディングを省略します。デコーダはデコード前にパディングを復元できます。デコードするとバイトが生成されます。 JSON ヘッダーとクレームの場合は、テキストを解析する前にバイトを UTF-8 としてデコードします。
ヘッダー — アルゴリズムと、多くの場合キーを命名する小さな JSON オブジェクト
ヘッダーは通常、alg を含む JSON であり、場合によってはキー識別子、kid を含みます。これらはトークン自体によって行われるアサーションです。検証者は、独自の許可アルゴリズム ポリシーを適用し、適切なキーを安全に取得する必要があります。 alg を読み取るだけでは許可されません。
ペイロード — トークンを保持している人なら誰でも読み取り可能なクレームの JSON オブジェクト
ペイロードには、sub、exp、aud などのクレームが含まれています。トークンを持っている人は誰でもそれらを読むことができます。エンコーディングは暗号化ではありません。 exp NumericDate は Unix エポックからの秒数をカウントしますが、未検証の主張には権限がありません。シークレットを読み取り可能なペイロードに保存しないでください。
署名 - 最初の 2 つのセグメントにわたる生のバイト。テキストとしては無意味で、キーがなければ役に立たない
最後のセグメントは、base64url でエンコードされた署名バイトであり、3 番目の JSON オブジェクトではありません。これを検証するには、暗号化アルゴリズム、キー、およびアプリケーション ポリシーが必要です。 ToolAcre は意図的に検証を実行しません。署名の存在を報告し、常に SignatureVerified false とマークします。
実用的な例 — 表示される JSON を含む、サンプル トークンをセグメントごとにデコードする
非機密デモンストレーション ヘッダー {"alg":"HS256","typ":"JWT"} とペイロード {"sub":"demo"} を考えてみましょう。 Base64URL エンコードは eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 および eyJzdWIiOiJkZW1vIn0 です。デコードすると JSON が復元されます。任意の 3 番目のセグメントを追加しても、トークンが本物になるわけではありません。
要点: デコードは読み取りであり、信頼することではありません。ToolAcre JWT デコーダーはヘッダーとペイロードを表示し、署名を検証しないため、表示されるものは何もトークンが本物であることを証明しません
デコードは読み取ることであり、信頼することではありません。使い捨てトークンのヘッダー、クレーム、警告には ToolAcre JWT デコーダーを使用します。アプリケーションの信頼できる検証ツールを使用して、署名付きトークンが有効かどうかを判断します。表示されたクレームだけでアクセスを許可してはなりません。