CODEWITHSUNDEEP
sessionopenid-connectsession-management
iepure
iepure

Reputation: 257

How to keep track of whether a user with an access token still has a valid session?

I'm new to OIDC and session management in general, and was wondering what would be recommended way to make sure a user's session is valid after they've already logged in to a site using implicit flow or authorization code flow.

For example, let's say a user logs in to mysite.com and gains an access token in the process. The token could be saved e.g. in an HTTP only cookie.

Should mysite.com poll the OpenId provider (OP) to check the user's session status every time they make a request to a protected resource (even if that resource isn't retrieved from the OP) to make sure the user hasn't e.g. modified the access token cookie manually? Or should mysite.com just blindly trust the user's token cookies after a successful OIDC authentication?

I guess one possibility would be to store a user's session status to a DB, but that seems like a rather heavy solution to a simple problem.

Any advice on best practices?

Upvotes: 1

Views: 846

Answers (1)

Alexandre Fenyo
Alexandre Fenyo

Reputation: 4809

Best practices are described in the OpenID Connect Session Management 1.0 draft specification.

First, you need to avoid generating too much network traffic between the end user device and the OP. This is particularly important for mobile devices. So, instead of repeating the authentication request, the draft specification gives a better way to pool the status of the end user session with the OP: inserting an hidden iframe to the OP, in the web page of your service. This way, this OP iframe will maintain a session to the OP by means of a session cookie, without needing to authenticate the user. Therefore, you can poll this iframe using cross iframe messages, to regularly check that the session to the OP is active. This way, there will not be any authentication flow to check that the session to the OP is active.

You will find other tricks in the draft specification, for instance using the expiration date in the ID Token from the OP.

As said in the spec, it is entirely possible that the End-User might have logged out of the OP before the expiration date. Therefore, it is highly desirable to be able to find out the login status of the End-User at the OP. This is the best practice. But many SP do not check the end user session status with the OP. They only manage their own session, that is removed after some inactivity period, for instance. When such an event occurs, they forward the end user to the authentication entry point at the OP, to initiate a new authenticated session.

Many SP do not choose to close the session with the SP when the session with the OP has been shutdown. From the OP point of view, the session with the OP may last long not to help SPs maintain their sessions, but to avoid the end user to authenticate again when he connects to another SP. This is particularly important when a group of SP work together to provide a seamless user experience, in which the user is transparently redirected from one SP to another.

Upvotes: 1

Related Questions