Single Sign Out
Let’s take a use case.
I sign into a site with my OpenID. Any site. Tumblr! (hey Tumblr, implement OpenID). So, now I’m logged into Tumblr and MyVidoop, my OpenID provider. I finish writing a post or posting a picture of a kitten or whatever. I’m done doing stuff, so I click ‘log out’ so factoryjoe doesn’t login and post pictures of his Hawaii trip onto my account. Unfortunately, right now, I’m only logged out of Tumblr. Which means that since I’m still logged into MyVidoop, factoryjoe can go off and log into Intense Debate now to lower my karma.
What a tool.
This is in no way a problem with MyVidoop - it’s a problem with federated login in general. This is yet another thing that Facebook has done that the Open Stack needs to replicate before we can have a serious solution. But that’s a topic for another conversation.
There are some people who will be a lot more equipped to answer questions about this, and hopefully they’ll tell me that I’m stupid and there’s a much better way to do this. As it stands, however, from my perspective there are basically three ways to do single sign out.
All of them suck.
However, not having single sign out is worse.
But, seriously, there has got to be a better way. But few people seem to be talking about this (again, I hope I’m wrong here).
Option 1
We take an idib style approach and on every request ping the OpenID provider to see if that user is logged in.
I think it’s pretty clear why this sucks for relying parties and why it isn’t really a valid option.
Option 2
On sign out, the relying party sends a little message to the OpenID provider saying, “Hey, this user just clicked the log out button on my site. I’ve logged her out here, but, you know, FYI.” The OpenID provider then goes, “Oh, cool! Thanks! I’ll send a message to every other site that she has last logged into since her last login and tell them that she’s now logged out. Off go a bunch of API calls to the relying parties using URLs discovered in XRDS.
This, also, sucks, but it sucks a lot less than Option 1. It has the advantage of putting most of the issues on the OpenID provider end, which is good, but there’s definitely still a fairly annoying requirement on the relying party end.
There’s also the issue where if the user logs out of one site, it doesn’t mean that she wants to be logged out of EVERY site.
Option 3
On signout, the relying party redirects the user to their OpenID provider which says, “Hey, cool, you clicked logout on X Site, do you want to log out of EVERYTHING?!” If the user says no, they’re just sent right back to a return_to URL on the RP end. If they say yes, the same thing happens, only off go those little API calls to their other RPs.
This solves some of the issues with Option 2 but brings up just as many mainly related to user experience. Having that step happen on every log out would also get pretty annoying.
None of these are good solutions.
I’m sure you can do better. You should. Let’s get the discussion started around this!
What about simply training the user?
So we could skip single sign out and just say, “Look, User, you need to sign out of your sites when you’re done with them. ALL OF THEM. Including your OpenID provider that you never go directly to in the first place.” This will become an easier pill to swallow as time goes on, but that’s a crappy excuse. We need to be making solutions right now.
And hopefully some people have some good ideas about this.
