2016-04-14 9 views
0

MEANアプリケーションの認証のトークンベースのアーキテクチャが安全であるという議論が多くあります。しかし、JSON Webトークンでペイロードとしての認証と認証のためのユーザー名とパスワードが本当に渡されているのか、ペイロードに安全な情報を渡していない場合、JSON Webトークンがユーザー名/側。Json Web Tokenでユーザー名/パスワードなどの安全なデータを渡すには?

私はアーキテクチャのものをたくさん読んでいますが、ユーザー名/パスワードを使用せずにトークンを認証するためにどのロジックを使用したのか説明できません。

認証トークンをウェブストレージではなくクッキーに保存することは有効ですか?

はい私は彼らが検証のために秘密鍵と公開鍵を使用したことを知っていますが、認証には不十分です。特定のユーザーを認証するには、ユーザー名/パスワードや特定のユーザーを識別するために必要なキーアクセスなど、いくつかのキー値が必要です。

答えて

4

いいえ、JWTでパスワードを送信するのは安全ではありません。これは、JWTの主張は単純にエンコードされているため、誰でも簡単にデコードできます。ユーザーに返されたJWTに機密情報を格納することは安全ではありません。

あなたはJWTのロールイン認証を誤解しているようです。一般的に、JWT認証はステートフルなセッションシステムを置き換えます。多くの通常のフローでは、ユーザーはユーザー名とパスワードを使用して認証し、サーバーはそのユーザーのセッションCookieを設定します。ユーザーがWebサイトに戻ると、ブラウザはセッションCookieを一緒に送信します。サーバーは、セッションクッキーを使用してリクエストを受信し、データベースから関連するセッションデータを検索します。

多くのJWTベースのシステムでは、ユーザーは通常どおりユーザー名とパスワードで認証しますが、認証サーバーがデータベース内の何かを参照するセッションCookieを設定するのではなく、そのJWTのJWTを含むCookieを設定します。ユーザーのセッションデータこれには、ユーザー名、所有している役割、または必要なその他のデータが含まれます。

ユーザーがWebサイトに戻ってブラウザにこの新しいJWT Cookieが提示されると、サーバーはクレームを信頼するために認可サーバーによって署名されていることを確認する必要があります。セッション情報のデータベースルックアップを避けることは、多くの利点をもたらします。

+0

ありがとうございました。つまり、JWTはサーバー側でいくつかの種類のセッションデータベースを管理しています。トークンの有効期限と検証を検証するサーバー側のJWTトークンの参照を使用します。したがって、MEANアプリケーションでは、express-jwtモジュールを使用すると、JWTトークンを格納および管理するための新しいセッションMongoDBコレクションを作成しますか? –

+1

これは確かに可能ですが、多くの人がセッションデータを直接JWTに保存し、サーバー側のセッションを完全に置き換えます。 JWTを使用してデータベース内のセッションをルックアップする場合、なぜJWTを使用していますか? –

+0

JWTのプロセスの流れについて、どのように役立ち、どのように機能するのか、本当に混乱しています。私は非常に多くの図やブログを参照しましたが、JWTがどのように役立っていて、どのように適切に機能するのかという答えを得ることができませんでしたか?私はJWTの一般的なプロセスをよく知っていますが、秘密とペイロードを持つJWTリフレッシュトークンは同じですか? JWTは本当に私のために内部プロセスを理解するのに時間がかかります。そして、大きな疑問は、それがどのようにトークンを認証するのか、私はそれを非常に多くのブログで読んでいますが、それでも私にとっては抽象的だということです。 –

関連する問題