初めてLaravel APIで壊れたauthフローをデバッグしなければならなかったとき、信頼できるトークンを生成できなかったため、午後を無駄にしました ミドルウェアは401 を返し続け、バグが検証コードにあるのか、トークンに供給されているのかを特定した、既知の良いJWTが必要でした sub、特定の有効期限、および私が制御した秘密、それで私は問題の片側を分離することができました スタックオーバーフローの答えからランダムなトークンをコピーすることは、それが秘密で署名されていなかったため、助けの反対を行いました。
それがJWTジェネレーターが埋めるギャップです これはプロダクション署名サービスではありません JSON Webトークンを消費する何かを構築またはテストしている瞬間のベンチツールであり、オンデマンドで有効なものが必要であり、正確な主張と選択した正確な秘密ツールの仕組み、JWTの組み立てとサイン方法、トークンを手作業で生成することでリアルタイムに節約できる実際のケースについて説明します。
tl;dr: JWTジェネレーターは、JSONペイロードとシークレットを1 つ加えたものを署名付きトークンに変換します クレームを貼り付け、HS256、HS384、またはHS512 を選択し、シークレットを入力して、トークンをコピーします JWT ジェネレーター ブラウザweb Crypto APIで署名するので、ペイロードとシークレットはマシンから離れることはありません。 knownでテストトークンを作成するために使用します
sub、設定された有効期限、または意図的に期限切れになったexpAPI's エラーパスを行使するには。 to read a token back, pair it with the JWT デコーダ。
JWT とは何ですか?また、発電機は何を生成しますか?
JSON Web Token は、クレームのセットを表すコンパクトで URL セーフな方法です。 RFC 7519 で定義された構造と、 " a JWT, " でほぼ全員が意味している署名付きフォームは、RFC 7515 で定義されている JSON Web Signature です。 署名付きトークンは、ドットで結合された 3 つの部分を持ちます: header.payload.signature。
ヘッダーは、署名アルゴリズムとトークン タイプに名前を付ける小さな JSON オブジェクトです { "alg": "HS256", "typ": "JWT" }。 payload はクレームの JSON オブジェクトです: トークンが誰であるか、いつ期限切れになるか、アプリケーションが追加するカスタムフィールドはどれでも ヘッダーとペイロードの両方が Base64url エンコードされており、これは RFC 7515 で指定されているとおり、2 文字の置換とパディングのない通常の base64 です。署名は、最初の 2 つの部分にわたって計算されたキー付きハッシュです。
ジェネレータは3 つすべてを組み立てます ペイロードとシークレットを供給し、ヘッダーを構築し、両方のセグメントをエンコードし、署名を計算し、それらを結合します 出力は、ストレートにドロップできる文字列です Authorization: Bearer ヘッダー、テストフィクスチャ、または curl コマンド.
率直に言っておく価値のあることの1 つ: 署名されたJWTは暗号化されておらず、エンコードされている トークンを保持している人は誰でも、Base64url-decodeでペイロードをデコードし、その中のすべてのクレームを読み取ることができる 署名は内容を隠さない 内容がキーのない誰かによって変更されていないことを証明するだけである パスワード、APIキー、その他ユーザーに表示されないものをJWTペイロード内に決して置かないでください。
サインはどのように機能しますか?
このツールが署名する HMAC ファミリの場合、署名は次のとおりです HMAC(secret, header + "." + payload)。 HMAC は RFC 2104 によって定義されたキー付きハッシュ構造であり、JWA 仕様 RFC 7518 は 3 つの JWT アルゴリズム名をそれにマッピングします。HS256 は SHA-256 で HMAC を使用し、HS384 は SHA-384 を使用し、HS512 は SHA-512 を使用します。
重要なプロパティは対称性です 同じ秘密が署名の作成と検証の両方を行います サーバーがトークンを受け取ると 再計算します HMAC(secret, header + "." + payload) 受信した最初の2 つのセグメントにわたって、結果が署名セグメントと等しいことを確認します ペイロードの1 バイトが変更された場合は、再計算されたハッシュが一致せず、検証が失敗します それが完全性の保証全体です。
対称的であるため、秘密はゲーム全体です秘密を持っている人は誰でもあなたのシステムに有効なトークンを鋳造することができます、それがジェネレータがWeb Crypto APIを介してブラウザで署名を実行し、秘密をどこにも送信しない理由ですトークンを生成しながらブラウザ& #39; s ネットワークタブを開くことでこれを確認できます: リクエストはありません これは、それが聞こえるよりも重要です、なぜなら、ライブプロダクション署名秘密を電話ホームが認証の鍵を渡すことになるランダムなWebツールに貼り付けるからです。
非対称アルゴリズムである RS256 と ES256 は動作が異なります。秘密キーが署名され、一致する公開キーが検証されます。これらは、多くのサービスがトークンを検証する必要があるが、トークンを発行できるのは 1 つだけである必要がある場合に正しい選択です。このツールは意図的にそれらを提供しません。なぜなら、これらのツールで署名することは秘密キーを Web ページに貼り付けることを意味し、それは決して始める価値のない習慣だからです。
JWT Generatorの使い方
ステップ1: ペイロードを書き込みます
JSONオブジェクトとしてクレームを入力します 最小の例としては { "sub": "1234567890", "role": "admin" }。 ザ・ sub claim は件名、通常はユーザー id です。 など、アプリケーションが読み取るカスタム フィールドを追加できます role、 scope、 tenant_id、または email.ツールはここに置いたものを正確に書かれたまま保持します。
ステップ 2: 時間に関するクレームを追加します
発行済みのままにして工具スタンプを押します iat 現在の Unix 時間で。 を追加するには秒単位で有効期限を設定します exp claim computed as now plus that offset. 15 分のアクセストークンの場合は 900 と入力します。1 時間のトークンの場合は 3600 と入力します。これらは最も認証バグが多いクレームであるため、ミリ秒ではなく時代以来の秒単位で正しく計算すると、一般的な間違いが解消されます。
ステップ3:アルゴリズムと秘密を選択します
HS384 またはHS512 を使用する理由がない限り、HS256 を選択してください フィールドに署名シークレットを入力します 次に、シークレットの解釈方法を選択します: プレーンテキストは入力した内容のUTF-8 バイトを使用しますが、base64urlとhexは最初に文字列をrawバイトにデコードします 多くのシステムはすでにbase64エンコードされたシークレットを保存し、エンコードされた文字列をプレーンテキストとしてフィードすると一致しない署名を生成するため、この選択は重要です。
ステップ4:トークンをコピーします
署名付きJWTは、ヘッダーとペイロードの復号化されたプレビューとともに表示されるため、使用する前にすべてのクレームを確認できます。コピーして、必要な場所に貼り付けます。
なぜ手でトークンを生成するのでしょうか?
API' のハッピー パスをテストします
JWT を検証するミドルウェアを書くとき、コードが受け入れるべきトークンが必要です。 verifier が使用するのと同じ秘密で署名されたものを、有効なもので生成します exp、および確認要求は200 を返します。 、そうでなければ、バグがトークンではなく、あなたの検証ロジックにあります。 この単一の分離ステップは、私が最も頻繁にツールに手を伸ばす理由です。
障害パスのテスト
ロバストな API は、適切な理由で適切なトークンを拒否します。 を指定したトークンを生成します exp 正しい expired-token エラーを返すことを確認するために、すでに過去に。 a で生成します nbf 将来的にはまだ有効ではないパスをテストする 署名チェックが実行されることを確認するために、間違った秘密で署名されたパスを生成する これらの否定的なケースはテストされずに発送されるものであり、ジェネレーターはそれらを32番目のジョブにします。
特定のユーザーからのバグを再現する
サポートは、特定のロールを持つアカウントでのみ発生する問題を報告します。その正確なトークンを生成します role クレームと影響を受けるユーザー' s sub、そして、あなたは、生産データに触れることなく、またはあなたがとにかく決してすべきではない、彼らの本当のベアラートークンをユーザーに求めることなく、ローカルに要求を再現することができます。
種まき 地域 発展
チーム内の新規開発者は、フロントエンド認証がまだ構築されている間に保護されたエンドポイントを攻撃するために、動作するトークンを必要とします。ローカル開発シークレットで署名された生成されたトークンは、それらをすぐにブロック解除します。
HS256 vs HS384 vs HS512: どちらを使用する必要がありますか?
| アルゴリズム | ハッシュ | 署名のサイズ | 最小キー長 | いつ使うか |
|---|---|---|---|---|
| hs256 | SHA-256 | 32 バイト | 32 バイト | デフォルト。 、広くサポートされる高速、ほとんどすべての使用のための安全 |
| HS384 さん | SHA-384 | 48 バイト | 48 バイト | ポリシーまたは標準でSHA-384 が必要な場合 |
| HS512 さん | SHA-512 | 64 バイト | 64 バイト | 高セキュリティのコンテキスト、またはすでに SHA-512 を標準化している場合 |
外部の何かがそうでないことを要求しない限り、実用的な答えはHS256 です。 RFC 7518 では、キーが少なくともハッシュ出力と同じ長さであることが必要なため、HS256 では32 バイト、HS384 では48 バイト、HS512 では64 バイトです。 ジェネレータは、デコードされたシークレットが最小値よりも短い場合に警告します。なぜなら、短いキーはアルゴリズム名に関係なく署名を弱めるからです。より長く、より高い番号のアルゴリズムは弱いシークレットを修正しません。; 適切な長さのランダムなシークレットが重要です。
よくある間違いとそれを避ける方法
最も頻度の高いものはエンコードによるシークレットの不一致ですフレームワークはシークレットをbase64 として保存し、base64 文字列をプレーンテキストとして貼り付け、今やキーバイトは検証者が使用するものと異なります署名は決して一致せず、ファントムバグを追いかけますツールで正しいシークレットエンコーディングを選択して、生のキーバイトが両側で同一になるように修正します。
2 つ目は、秒とミリ秒を混乱させるものです RFC 7519 で登録された時刻の主張は、すべてUnixエポック以降の秒で測定されます。 JavaScript& #39; s Date.now() ミリ秒を返します 計算すると exp あなた自身と1000 で割ることを忘れると、あなたのトークンは今から5 万年後に期限切れになるように見えますが、いくつかの厳密な検証者はこれを拒否します。ジェネレーターにクレームを計算させると、これは完全に回避されます。
3 つ目はペイロードをプライベート扱いですそうではありませんクレームに秘密を保管する誘惑に駆られたらやめてくださいトークンを持っている人なら誰でも読めますトークンホルダーが見ていて心地よいものだけを保存し、サーバー上に真に秘密のデータを保管してください。
JWT が他のツールと一緒に適合する場所
トークンを生成したら、当然の次のステップはトークンを読み返すことです。 the JWT デコーダ 任意のトークンをヘッダーとペイロードに分割し、期限切れのフラグを立てます exp、これはあなたが意図したことを生成ジェネレータを確認する方法です。 secrets も生成している場合、 ハッシュジェネレーター SHA ハッシュをクライアント側で計算します パスワード ジェネレーター そもそも良い HMAC シークレットを作るような長いランダム文字列を生成します。 Base64url を手作業で理解したい場合は、 Base64 エンコーダ / デコーダ ヘッダーとペイロードをエンコードされた形式に変換するのと同じ可逆変換を示します。そして、a にドロップするためにランダムな識別子が必要な場合 sub や jti 主張、 uuid ジェネレーター 適切な形式で 1 つを提供します。
ブラウザベースのツールが機密資料をサードパーティのサーバーから遠ざける理由をより広範囲に把握するには、次の手順を実行します オンライン ツールのデータ プライバシー ガイドではクライアント側モデルについて説明します Web 開発者ツールキット トークン作業と適切に組み合わせるユーティリティをまとめます。
サーバーは生成したトークンをどのように検証しますか?
反対側で何が起こるかを知るのに役立ちます なぜ秘密や主張が 正確に正しくなければならないのかを説明してくれるからです APIがトークンを受け取ると jsonwebtoken や jose や PyJWT のようなライブラリは 3 つのことを順番に実行し トークンをドットに分割し Base64url-decodes ヘッダーで を読み取るようにします alg。 署名を再計算します header.payload 設定された秘密を使用して、署名セグメントに対してバイト単位でそれを比較します。 そして、それは登録されたクレームをチェックします: です exp 過去には、です nbf 将来的には、そうです iss あんど aud APIが期待するものと一致します.
それらのチェックのどれもが ジェネレーターが制御できるものに マップします 署名で検証に失敗した場合 シークレットまたはそのエンコーディングは 2 つの辺で異なります オンで失敗した場合 exp、トークンの有効期限が切れているので、そのパスをテストするために意図的に引き起こした可能性があります。 に失敗した場合 alg、検証者が受け入れるように構成されていないアルゴリズムでトークンを生成しました。これ自体が発見するのに便利です。意図的なバリエーションを持つトークンを生成することは、API がどのチェックを強制し、どのチェックをサイレントにスキップするかを正確に計画する方法です。
に関する一言 alg ヘッダー具体的に。 RFC 7515 が定義します none 署名されていないトークンの有効なアルゴリズムとして、初期のライブラリはクレームしたトークンを信頼します alg: none そして検証を完全にスキップします それが古典的なJWTの脆弱性です 現代のライブラリはデフォルトで拒否しますが ジェネレータは を提供します none API で署名されていないトークンを起動し、それが「いいえ」と表示されることを確認できるように、正確にオプションを選択します。 API がトークンを受け入れた場合、重大なバグが見つかりました。
シークレットやトークンストレージをどのように扱うべきですか?
署名するシークレットは、データベースのパスワードと同じ注意が必要です。 HMAC のセキュリティは、キーが推測できないかどうかに依存するため、優れた HMAC シークレットは、記憶に残るフレーズではなく、長くてランダムな文字列です。パスワード ツールを使用してシークレットを生成し、ソース制御では決して設定せずに環境構成に保存することがベースラインです。回転すると、古いシークレットで署名されたすべてのトークンは、検証者が切り替わった瞬間に無効になることに注意してください。そのため、運用システムは通常、回転ウィンドウ中に複数の有効なシークレットをサポートします。
クライアント側では、完成したトークンをどこに保存するかは、署名方法と同じくらい重要です。 のトークン localStorage はページ上の任意の JavaScript で読み取れるため、単一のクロスサイトスクリプティングの欠陥が攻撃者に有効な資格情報を渡します。 an httpOnly、 Secure、 SameSite cookie はスクリプトからは見えず、CSRF 保護が必要であるという代償を払ってそのパスを閉じます。共通のパターンは、メモリに保存されている短寿命のアクセス トークンと、メモリに保存されている長寿命のリフレッシュ トークンです httpOnly cookie。これらはいずれもトークンの生成方法を変更しませんが、生成されたトークンを責任ではなく安全に使用できるようにするのはコンテキストです。
フェイク
JWTを生成するにはどうすればよいですか?
JSONオブジェクトとしてクレームを貼り付け、HS256 などの署名アルゴリズムを選択してシークレットを入力します ツールbase64url-encodes the header and payload, computes the HMAC signature, and returns the finished token for you to copy.すべてがブラウザで実行されます。
どの署名アルゴリズムがサポートされていますか?
HMAC ファミリである HS256、HS384、および HS512 に、未署名の "none" を加えたテスト用オプション。 RS256 と ES256 は秘密キーで署名するため意図的に提供されておらず、秘密キーを Web ページに貼り付けることはセキュリティ リスクを回避するのが最善です。
私の秘密はサーバーに送信されますか?
いいえ 署名はWeb Crypto APIを介してブラウザで完全に実行されるため、シークレットとペイロードがデバイスから離れることはありません。 「DevTools Network」タブでこれを確認でき、ツールはロードされるとオフラインで動作し続けます。
トークンの有効期限を設定するにはどうすればよいですか?
数秒で有効期限を入力すると、ツールが追加されます exp 現在の時刻にその数秒を加えたものに等しいと主張します。 15 分間のトークンの場合は 900 と入力します。省略するにはフィールドを空のままにします exp 完全に.
なぜシークレットは少なくとも 32 バイトである必要があるのでしょうか?
RFC 7518 では、少なくともハッシュ出力と同じ長さの HMAC キーが必要です。HS256 では 32 バイト、HS384 では 48 バイト、HS512 では 64 バイトです。シークレットが短いと署名が弱くなるため、デコードされたシークレットが短すぎるとツールは警告します。
署名のないトークンを作成できますか?
はい。 alg none を選択すると、ツールはヘッダー.payload を生成します。 token with a empty signature.これは、API が未署名のトークンをどのように処理するかをテストするためだけです; ほとんどのライブラリはデフォルトで alg:none を拒否します。
生成されたJWTは暗号化されていますか?
いいえ 署名されたJWTは暗号化されずエンコードされます: 誰でもbase64url-ヘッダーとペイロードをデコードし、すべてのクレームを読み取ることができます 署名は内容が変更されていないことを証明するだけです ペイロード内にパスワードや秘密を決して入れないでください。
