問題タブ [http-token-authentication]

トークンベースの認証はこのように機能します

トークンベースの認証システムの背後にある一般的な概念は単純です。ユーザー名とパスワードを使用せずに、特定のリソースをフェッチできるトークンを取得するために、ユーザーがユーザー名とパスワードを入力できるようにします。トークンが取得されると、ユーザーはそのトークン (特定のリソースへの一定期間のアクセスを提供する) をリモート サイトに提供できます。

サーバーがトークンをクライアントに発行すると、途中でハッカーがそのトークンを盗み、有効なクライアントとしてサーバーの前に現れる可能性があるため、これが安全であると見なされる方法。盗難証明トークンの生成方法を教えてください。

仲介者がハッキングできないように、サーバーとクライアントの間でトークンをやり取りする非常に安全な方法について説明します。

私のアプリケーションでは、ユーザーを登録しているときに、ユーザー名、パスワード、および jwt で生成されたトークンを MONGO DB のこれらのフィールドに保存しています。ユーザーが正しい資格情報でログインしようとすると、保存されたトークンで応答を送信します。コントローラー) クライアントから送信されたすべての要求に対して同じトークンを送信できるように、localstorage を使用してトークンを格納しています。しかし、この手順に関していくつかの問題が見つかりました。

1. 毎回1人のユーザーに対して同じトークンを生成しています。したがって、第三者がトークンを取得できれば、制限されたページにアクセスできます。
2. 生成されたトークンをMONGODBに保存することで、dbのスペースを無駄にしていますか?
3. ユーザー以外の誰でも localstorage に格納されたトークンにアクセスできますか?
4. シングルページアプリケーションのすべてのリクエストに対して、再びmongodbにクエリを実行してそのユーザーのトークンを取得し、検証しています.ここでは、クライアント側とサーバー側の両方をチェックしています.

jwt を使用して、アプリケーションでトークン、Node、Express、Mongoose を生成しています

私は適切な手順に従っていますか。そうでない場合は、私のアプローチまたは新しいアプローチの解決策を提供してください。トークンベースの認証とセッションベースの認証について多くのサイトを検索しましたが、何もうまくいきませんでした。注：私はNodejs、AngularjSの初心者です

django rest framework Docsに従ってトークン認証を実装しました。

私が読んだ形では、DRF のトークン認証は非常に単純です。ユーザーごとに 1 つのトークンであり、トークンは期限切れにならず、常に有効です (私は正しいですか? )。

より良いプラクティスがあることは理解していますが、今のところ、DRF トークン認証で問題ありません。

私の質問は、通常の DRF トークン認証でログアウトするためのベスト プラクティスは何ですか?

つまり、ユーザーがログアウトしたときに、クライアント側からトークンを削除する必要がありますか? ログイン時にトークンを再度取得しますか？トークンを削除して新しいトークンを生成する必要がありますか?

これを経験した人はいますか？

OWIN ミドルウェアを使用して Web Api トークン ベースの認証を使用しています。トークンは正常に生成されましたが、デコードできません。たとえば、そこからユーザー名とパスワードを抽出できません。これが私の構成であり、私の起動コードです

トークンを送信するために使用される私のコードは

私の認証コード

and the code failed when trying to decode the code from base64 string note:- my sample token is 3K8vHKHA2ZsKfKbvzUbo4a2sat2JLzvvyxCZ0KSD6s1wUS3t3oDPXuQ89aTmGpsG4ZL8O0cr8M9EUeZGtdM6FBwR7gLFcLZkTaimFGKyyZMNce9trQavVTzs6gam6qach1rPTLv_gIYGgPmM-401PZsr89BIXw4acTpJL3KbXs8y7PQ-o-eTV2IA8euCVkqC02iEnAzmS0SwhBouISCC-HvcNpE2aNixg4JXEt8EslU you can see the attached for the exception

JWT でのリフレッシュ トークンの使用について説明している別の SO 投稿を参照しています。

JWT（JSON Web Token）の自動有効期限延長

クライアント (Web およびモバイル) が REST API と対話し、サービス層とデータ層と対話する、非常に一般的なアーキテクチャのアプリケーションがあります。

JWT トークン認証については理解していますが、リフレッシュ トークンの使用方法について少し混乱しています。

JWT 認証に次のプロパティを持たせたい:

1. JWT トークンの有効期限は 2 時間です。

2. トークンは、クライアントによって 1 時間ごとに更新されます。

3. ユーザー トークンが更新されず (ユーザーが非アクティブで、アプリが開いていない)、有効期限が切れた場合、再開するたびにログインする必要があります。

リフレッシュ トークンの概念を使用してこれをより良いエクスペリエンスにすると主張する人がたくさんいますが、これの利点はわかりません。それを管理しなければならないのは、追加の複雑さのようです。

私の質問は次のとおりです。

1. リフレッシュ トークンを使用する場合、そのトークンの有効期限を長期に設定することは有益ではないでしょうか?
2. リフレッシュ トークンを使用する場合、そのトークンは userId および/または JWT トークンと共に永続化されますか?
3. トークンを 1 時間ごとに更新すると、どのように機能しますか? JWT トークンまたはリフレッシュ トークンを受け取るエンドポイントを作成しますか? これにより、元の JWT トークンの有効期限が更新されますか、それとも新しいトークンが作成されますか?
4. これらの詳細を考えると、更新トークンは必要ですか? ユーザーが JWT トークンを使用して新しいトークンを取得しているだけの場合 (上記のリンクに従って)、更新トークンは廃止されているようです。