JSON Web Token（JWT）は、データベースセッショントークンよりも優れています
データベースセッショントークンシステムを使用すると、ユーザー名/パスワードを使用してユーザーログインでき、サーバーはトークン（たとえば、uuid）を生成してデータベースに格納し、そのトークンをクライアントに返すことができます。そこからのすべてのリクエストにはトークンが含まれ、サーバーはトークンが有効かどうか、およびトークンがどのユーザーに属しているかを検索します。
JWTを使用すると、サーバー上に保持される秘密鍵と、クライアントがすべてのリクエストで保持および送信する署名付きトークンの組み合わせにより、セッション/トークンに関してデータベースに何も保存する必要がなくなります。
これは良いことですが、各リクエストをデータベースに保存するだけでなく（ハッシュテーブルをチェックするだけなので高速になります）、JWTを使用することの利点がわかりません。これに詳しい人は説明できますか？ Cookieを無視しましょう。具体的には、前述のデータベースカスタムトークンとJWTを比較して、メリットを理解しようとしています。
主な違いは、サーバーに必要なセッションストレージサイズと検索作業です。
サーバー側では、JWTは単一キーをメモリ（または構成ファイル）に保存します-secret keyと呼ばれます。このキーには2つの目的があり、新しい暗号化されたトークンの作成を可能にし、「すべてのロックを開く」マスターキーのように機能します。または、実際にはすべてのトークンを検証します。その結果、200万または200万のユーザーがログインしているかどうかは関係ないため、サーバーは認証要求に対してはるかに高速に応答します。同じ数のレコード（1つ、そのサーバーキー）がすべてのクライアント要求の認証に使用されます。
データベースにユーザーセッションを保存する従来の認証は、すべてのユーザーごとにdbにレコードを作成します。その結果、複数キーになります。したがって、200万人のユーザーがログインしている場合、サーバーは200万件のレコードを作成し、各クライアント要求でサーバーはデータベース内の関連するセッションレコードを見つける必要があります*。
JWTは、セッション/ユーザーオブジェクト全体を格納および処理するために、クライアント側に任せます。すべてのクライアントが自分のデータのみを処理するため、実際にははるかに理にかなっています。そのため、クライアント側にも負担がかかりません。
最後の段落で書いたことは、ここで保存するのはdb呼び出しだけではありません。 JWTは実際にははるかに多くスケーラブル独立した軽量の性質のため、認証要求が蓄積するので失敗せず、サーバー側でセッションを管理することなくサーバーがデバイスとサービス全体で認証を処理できるようにします。
ただし、セキュリティに関しては、dbセッションは間違いなく優位です。これらのレイテンシはより安全である可能性があり、ユーザーの後のセッションハイジャックに対しても脆弱ではありませんログアウト。
* db stored sessionsメソッドは、効果的なキャッシングと、Redisなどの高速キー/値サーバーに（ユーザーオブジェクト全体ではなく）セッションIDのみを格納することで最適化できます。ただし、ほとんどの場合、dbよりもJWTメソッドを選択します。
Jsonベースのトークン（JWT）は、次の問題を克服します。
- モバイルの問題：ネイティブモバイルアプリにはCookieの処理に問題があるように見えるため、リモートAPIを照会する必要がある場合、セッション認証は最適なソリューションではない可能性があります。
- CSRFの問題：Cookieの方法に従っている場合は、クロスサイトリクエストを回避するためにCSRFが必要です。
ただし、JWTはセッションを使用せず、モバイルに問題はありません。CSRFは必要なく、CORSでも非常にうまく機能します。有効なトークンがない場合は、何もできません。
このトークンはクライアントのローカルストレージ/セッションストレージに保存されるため、これらのトークンを他のクライアントにも渡すことができますが、このJWTの生成に使用したのと同じ資格情報を共有する必要があります。