3

I have an application system that developed based on IdentityServer4 and .NET Core 2.0. Just recently I noticed that log into the server will timeout in 30 minutes regardless of user activity. Client applications cannot launch other SSO enabled applications after the 30 minutes boundary. After 30 minutes, launching any new app will force user login. I looked at the cookies that might affect the SSO functionality, there are three: AspNetCore.Identity.Application, Identity.External and idsrv.session. But they are all browser session cookies. I don’t see how they would timeout. Anyone knows what’s going on?

My related settings:

  • Absolute Refresh Token Lifetime: 2592000
  • Access Token Lifetime: 3600
  • Authorization lifetime 300
  • Identity Token Lifetime: 300
jps
  • 20,041
  • 15
  • 75
  • 79
John Cheng
  • 197
  • 2
  • 8
  • 1
    I think you are being downvoted for not providing enough information. Of course it would be nice if users gave constructive criticism instead of just downvoting – mode777 Apr 07 '18 at 19:08
  • Hi John, I hope you are available at this time, I'm a beginner and I'm looking to implement SSO using identityserver in .net core application. Can you please help me on how you did this? – Saeed Gholamzadeh Jul 31 '20 at 09:26

3 Answers3

3

mode777 is right. This issue is not related to IdentityServer4 nor OpenID Connect. It's related to the AspNetCore.Identity. I find this link very helpful and solved my timeout issue by adding a line like this:

services.Configure<SecurityStampValidatorOptions>(options => options.ValidationInterval = TimeSpan.FromHours(24));

So, what happened is this: After the 30 mins default interval, a request to the server will go through the user security stamp check. For some unknown reason, the logic that checks my user security stamp think the stamp is invalid and hence calls SignInManager's SignOutAsync, which kills everything. What I still don't understand is that my user security stamp is never changed! It shouldn't cause the invalidation. For now, I will let my application works with a much longer check interval, and will keep an eye on the security stamp.

John Cheng
  • 197
  • 2
  • 8
  • 2
    I wasn't satisfied with the above solution. So, I dug into the code again. I found that the actual cause of validation failure is because I did not write the security stamp into user claims. So, there was nothing to compare with during validation. To fix it in the right way, I added this line in the Identity configuration: config.ClaimsIdentity.SecurityStampClaimType = "securityStamp"; and also added this line: new Claim("securityStamp", user.SecurityStamp), in the UserClaimsPrincipalFactory. By the way, my app uses multiple stores like AD and LDS behind. I rewrote many of the implementations. – John Cheng Apr 10 '18 at 00:38
  • Unfortunately, this does not work for me. In the current default implementation of the `UserClaimsPrincipalFactory`, security stamp is being added already based on the value from the `ClaimsIdentity.SecurityStampClaimType`. But when the token is returned, the value is being omitted for some reason. I have also tried adding the claim using `ProfileService`, and the token is returned with the security stamp but validation still fails. My only option now is to set a long `ValidationInterval` – Manvir Singh Jul 04 '19 at 08:59
  • @JohnCheng you should be careful, because IS4 uses UserClaimsPrincipalFactory to issue access token as well, and if you are not filtering claims when issuing it, security stamp would end up in the token, which is unlikely, because it is not encrypted unlike auth cookies – Alexander Goldabin Jun 11 '20 at 15:11
2

First of all this is not a Identity Server 4 or OpenID Connect related issue. This concerns the local login probably goverened by Asp.Net Identity which is probably Cookie based (It all depends on your configuration - Startup.cs would be nice).

You can configure the session timeout for Asp.Net Identity which is described here: ASP.NET Identity Session Timeout

Have you tried that?

mode777
  • 3,037
  • 2
  • 23
  • 34
1

Digging though source code I found that the cause is missing SecurityStamp claim (default name: AspNet.Identity.SecurityStamp) in auth cookie (.AspNetCore.Identity.Application). After 30 minutes (default value for options.ValidationInterval) security stamp is validated against stamp in the store. If it's missing in cookie - validation fails immediately.

So the solution would be to put security stamp in the cookie.

In my case problem was caused because I was using wrong Sign-In method: HttpContext.SignInAsync instead of build-in Asp.Net Identity SignInManager.SignInAsync which is preferable to use in most cases. SignInManager.SignInAsync puts that claim in the cookie.

Alexander Goldabin
  • 1,824
  • 15
  • 17