Two things that make logging out hard

When building a web service, logging out is often an afterthought. When you finally get to it, it turns out to be complicated.

As a user, you have a couple of reasons to log out from a web service:

• You want to switch to another account.
• You want to prevent anyone else (or even yourself) from accessing your account using the same device.

We now have multiple devices and the services can be used with browsers and native apps. Sometimes you want to log out of the other devices, for example if your phone gets lost or stolen. The service administrator may log out all your devices if they detect that your account has been compromised¹.

In a traditional Web 2.0 architecture, the active sessions are stored in a database. The user gets a HTTP cookie with the session ID and every request is checked against the database to see if the session is still active and to whom it belongs. Implementing log out is straightforward: delete the user’s session from the database and the user is logged out.

Contemporary web services and single-page applications come with two things that complicate the situation:

Single sign-on (SSO). You have logged in to multiple services using the same credentials. Now you click the log out button in one of the services. What happens? Do you get logged out from that service or all the services? On that device or on all the devices? Does the answer depend on whether the single sign-on provider is run by the same organization as the service or by a third party?

I’ve discussed this question with developers, designers, and product managers and I’ve learned that very reasonable people disagree about it. It depends.

Stateless sessions. Instead of storing sessions in a database, you can use a signed (and possibly encrypted) cookie or a token. As long as the user’s requests include a valid token, they’re logged in. There’s no server-side state associated with the session, hence the name.

In this design, logging out means forgetting the session token. You can unset the cookie and delete the tokens from applications’ storage. The security people do not like this, because the token stays valid even if the user has nominally logged out. Having a short expiration time helps, but then you have to figure out how to periodically get fresh tokens. Logging out other devices is impossible without re-introducing server-side state.

In conclusion. If you’re looking to implement a SSO system or stateless session architecture, talk about how logging out should work early on. Especially do this if you’re going to use OpenID Connect (which often is used in stateless fashion). It does not come with great answers to these questions.