5

私はトークンベースの認証を構築しています(Angularクライアントでパスポート/JWTを使用するNode.js)。

ユーザーが資格情報を入力すると、アクセス トークンが取得され、ヘッダー内のすべての要求で送信されます (header: bearer TOKEN)。

彼のアクセストークンの有効期限が切れるたびに（ほぼ毎日だと思いますが）ログインリクエストを要求したくありません。 Refresh Tokensについて聞いたことがあります。更新トークンは期限切れになることはなく (またはめったに期限切れにならない)、無期限にトークンを更新できます。アクセス トークンの期限が切れそうになると、クライアントは更新要求を送信して、更新トークンを送信することで新しいアクセス トークンを取得できます。

私はいくつかのことを理解していません。何かが欠けている可能性があります:

  1. 有効期間が長い/無期限のリフレッシュ トークンが、有効期間が短いアクセス トークンのセキュリティを損なわない方法。

  2. Cookie は盗まれ、有効期限が切れるまで使用される可能性があります。トークンは存続期間が短いため、より安全ですが、存続期間が長い更新トークンを提供すると、トークンを使用する利点が失われます。

注: リフレッシュ トークンは最初のログイン時に送信されるため、すべてのリクエストでスプーフィングできないことは認識していますが、最初のリクエストでスプーフィングされている場合は脆弱です。

4

2 に答える 2

4

リフレッシュ トークンはアクセス トークンとは異なるパスで提示されます。アクセス トークンはリソース サーバーにのみ提示され、リフレッシュ トークンは認可サーバーにのみ提示されます。アクセストークンは自己完結型であるため、その有効性を確認するために認可サーバーへのコストのかかる呼び出しは必要ありませんが、損失を軽減し、精度を高めるために (何か問題が発生した場合に取り消すことはできません)、有効期間は短くなっています。更新トークンは長期間有効であり、認可サーバーへの呼び出しごとに検証されるため、取り消すことができます。この 2 つの組み合わせにより、システムは安全になります。

于 2014-12-08T13:50:48.940 に答える
0

私は次のアプローチを使用します。

テーブル/インデックス:

  1. ユーザー テーブル (ユーザー ID とすべてのユーザー関連のメタデータのみを含む)
  2. JWT テーブル (3 つのフィールド: user_id、access_token、refresh_token)

認証の流れ

1.以前に認証されていないユーザーがサインインすると、アクセス トークンと更新トークンを含む JWT が発行されます。user_id およびアクセス トークンと共に、JWT テーブルの更新トークンを更新します。

2. JWT の有効期限が、ユーザーにとって小さい/快適なものであることを確認してください。通常は 1 時間以内です。

4.クライアントがJWTでリクエストを行う場合

を。アクセス トークンの有効期限を確認します。トークンの有効期限が切れていない場合 -> db テーブルにアクセスせずに続行します。

b. アクセス トークンの有効期限が切れている場合は、JWT テーブルで user_id を検索し、更新トークンとアクセス トークンが一致するかどうか (クライアントが提供したものは何でも) を確認します。

はいの場合は、応答を含む新しい JWT を発行し、新しい更新トークン、アクセス トークンを JWT テーブルに更新します。

いいえの場合は、401 を返します。クライアントは、ユーザーにサインインを求めることを強制されます。

終わり。

要約する、

1.DB 呼び出しは、更新トークンが有効かどうかを確認するためだけに必要です。

2.このシステムでは、ユーザーは、任意の数の JWT を使用して、任意の数のデバイスからサインインできます。

3. ユーザーに関連するすべての JWT は、JWT テーブルからそのユーザーに関連するリフレッシュ トークンをワイプすることで無効にすることができます。たとえば、ユーザーが自分のパスワードを変更した場合などです。これにより、事実上、アクセス トークン/JWT の有効期限が切れるまでの時間枠が狭められます。

これがJWTの背後にある意図だと思います。DB 呼び出し/ユーザーの割合は、有効期限、ユーザーが通常 Web サイトに滞在している時間などによって異なります。

于 2020-08-16T11:21:07.487 に答える