署名付きJWTが実際に役立つシナリオは何ですか？
[〜＃〜] update [〜＃〜]：この問題についての調査を終了し、調査結果を説明する長いブログエントリを投稿しました：JWTの暗黙の脆弱性。ローカル認証にJWTを使用するための大きなプッシュで、署名鍵を保護する必要があるという重要な詳細が1つ省略されていることを説明します。また、キーを保護するために最大限の努力を払うつもりがない限り、Oauth）を介して認証を委任するか、従来のセッションIDを使用する方がよいことも説明します。
（この投稿は賛成/反対投票の戦いに耐えており、-2の低さでした。以前はシステムのセキュリティを評価するために支払われていたので、この調査と上記の結論を却下しないようにしてください手を離れて。）
各リクエストを承認するためにデータベースにアクセスする必要がない高度にスケーラブルなAPIの手段として、JSON Web Token（JWT）を次々に宣伝しています。署名を確認することでデータベースの検索が不要になることは知っていますが、このアプローチではサーバーが悪用されるリスクが非常に高くなるようにも思えます。
攻撃者がサーバーに侵入し、データベースを含むファイルシステム全体への読み取りアクセス権を取得するシナリオを考えてみましょう。また、侵入がしばらく検出されなくなったと想定します。
従来のソリューションでは、パスワードのハッシュとセッションIDのハッシュが保存されるため、攻撃者はインターフェースを介してアプリケーションを利用できません。一方、サーバーがダウンストリーム認証のために署名されたJWTを発行する場合、署名キーはハッシュされていない場所に存在する必要があります。攻撃者がそれを見つけた場合、攻撃者はその後、有効期限が切れていないJWTトークンを偽造して、気付かれずにダウンストリームサーバーにアクセスできます。 （攻撃者は、クライアントを確認するためにルックアップを実行することで検出される可能性がありますが、スケーラブルな認証にJWT署名を使用する目的に反する可能性があります。）
サーバー侵害は起こります。一般に、アカウントは書き込みよりも多くの読み取りを実行できるため、ほとんどの違反は読み取り専用であると想定するのが妥当と思われます。それらが発生したとき、プレーンテキストではなくハッシュされた値を格納することにより、影響が最小限であると宣言できる企業は誇りに思います。残念ながら、JWTベースの承認の下では、会社は「はい、ハッシュパスワードを実行します」と言わなければなりませんが、いずれにしてもすべてのアカウントが危険にさらされていました。 （セッションは、期間が短いため、通常はそれほど問題になりません。）
キーの正当な使用法は数多くあり、キーを保護するためのアプローチは多数あり、キーの盗難には通常重大な結果が伴うことを理解しています。ただし、この場合、人々は古い認証メカニズムを新しい安全性の低いものに置き換えることを提案しています。それは私には意味がありません。
それでも、多くの賢い人々がJWT署名の標準と実装に多大な努力を注いできました。 Oauthトークンイントロスペクションプロトコルの存在は、安全なシステムが認証のためにトークンだけに依存しないことのさらなる証拠です。署名されたJWTの本当の利点は何ですか？JWT署名は本当に何を意図していますか？ために？
以下は、私が認識している一見、より正当な使用法です。
- サーバー全体のシークレットで署名すると、データベースに到達する前にリクエストを停止できるため、DoS攻撃の影響を最小限に抑えることができます。
- 中間レベルのセキュリティのみを必要とするJWTペイロードデータを検証します。 （私はそのようなデータを想像するのに苦労します。）
- 信頼されていないマイクロサービスが、一般的に信頼されている認証サービスから取得した認証情報を効率的に共有できるようにするため。 Nordic APIsの説明 を参照してください。 （しかし、私はまだその恩恵に感謝しようとしています。）
他の人も持っている可能性が高いですが、私はこれらの最初のものを自分で考えました。他の用途がよくわかりません。なぜ誰もがJWTに署名するのかについての明確で説得力のある説明はまだ見ていません。
本当のスクープは何ですか？ご協力いただきありがとうございます！
（質問の背景：署名ベースの承認を通じてスケーラビリティを得るという考えを放棄するかどうかを決定しようとしています。）
追伸代替の「認証」スキームとして説明されているJWT署名を見てきました。トークンの取得時に認証が行われ、その後は認証のみになると確信しています。私が間違っていたら訂正してください。
JWTのステートレスフェデレーションの利点についてはすでに説明しましたが、それらについては同意できると思います。
攻撃者は、保護されたリソースにアクセスするためにユーザーのパスワードを必要とせず、認証コンテキストにアクセスするだけです。
サーバー側のトークン、またはセッションベースのメソッドで見逃しているリスクの1つは、これらの識別子もサーバーに保存されることです。実際、これらのファイルは、ファイルシステム（秘密キーが最も頻繁に格納される）であるデータベースよりも読み取り専用で危険にさらされることが多い場所に格納されることがよくあります。攻撃者がセッションIDまたは認証トークンを取得すると、JWTを使用する場合と同じように、依存パーティにアクセスできます。
チェーンのもう1つの弱点は、ユーザー側のストレージです。これは、多くの場合、サーバーよりも標的型攻撃への妥協が容易です。このリスクは、トークンを頻繁に循環させることである程度軽減できます。よく実装されたJWTシステムのコア機能ですが、実際には長寿命のセッショントークンでは頻繁には実行されません。
Sven Slootwegによる セッション管理に使用されるJWT についての素晴らしい記事があります。最後の記事では、JWTを活用できるいくつかのユースケースについても触れています。
特に、彼は使い捨て認可の必要性について話します。例はダウンロードサーバーで、JWTを受け入れてファイルアクセスを承認します。 JWTはクライアントの認証と承認に必要なすべての情報を持っているため、ダウンロードサーバー自体をステートレスに保つことができます。