MEAN アプリケーションの認証のトークン ベースのアーキテクチャが安全であることについては、多くの議論と支持があります。しかし、JSON Web トークンのペイロードとして承認と認証のためにユーザー名とパスワードを本当に渡すのか、ペイロードで保護された情報を渡さない場合、JSON Web トークンがサーバーでユーザー名/パスワードなしでユーザーを認証する方法について疑問があります。側。
私は多くのアーキテクチャに関するものを読みましたが、ユーザー名/パスワードを使用せずにトークンを認証するために使用したロジックを説明できません。
Web ストレージではなく Cookie に認証トークンを保存することは有効ですか?
はい、検証に秘密鍵と公開鍵を使用したことは知っていますが、認証には不十分です。特定のユーザーを認証するには、ユーザー名/パスワードなどのいくつかのキー値、または特定のユーザーを識別するために必要なキー アクセスが必要です。
いいえ、JWT でパスワードを送信するのは安全ではありません。これは、JWT クレームが単純にエンコードされており、誰でも簡単にデコードできるためです。ユーザーに返された JWT に機密情報を格納することは安全ではありません。
認証における JWT の役割を誤解しているようです。一般に、JWT 認証はステートフル セッション システムに取って代わります。多くの通常のフローでは、ユーザーはユーザー名とパスワードを使用して認証し、サーバーはユーザーのセッション Cookie を設定します。ユーザーが Web サイトに戻ると、ブラウザはセッション Cookie を一緒に送信します。サーバーは、セッション Cookie を含むリクエストを受信し、データベースから関連するセッション データを検索します。
多くの JWT ベースのシステムでは、ユーザーは通常どおりユーザー名とパスワードで認証されますが、承認サーバーがデータベース内の何かを参照するセッション Cookie を設定する代わりに、ユーザーのセッション データの JWT を含む Cookie を設定します。これには、ユーザー名、役割、またはその他の必要なデータが含まれる場合があります。
これで、ユーザーが Web サイトに戻り、ブラウザーがこの新しい JWT cookie を提示したときに、サーバーは内部のクレームを信頼するために承認サーバーによって署名されたことを確認するだけで済みます。セッション情報のデータベース ルックアップを回避することには多くのメリットがありますが、そのメリットの 1 つが速度です。