web-dev-qa-db-ja.com

IdentityServer4アクセストークンの有効期間

IdentityServer4を使用していますが、その構成はデータベースにあります。クライアント（oidc）にサイレント更新があります。クライアントに次のライフタイム設定を設定しました。

AbsoluteRefreshTokenLifetime =  60 * 30,//30 mins
AccessTokenLifetime = 60 * 5,//5 mins
SlidingRefreshTokenLifetime = 60 * 15 // 15 mins

どうなりますか？トークンの有効期間はどのくらいですか？ユーザーにいつ再度ログインするように求める必要がありますか？トークンが更新されたとき、および有効期限が切れたときのトークンの有効期間に関する明確なドキュメントはありません。

access-tokenidentityserver4
5
The Eagle

アクセストークンには、自己完結型と参照型の2種類があります。

JWTトークンは、自己完結型のアクセストークンです。これは、クレームと有効期限を持つ保護されたデータ構造です。 APIがキーマテリアルについて学習すると、発行者と通信する必要なく、自己完結型トークンを検証できます。これにより、JWTを取り消すことが難しくなります。有効期限が切れるまで有効です。

From http://docs.identityserver.io/en/latest/topics/reference_tokens.html#reference-tokens から

更新トークンを使用すると、APIに長期間アクセスできます。

通常、アクセストークンの有効期間を可能な限り短くする必要がありますが、同時に、IdentityServerへのフロントチャネルラウンドトリップを行って新しいものを要求することでユーザーを何度も煩わせたくありません。

更新トークンを使用すると、ユーザーの操作なしで新しいアクセストークンを要求できます。クライアントがトークンを更新するたびに、IdentityServerに対して（認証された）バックチャネル呼び出しを行う必要があります。これにより、更新トークンがまだ有効であるか、それとも取り消されているかを確認できます。

http://docs.identityserver.io/en/latest/topics/grant_types.html#refresh-tokens から

したがって、アクセストークンは自己完結型であり、変更できません。発行されたトークンは、期限が切れるまで有効です。そのため、有効期間が短いトークンを使用する必要があります。

アクセストークンの更新プロセスを自動化するには、更新トークンを使用できます。これは、ユーザーの介入なしにアクセストークンを要求するために使用できるため、強力なトークンです。更新トークンは有効期間が長い（少なくともアクセストークンよりも長い）必要があります。

更新トークンの有効期限が切れると、ユーザーは再度ログインする必要があります。スライド式の有効期限がなければ、リフレッシュトークンは絶対時間で期限切れになり、ユーザーは再度ログインする必要があります。

スライド式の有効期限を使用すると、更新トークンの有効期間を短く設定できます。アクセストークンが要求されるたびに、新しい更新トークンが発行されます。ライフタイムを延長し、使用された更新トークンを無効にします。

ユーザーは、更新トークンが有効である限り、再度ログインすることなくリソースにアクセスできます。あなたのケースでは、ユーザーが30分以上非アクティブである場合、それは期限切れになります。

アクセストークンは自動的に更新されません。新しいアクセストークンをリクエストするには、クライアントにコードを追加する必要があります。更新トークンが使用できないか期限切れの場合は、ユーザーをログインページに送ることができます。

13
Ruard van Elburg

私の理解によれば、AbsoluteRefreshTokenLifetimeとSlidingRefreshTokenLifetimeは、oidcクライアントに設定する必要があるImplicitフローには適用されません。

http://docs.identityserver.io/en/release/topics/refresh_tokens.html

アクセストークンには有効期限があるため、更新トークンを使用すると、ユーザーの操作なしで新しいアクセストークンをリクエストできます。

更新トークンは、認証コード、ハイブリッドおよびリソース所有者のパスワード資格情報フローでサポートされています。クライアントは、AllowOfflineAccessをtrueに設定して、更新トークンを要求することを明示的に承認する必要があります

同様の状況が発生し、テストのためにCookieを15分に設定し、有効期限をスライドさせています。以下の問題のスレッドごとに、サイレント更新を使用する場合は手動で処理する必要があるようです。

https://github.com/IdentityModel/oidc-client-js/issues/402

私はJavaScriptクライアントを初めて使用するので、ユーザーが存在するかどうかをどのように判断するかをまだ理解しようとしています。私はcookieがこれを処理してくれることを期待していましたが、送信したスレッドごとに拡張され続けるようです。

更新

テストとグーグルのトンの後、アクセストークンの有効期間とサイレント更新に関して私が作業/理解できるようになったのはここです。

最初に、あなたがoidc-clientまたはredux-oidcを使用していると想定しています。私は、oidc-clientの単なるラッパーであるredux-oidcを使用しています。

アクセストークンの有効期間（AccessTokenLifetime）を5分に設定していて、サイレント更新がtrueになっているためです。これは、2.5分ごとに更新されるか、userManager.accessTokenExpiringNotificationTimeが何に設定されているかに応じて更新されます。その時点で、Cookieの有効期限タイムアウトの設定に応じて、アクセストークンが更新されます。クッキーは魔法が起こる場所です。 Cookieの有効期限が切れると、アクセストークンを更新できなくなります。 Cookieは次のように設定されます。

  • Identity Server start.cs（これにより、Cookieのスライド有効期限が設定されます）：

    var builder = services.AddIdentityServer（options => {options.Authentication.CookieSlidingExpiration = true;}）

  • Identity Server AccountController.cs、ログインメソッド（機能を覚えている場合は、IsPersistent値、tsConfigValue = 15を変更できます）：

    var props = new AuthenticationProperties {IsPersistent = false、ExpiresUtc = DateTimeOffset.UtcNow.Add（TimeSpan.FromMinutes（tsConfigValue））};

これで、アクセストークンの有効期間とサイレント更新に関する私の問題が解決しました。それが役に立てば幸い。

4
user1015196