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:

  1. The user first establishes a connection between an identity provider (i.e., Google) and a relying party (i.e., Facebook).
  2. 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:

Logout link at the top of a page

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

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.

Single sign in 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.


9 Responses to “Logout: the other half of the identity equation”

  • Facebook User Says:

    Cool stuff.

    And I think I’ve got this figured out. I used Facebook Connect here, at Social Lipstick. I’ve tried logging in and out, and I see that logging out here logs me out of Facebook (as you explained above). Is there a way I can log out of Facebook Connect at Social Lipstick?

  • Luke Shepard Says:

    Hey Joe! Oh yeah I totally forgot to mention that you could just try it out here. So yeah, it works like you’d expect. Facebook Connect just uses your Facebook session -there’s no difference.

  • Michael Malone Says:

    Luke, totally agree with you, you’re dead on with this one. In addition to UX, I think single sign-out is necessary for security. Think about when people typically log out of a service. It’s usually when they’re on someone else’s machine or on a public terminal. If I use Facebook Connect to log into your blog and post a comment I’m creating a session authenticating me on Facebook. It’s misleading and potentially dangerous if you don’t destroy that session when I logout. The next person to sit down at that machine and visit Facebook will be logged into my account.

    How is this handled with the non single sign-on OpenID flow? If I log into a third-party site using Google I’m going to have to log into / create a session on Google. It’s probably not clear to the average user that, in order to log out, they’ll need to return to Google and log out there in addition to logging out on the third party site… So there may even be an argument to support single sign-out even for sites that don’t support single sign-in…

  • Facebook’s transparent use of OpenID | ../learninglab/joss Says:

    [...] know of three important blog posts about Facebook’s use of OpenID, two from Luke Shepard, the principle developer of OpenID on Facebook and another from Simon Willison. A month before [...]

  • Facebook User Says:

    I read your post on the fb dev forum on single-sign on, and responded there. Now that I’ve this post on why only option 3 makes sense, I have more to add. First of all, I think you your P and Q are wrong. It just isn’t true that being logged in on fb makes you logged in at the Run Around. Logging in to the Run Around doesn’t actually happen until you first _arrive_ there.

    Here’s how I see it:

    If you are logged in to a provider, then you can log in at a relying party.

    The contra-positive of this is

    If you cannot log in at a relying party, you are not logged in to a provider.

    This statement doesn’t tell us anything about how logging out should work.

    Ultimately, what we should be asking ourselves is What do users want? While this is best answered by conducting a survey, I’m going to argue for not logging out at the provider (option 2). If you’re at the Run Around, and you start clicking links and buttons, you will pretty much expect your actions will only affect things on the Run Around, except for things that explicitly have to do with fb (like posting stories to your news feed). This includes the “log out” link; it should only log you out of the Run Around.

    Suppose we want to be absolutely clear to the user about what the log out link does. We might change the text to say “log out of the Run Around and log out of Facebook”. Aside from being an eyeful, the user is going to wonder, “How can I just log out of the Run Around? I’m not done doing stuff on fb!”. You see, it makes perfect sense to the user that he can be logged out of the Run Around while he is logged in at fb.

  • BOBBY Says:


    Pillspot.org. Canadian Health&Care.No prescription online pharmacy.Special Internet Prices.Best quality drugs. High quality pills. Buy pills online

    Buy:Seroquel.Lipothin.Buspar.Zocor.Wellbutrin SR.Prozac.Advair.Benicar.Female Pink Viagra.SleepWell.Nymphomax.Amoxicillin.Lipitor.Cozaar.Ventolin.Female Cialis.Acomplia.Lasix.Zetia.Aricept….

  • Lawton Says:

    Craigslist http://7pt.8eb.ll7.co : Lawton…

    Craigslist…

  • WaterDetection Says:

    WaterDetection…

    “[...]Logout: the other half of the identity equation | Social Lipstick[...]“…

Leave a Reply

You must be logged in to post a comment.