クライアント側のJWTセッションを無効にする
JWTと、JWTを介して「ステートレス」セッションを作成する方法についてたくさん読みました。私が理解していることの要点は、署名と有効期限があるため、基本的にセッション全体を送信してクライアントに保存でき、サーバーはセッションを記憶するためにデータベースを維持する必要がないということです。
ユーザーがログアウトする必要がある場合、または有効期限が切れる前にセッションを無効にする必要がある場合はどうなりますか？
技術的には、クライアント側から削除するようにブラウザに指示することはできますが、これが実際に発生したかどうかはわかりません。トークン自体は技術的にはまだ有効であり、削除手順に従わなかった場合でも、トークンを使用できます。
この理解は正しいですか？もしそうなら、これはクライアント側のセッション管理の大きな欠点ではありませんか？サーバーにセッションを保存させるか、有効期限を短くする以外に、これを克服する方法はありますか？
有効期限が切れる前にJWTトークンを無効にする理由はいくつかあります。アカウントの削除/ブロック/一時停止、パスワードの変更、権限の変更、管理者によるユーザーのログアウトです。だからあなたの質問はトピックにあります
ユースケースに応じて、適用または組み合わせるいくつかの手法があります
1）ローカルストレージからクライアントトークンを削除します
2）トークンブラックリスト：ログアウトから有効期限までのトークンを保存し、有効期限をマークして、すべてのリクエストでチェックします。一意の識別子jtiを使用するか、最終ログイン日を含めてiatで発行し、古いトークンを削除します
サーバーストレージが必要です。取り消すトークンが多すぎると思われない場合は、メモリ内ブラックリストを使用することもできます。ユーザーとcurrentTime - maxExpiryTime < lastLoginDate (iat)の重要なデータを更新した後にのみエントリを設定する必要があります。エントリは、currentTime - maxExpiryTime > lastModified（期限切れでないトークンが送信されなくなった）のときに破棄できます。この場合、トークン全体を保存する必要はありません。 sub、iat、そして多分jti
3）有効期限が短く、ローテーションします。いくつかのリクエストごとに新しいアクセストークンを発行します。 トークンの更新を使用すると、アプリケーションは再認証してsliding-sessionsと組み合わせる必要なしに新しいアクセストークンを取得できます。
スライディングセッションは、非アクティブな期間の後に期限切れになるセッションです。ユーザーがアクションを実行すると、新しいアクセストークンが発行されます。ユーザーが期限切れのアクセストークンを使用する場合、セッションは非アクティブと見なされ、新しいアクセストークンが必要になります。この新しいトークンは、更新トークンを使用するか、資格情報を要求することで取得できます
その他の一般的な手法
アカウントが新しいユーザーとパスワードのログインで侵害された場合、ユーザーの一意のIDの変更を許可する
ユーザーがパスワードを変更したときにトークンを無効にするには、パスワードのハッシュを使用してトークンに署名します。パスワードが変更されると、以前のトークンは自動的に検証に失敗します。このメカニズムを他の関心分野で拡張して署名します。欠点は、データベースへのアクセスが必要なことです
署名アルゴリズムを変更して、主要なセキュリティ問題で現在のすべてのトークンを取り消します
見てください JSON Webトークンの無効化
私はいくつかの宿題をしましたが、失効を実装するためのより良いアプローチは、jti（Jtwのid）と失効したidのブラックリスト（トークンの有効期限が切れるとクリアされる）を使用することだと思われます。これにより、JTWはブラックリスト部分のみに対してステートフルになります。
ブラックリストare JWTステートレス違反。使用できる認証スキームはたくさんあります。 JWTはステートレスに基づいているため、そのように使用する必要があります。一方、これは非常に一般的な認証スキームであり、それを実装する必要があり、アプリケーション（API）を本当に安全にしたい場合は、いくつかのカスタマイズを許可する必要があります。
私は自分のプロジェクトでこの2つの方法を個人的に使用しています（パフォーマンスのニーズに応じて、個別または組み合わせて）：
トークンログ。プロジェクトで発行されたすべてのトークンをID、クレーム、有効期限とともにログに記録し、リクエストごとに検証します。トークンの有効期限が切れると、このログからアーカイブに移動されます。パフォーマンスの低下はそれほどひどいものではありません。
また、ユーザー名に加えて、dboからユーザーをロードするときに次のステップで承認されるユーザーの秘密のハッシュ（自動生成された隠しトークンやパスワードなど）をクレームに追加します。とにかくユーザーのクエリが実行されるため、これによるパフォーマンスの大幅な低下はありません。欠点は、具体的なトークンを無効にできないことです。すべてのユーザーのセッションのみを無効にできます。