Learn-json-web-tokens: なぜ「単回使用」でMITMを解決できるのでしょうか。

@ NE-SmallTown良い質問。
シングルユーストークンを使用することは、アプリケーションのセキュリティにとって良い習慣です。
このパターンを使用する場合は、応答ごとにJWTを自動的に更新するonPreResponseフックを設定できます。

あなたが答えなければならない質問は、トークンが再利用されないようにすることをどのように計画していますか？
識別子をある種のデータベースに保存し（_通常、アプリではこれにredisを使用します_）、トークンがすでに使用されているかどうかを確認する必要があります。

@nelsonic返信ありがとうございます。少し混乱しています。

質問があります。

あなたが言うように、プロセスは次のとおりです。

ユーザーがホームページにアクセスし、ヘッダーでトークンを送信します（ログインしていることを前提とします）

                                       |
                                       |
                                       ↓

サーバーはトークンを受け取り、トークンをデコードしてuserId取得し、データベースに移動して（ redisではなくデータベースを使用すると仮定）、 userId対応するトークンを取得します。 ==演算子を使用して、それらが等しいかどうかを確認します。等しい場合は、トークンを破棄して新しいトークンを生成し、データベースにプッシュして、それとデータをクライアントに応答します。

質問があります。チェックには==演算子を使用しますがいるので、使用しません。例：

JWT.require(Algorithm.RSA256((RSAKey) publicKey))
                .withIssuer("auth")
                .withSubject("ne-smalltown")
                .withAudience(userId)
                .withArrayClaim("jwt-role", userRole)
                .build()

私が間違っている場合、トークン自体を使用する方法と場所を教えていただけますか？上記のようなメカニズムを検証しますか？

IMO、トークン自体のvertifyメカニズムを使用できる唯一の場所は、古いトークンのexpパラメーターを取得して新しいトークンに配置し、トークンが古くなっているかどうかを確認してユーザーを再ログインさせることです。

                                        |
                                        |
                                        ↓

クライアントは新しいトークンを受け取り、それをlocalstorageにプッシュして古いトークンを置き換えます。次のリクエストでは、それを使用します。

@nelsonicこんにちは？

@ NE-SmallTownすぐに返信しなかったことをお詫びします。
JWT仕様には、1回限りの無効化に関するクレーム/メカニズムがありません。
参照： http ：

@jbspeakrには、
参照： https ：

@nelsonic投稿を共有していただきありがとうございます。

投稿によると：

理論的には、これはパスワードリセットトークン以外のユースケース（電子メールのアクティブ化、アカウントの確認など）でも機能します。

私はこれらのケースがシングルユースjwtに適していることに同意しますが、私のケースはjwtにユーザーロール情報が含まれ、ロールが一定であり、パスワードのリセット、電子メールのアクティブ化、アカウントの確認などが好きではありません。

質問に戻りますが、私の場合、トークンを垂直化する必要はないと思います。データベースのトークンで==演算子を使用するだけです。