Logout: the other half of the identity equation

This week, Facebook began accepting OpenID for single sign on. At the Internet Identity Workshop, many people raised a lot of questions about Facebook’s implementation, and in general the relationship between single sign in and sign out. In this post, I’ll argue that sign in is only half the battle; if we want OpenID to represent a complete identity solution, then it needs to support sign out just as robustly as it does sign in.

First, let me define what I mean by “automatic single sign in”. Here’s how it works:

The user first establishes a connection between an identity provider (i.e., Google) and a relying party (i.e., Facebook).
On subsequent visits, if the user is signed into their provider, then the relying party detects that and automatically logs them into their own site.

So then, the user sees something like this on the relying party:

What does that “logout” link do?

There are three possible choices:

Log you out of the current site. (clear cookies on the current domain)
Log you out of the current site AND the identity provider. (clear cookies and use cross domain communication to clear the parent)
Give the user a choice between #1 and #2.

As I argued last fall, the only logical choice is #2: for it to log you out of not only the current site, but the identity provider as well.

For #1 or #3 (which involve clearing cookies on just the current domain), we leave the user in a logically inconsistent state, which exposes them to security and usability problems.

The contrapositive

One of the basic rules of logic says that if an if/then statement is true, then its contrapositive must also be true.

IF p => q THEN !q => !p

So if we have:

P = “You are logged into the provider”
Q= “You are logged into the relying party”

Then the negation would be:

~Q = “You are NOT logged into the relying party”
~P = “You are NOT logged into the provider”

In English:

If you are NOT logged into the relying party, then you should NOT be logged into the identity provider.

Otherwise, we end up with a contradiction. The user clicks “logout”, and perhaps they even see a logged out page, but when they refresh or navigate away, the relying party will grab the parent’s session and log them right back in.

In short: for relying parties and providers that support automatic single sign in, they need to also support automatic single sign out.

The examples

We can look to the web to see how real sites have implemented this. My favorite example is Google, Youtube, and Blogger. These are all owned by the same company, and if the user sets it up, then they all share the same identity provider (Google). However, I think to most consumers, they are branded sufficiently different that it approximates the world in which the provider and the relying party have no relationship.

Link your Blogger account with Google, then log into Gmail. Then go to Blogger - you’re automatically logged in. Now, click “logout”. You are logged out of Blogger and Google. (Incidentally, you’re also logged out of YouTube, Gmail, and all other Google services).

As another example, go to Citysearch. Log in with Facebook Connect. Now log out, and you are logged out of Facebook as well as all other Connect sites that implement automatic login detection.

Implementation details

Single sign in can be implemented in different ways. With OpenID, it is accomplished with an immediate mode call. A relying party can do an immediate call either in a background iframe, or with a full page redirect (if there is only one provider).

In Facebook Connect, the background iframe request is done automatically by the Facebook Javascript libraries. An application can support single sign in by assigning a callback that refreshes the page when the user is logged in.

Single Sign Out

But, how do we do logout? For Facebook Connect, a site calls FB.Connect.logout(). That will do a background ping to Facebook that clears the user’s current session. It also briefly pops up a screen that says “You are logging out of Facebook.”

There is no equivalent support in OpenID, but I argue that there should be. I would like to see two request modes in addition to checkid_setup and checkid_immediate.

logout_teardown: Inverse of checkid_setup, allows user interaction for the logout. If a provider chooses, they could show the user a page before logging them out, and perhaps give the user a choice.
logout_immediate: Inverse of checkid_immediate, logs out without any interaction. This could be done in a background iframe or full page redirect.

It would be up to the provider to support one, both, or none of these additional modes.

In the example of Facebook Connect, a provider could display the “You are being logged out” notice via logout_setup.

The choice

But wait, you say! I don’t like this behavior! I don’t want to be logged in and out at will - I want choice to navigate throughout the web.

First, let me assert that most people don’t care that much. They just want it to work. And single sign in / sign out is a conceptually easier model to handle (once we get the kinks out) than having the keep track of accounts across the web. Single sign in is kind of the point of OpenID and related technologies.

That said, there are legitimate reasons why you might not want to support automatic login. For example, Mint.com handles very sensitive data, so may not want to trust in third-party credentials exclusively. Or Netflix, which has its own very developed sense of user identity, including credit cards on file, may choose not to accept single sign on. These companies may find it useful to link with other identities, but single sign on is just not part of the equation.

That’s fine, actually - they don’t have to. But the developer does need to pick a side. If you don’t want to support sign in, then you don’t need to support sign out. But for those sites that DO support sign in, they DO need to support signout. You’re either in the club or not.

Imagine there’s a “single sign in cloud”. When a user logs into their identity provider, they log into the entire cloud; when the log out, they log out of the whole thing. Sites choose whether they join the cloud.

Let’s review the contrapositive rule. IF a site supports automatic login THEN it must support automatic logout. It’s a choice. If you don’t want to log the user out of the provider when they hit “logout”, then you can’t automatically log them in. You must require them to click a button or enter a password or some such to get in - each and every time.

But regardless, we want to make sure that OpenID supports automatic login and logout, even if it’s not always required.

Update: Shibboleth and Single Sign Out

There’s already been some extensive analysis of single signout within other identity communities. That post makes the very valid point that single signout is much harder than it seems. However, I don’t think that argues that it shouldn’t be attempted, just that we need to watch out and use the right tools.

Logout: the other half of the identity equation