There's three types of sites

Let me count the ways…

Okay, so suppose you’re a website owner. You have a user database, but you want more people to use your site. You’ve heard about a lot of these technologies for making your login process easier, but you’re not sure how to use them. Facebook is offering Facebook Connect, and you’ve heard of Yahoo and the OpenID community. But how do you actually go about using them? What happens when a user decides to use one of these systems?

Three basic uses

Different sites have different uses for using delegated auth. Perhaps the site is already well established and just wishes to sprinkle some “social sauce” throughout to make their site more engaging. Other sites will be brand new and want to grow their userbase quickly. Still others may have a core userbase, but want to really increase their numbers.

1. Keyless remote

Log in once, logged in everywhere. Log out once, logged out everywhere.

My favorite aspect of this social web is the promise of being able to “sign into the web”. With a single click, I can log into any number of sites. For example, if I’m logged into Facebook, then I can go to a relying party and just be automatically signed in. This is incredibly powerful as it removes pretty much any friction. Of course there’s an initial setup phase for each website, but once that’s complete, I shouldn’t ever have to remember my provider again - the website just knows, and logs me in automatically.

If I log out of any site, then I’m logged out of my identity provider and all the rest of them. If I go to a shared computer, then I just click logout once, and I will be signed out of everything.

Master key

Substitute for name and password, but then manage everything after that.

Then there are some sites that will want to use OpenID as a means for logging in, but they have their own way of managing sessions after that. In this case, users will click on the “login” button for OpenID, Yahoo, or Facebook, and then they will get a session granted by the remote website. From here on in, it doesn’t really matter what the user does with his provider - the site will still have its own cookie that will determine if the user is logged in.

Simple Link

Establish a different identity, but don’t share sessions.

Some sites already have a strong userbase, and they perhaps have to protect credit cards or

Some sites already have a strong userbase. They really like selling data to advertisers, and they don’t want to get hung up on who “owns” the user. If they accept identity from a random OpenID provider, then what happens if that provider goes out of business? Will they be able to recover the identity? For that reason, these sites prefer each user to have their own username and password. They accept OpenID or Facebook because they want to just establish an extra link - for example, to get a user’s friends, or to display a link on their profile.

**How do we implement it?
**

Authentication is a gnarly problem. It’s hard enough to figure out how to securely keep authenticated sessions alive on a single domain; how do you manage to get an authenticated session across domains? If I want to use yahoo.com as a provider, and I live on crossways.com, then how do I do that?

Answer: it’s pretty tough, but getting easier as library support evolves.

Logging in

The login process for OpenID is pretty straightforward. You either redirect full, or use a browser popup, but you open a window onto the identity provider’s domain. The user enters their username / password, then la-dee-dah, they are sent back where they came from and they are logged in. The RP can then set a cookie to keep track of that state.

If the RP has reason to believe that a given user has come from a specific provider, but they aren’t sure, then they can use the checkid_immediate call in OpenID to check if the user is currently logged in. For example, the RP might store a long-term cookie that says I’m jerry from yahoo.com. When I visit their site, it could do a quick redirect and then redirect back to check if I’m actually logged into Yahoo as chuck. If I’m not, then the OP can just show their normal sign-in page.

With Facebook, it’s the same basic approach, except that it is wrapped in a Javascript library. The JS does some fancy auto-detection of your login state before it renders the popup. Most importantly, it allows a site to know whether you are an existing, logged-in user before it ever does a popup, by using Facebook’s cross-domain communication library.

Google does something like this for Blogger. If you visit Blogger from a new computer, you’ll first be redirected to google.com, and then immediately back, and Blogger uses that to tell if you are logged into your Google account or not.

Logging out

OpenID doesn’t have a way to support universal logout; with Facebook, there is a FB.Facebook.logoutUser() method that allows you to log the user out of Facebook (as well as your own site, if you want). Likewise, if you log out of Facebook, then it invalidates all your sessions with the remote sites (applications).