So I have a Blazor server-side app that authenticates with a provider to get the access and refresh tokens. The authentication ticket is stored in a SQL Server database based on a distributed cache implementation of ITicketStore. And the cookie itself is saved in the browser's session storage.
The app resides in IIS and it's application pool is recycled every 24 hours.
The ticket store is set up as follows:
services.AddSingleton<ITicketStore, CookieDistributedTicketStore>();services.AddOptions<CookieAuthenticationOptions>(CookieAuthenticationDefaults.AuthenticationScheme) .Configure<ITicketStore>((options, store) => { options.ExpireTimeSpan = TimeSpan.FromDays(14); options.SlidingExpiration = true; options.SessionStore = store; });Any when setting the ticket in the store, these are the cache entry options:
var expiresUtc = ticket.Properties.ExpiresUtc;if (expiresUtc.HasValue){ options.SetAbsoluteExpiration(expiresUtc.Value);}if (ticket.Properties.AllowRefresh ?? false){ options.SetSlidingExpiration(TimeSpan.FromMinutes(60));}The challenge request is simply:
await HttpContext.ChallengeAsync(OpenIdConnectDefaults.AuthenticationScheme, new AuthenticationProperties { RedirectUri = redirectUri, });Every piece of information has its own lifetime and I can't fully understand how they all work together.
- The access token has a lifetime of 14 days and the refresh token 60 minutes.
- The authentication ticket has an absolute lifetime of 14 days and a sliding of 60 minutes.
- The cookie lasts as long as the session.
- The app recycles every 24 hours.
Are these reasonable lifetimes? Do they work well together or should I use other values?