回答:
JWTは、言うまでもなく「セッション」を使用するよりもメリットがありません。JWTは、サーバーでセッション状態を維持する代わりに、クライアントでセッション状態を維持する手段を提供します。
よく聞かれるのは、「サーバー側のセッションを使用するよりもJWTを使用する利点は何ですか」です。
サーバー側セッションでは、セッション識別子をデータベースに保存するか、それをメモリに保持して、クライアントが常に同じサーバーにアクセスするようにする必要があります。これらの両方に欠点があります。データベース（または他の集中型ストレージ）の場合、これはボトルネックになり、維持する必要があります。基本的に、すべてのリクエストで実行される追加のクエリです。
インメモリソリューションを使用すると、水平スケーリングが制限され、セッションはネットワークの問題（Wifiとモバイルデータの間のローミング、サーバーの再起動など）の影響を受けます
セッションをクライアントに移動するということは、サーバー側セッションへの依存関係を削除することを意味しますが、独自の課題を課します。
これらの問題は、JWTや他のクライアント側のセッションメカニズムでも共有されます。
特にJWTはこれらの最後の問題に対処します。JWTとは何かを理解するのに役立つ場合があります。
それは少しの情報です。ユーザーセッションの場合、ユーザー名とトークンの有効期限を含めることができます。ただし、セッションIDやユーザーのプロファイル全体など、何でもかまいません。（ただし、これは行わないでください）悪意のある者が偽のトークンを生成するのを防ぐ安全な署名があります（署名するにはサーバーの秘密鍵にアクセスする必要があり、署名後に変更されていないことを確認できます）。 CookieまたはAuthorizationヘッダーが送信されるのと同じように、すべてのリクエストでそれらを送信します。実際、これらは通常HTTP Authorizationヘッダーで送信されますが、Cookieを使用することもできます。
トークンは署名されているため、サーバーはその出所を確認できます。サーバーは、安全に署名する独自の機能を信頼していると想定します（標準ライブラリを使用する必要があります。自分で署名しようとせず、サーバーを適切に保護してください）。
トークンを安全に転送することに関する問題の答えは通常、暗号化されたチャネル（通常はhttpS）を介してトークンを送信することです。
トークンをクライアントに安全に格納することに関しては、悪意のある人がトークンを入手できないようにする必要があります。これは、（ほとんどの場合）悪質なWebサイトからのJSがトークンを読み取ってトークンを送り返すのを防ぐことを意味します。これは、他の種類のXSS攻撃を軽減するために使用されるのと同じ戦略を使用して軽減されます。
JWTを無効にする必要がある場合は、確実にこれを実現する方法があります。「他のセッションを終了する」ことを要求したユーザーのみのユーザーごとのエポックを保存することは、おそらく十分に優れた非常に効率的な方法です。アプリケーションがセッションごとの無効化を必要とする場合、セッションIDは同じ方法で維持でき、 "killed tokens"テーブルは完全なユーザーテーブルよりもはるかに小さく維持できます（必要なのは、許可されたトークンの最長存続期間。）したがって、トークンを無効にする機能は、このセッションの強制終了状態を維持する必要があるという点で、クライアント側セッションの利点を部分的に無効にします。これは、元のセッション状態テーブルよりもはるかに小さいテーブルである可能性が高いため、ルックアップはさらに効率的です。
JWTトークンを使用するもう1つの利点は、おそらくそれが期待できるすべての言語で利用可能なライブラリを使用して実装するのがかなり簡単であることです。また、最初のユーザー認証スキームとは完全に分離されています。指紋ベースのシステムに移行した場合は、セッション管理スキームに変更を加える必要はありません。
より微妙な利点：JWTは「情報」を運ぶことができ、クライアントがこれにアクセスできるため、いくつかのスマートなことを開始できます。たとえば、ログアウトの数日前にセッションが期限切れになることをユーザーに通知し、トークンの有効期限に基づいて再認証するオプションをユーザーに提供します。想像できることなら何でも。
つまり、JWTは他のセッションテクニックのいくつかの質問と欠点に答えます。
JWTは、安全なストレージやトランスポートなどの他の問題には対応していませんが、新しいセキュリティの問題はありません。
JWTには多くの否定的な点がありますが、他の種類の認証と同じセキュリティを実装すれば問題ありません。
最後の注意点：Cookieとトークンではありません。Cookieは、情報のビットを格納および転送するためのメカニズムであり、JWTトークンの格納および転送にも使用できます。
短い答えは次のとおりです。なし。
より長いバージョンは：
GraphQLドキュメントでこの推奨事項を読んだ後、セッション管理用のJWTを実装しました。
これらの認証メカニズムに慣れていない場合は、将来の柔軟性を犠牲にすることなくシンプルであるため、express-jwtの使用をお勧めします。
実装はほんの少しの複雑さを追加しただけなので、確かにシンプルでした。しかししばらくして、私（あなたのような）は何の利点があるのか疑問に思い始めました。このブログの投稿で詳細に説明されているように、セッション管理に関する限り、JWTの数はほとんどない（またはおそらくない）ことがわかります。
私の2セントは、途中でjoepie91の有名なブログ投稿と対照的です。
それを考えると、今日の（そして明日の）アプリケーションは、（主に）されているネイティブのクラウド
への経済的利益がありますステートレスJWT認証は、どのアプリケーションのスケールとしてスケール：
1で引き分け、すべての息と一緒にコスト負担クラウドアプリケーション。
ユーザーがセッションストアに対して「反対に」認証する必要がなくなると、このコストは削減されます。
処理
セッションストアを24時間年中無休で実行するには、費用がかかります。
ポッドは一時的なものであるため、K8Sの世界ではメモリベースのソリューションを利用できません。
スティッキーセッションは、まったく同じ理由でうまく機能しません。
ストレージ
データの保存にはコストがかかります。SSDへのデータの保存にはさらにコストがかかります。
セッション関連の操作は迅速に解決する必要があるため、光学ドライブはオプションではありません。
I / O
一部のクラウドプロバイダーは、ディスク関連のI / Oに料金を請求しています。
帯域幅
一部のクラウドプロバイダーは、サーバーインスタンス間のネットワークアクティビティに対して課金します。
APIとセッションストアが別々のインスタンスであることがほぼ確実であるため、これが当てはまります。
セッションストア
のクラスタリングコストは、前述のすべてのコストをさらに増大させます。
ユーザー認証のためにJWTとトークン+キャッシュのどちらかを選択する同様の質問がありました。
これらの記事を読んだ後、JWTが約束する利点がJWTがもたらす問題を追い越さないことは私には明らかです。したがって、token + cache（Redis / Memcached）が私にとっての道です。