JWT（Json Webトークン）とカスタムトークン
私は質問を調べていましたが、疑問を解決できるものは何も見つかりませんでした。 JWTに関する広範な情報を見つけましたが、カスタムトークンの生成に対してJWTが提供できる利点を、RESTサービスに対する認証要求と比較すると、それほど多くはありません。
カスタム生成トークンを生成するよりもJWT（Json Web Token）を使用する利点は何ですか？カスタムトークンを生成するには、ハッシュ戦略または一意の乱数ジェネレーターを使用できます。
カスタムトークンを生成する場合、セキュリティ上の懸念はありますか？他の認証メカニズムを使用することをお勧めしますか？
ありがとう！
JWTトークン 件名（ログインしたユーザーなど）に関するステートメントであるクレームが含まれます。これらのステートメントには、名前、電子メール、役割などがあります。JWTトークンはデジタル署名されており、 [〜＃〜] csrf [〜＃〜] 攻撃に対して脆弱ではありません。
これらの2つの特性により、トークンを受信するサービスは、トークンの有効性を確認したり、サブジェクトに関する情報を取得したりするために、発行元の認証サーバーに戻る必要がなくなります。
これにより、JWTトークンを使用するシステムが大幅に拡張できるようになります。 JWTトークンには、安全なトランスポートチャネル（HTTPS）が必要です。
これの欠点は、トークンを取り消すことができないことです（これらのトークンを保護する中央サーバーがないため）。そのため、トークンの有効期間は通常短いです。
一方、 セッションID を保持するトークンは、認証サーバーに接続してトークンを検証し（通常はデータベースルックアップ）、サブジェクトに関する情報を取得する必要があります（別のデータベースルックアップ）。
HMACトークン の検証には、トークンの生成に使用される秘密鍵の知識が必要です。通常、受信サービス（API）は、認証サーバーに接続する必要があります。認証サーバーはシークレットが保持されている場所だからです。
HMACトークンとセッションIDは通常、Cookieに保存されます。 Cookieはクロスドメインサービス呼び出しには使用できず、CSRF攻撃から保護する必要があります。
From Django RESTフレームワークドキュメント 、
JSON Web Tokenは、トークンベースの認証に使用できるかなり新しい標準です。組み込みのTokenAuthenticationスキームとは異なり、JWT認証はトークンを検証するためにデータベースを使用する必要はありません。