insight When dealing with OpenID Connect (OIDC) and OAuth authentication in a modern .NET application, Identity Server is ofted used as the identity provider. In this post, I’ll work through a common, but quite specific scenario: configuring the lifetime of a client session. In this case, the user of an ASP.NET MVC Client must be logged out of the session after 15 minutes of inactivity. In such a setup, there are a lot of places where you can configure time-outs, lifetimes, expirations etc.
Setup
In this scenario, we have three applications:rnu003culu003ern tu003cliu003eAn ASP.NET MVC web application (the u003cemu003eClientu003c/emu003e, in Identity Server terminology)u003c/liu003ern tu003cliu003eA Web API (a u003cemu003eResourceu003c/emu003e)u003c/liu003ern tu003cliu003eIdentity Server (the u003cemu003eIdentity Provideru003c/emu003e)u003c/liu003ernu003c/ulu003ernSome pages in the Client application require authentication, because they display data from the API. This API is protected, so the Client need to send a valid Access Token to get access to the APIs data. Identity Server is used as the u003cemu003eIdentity Provideru003c/emu003e. So far, a pretty standard setup.
The required behavior: a sliding session that expires after inactivity
For this scenario, let’s consider the following requirements:rnu003colu003ern tu003cliu003eUsers must log in to access the protected pages in the MVC client.u003c/liu003ern tu003cliu003eAs long as the user is active on the site, the session remains valid (i.e. we have a u003cemu003esliding sessionu003c/emu003e, it won’t expire as long as the user keeps using the client).u003c/liu003ern tu003cliu003eWhen the user is inactive for 15 minutes, the session will expire. Any attempt to visit the protected pages after that time should fail and the user should be redirected to the login screen.u003c/liu003ern tu003cliu003eWhen the user closes the browser, the session should be destroyed.u003c/liu003ernu003c/olu003ernWe’ll implement these requirements one at a time.
1. Getting the authentication to work using the hybrid flow
The first requirement is the easiest to implement. If you simply follow the quickstart tutorials in the Identity Server documentation, this is where you’ll end up. The MVC client now uses the OpenID Connect Hybrid flow to obtain the access token that it needs.rnrnWhen you have implemented the quickstart scenario, note that there are certain things that we have u003cemu003enotu003c/emu003e configured explicitly: how long is this access token valid? What happens when the token expires? How long can the user keep using the client before he needs to re-authenticate or re-login? All of this u003cemu003eisu003c/emu003e configured of course, but all using default settings of both Identity Server and the OIDC middleware that the client uses. We’ll make some of this configuration explicit when we look at the other requirements.
Conclusion
As it turned out, we hardly had to deal with Identity Server at all to meet the requirements for the user sessions. And let that be the main take-away from this post: that user session management and Identity Server configuration are two mostly unrelated subjects. Knowing the distinction makes it much easier to navigate your way through all the available configuration options.