ActsAsFlinn

OpenID as a Single Sign-On

I’m working on implementing SAML relying party services for a large household brand. I recommended OpenID about a year ago but they chose SAML instead. SAML is Sun’s an industry standard for Single Sing-On.

I’ve come to realize why the powers that be chose SAML instead of OpenID. OpenID is essentially the same thing as SAML but SAML’s user experience is designed in such a way that the IDP is providing a federated sign-on process. The user experience is designed for sign-in not cover-your-ass disclaimers like you find with most OpenID providers.

For example, a user browsing a CNN partner site can expect a CNN login page and CNN’s login page doesn’t educate the user on the virtues of SAML. The OpenID user experience can be implemented the exact same way but they chose SAML because when they tried someone’s (Yahoo!) OpenID implementation they were confused (for good reason). In their mind OpenID was a bad user experience. They took it at face value and didn’t know that you could engineer the OpenID user experience.

Guess what. OpenID can be used for Single Sign-On.

OpenID can be used for federated login. Here’s how.

1. On your consumer sites take a username and figure out the identity url for the user (don’t ask for it)
2. Setup a regular login page on your OpenID provider
3. Setup the appropriate release policy for your consumer sites
4. By default turn on a remember me cookie at the IDP
5. Use cookies on your consumer sites to figure out the identity url for the user.

Single Sign-On with OpenID = Done.

The result is a user that has no idea they’ve just used OpenID (a great user experience), a provider that can service any partners and partners that can integrate faster with a well supported open stack available for many platforms right now.

OpenID User Experience is Piss Poor

With piss poor OpenID setups providers are missing the opportunity to leverage their #1 asset, their user base. Recent OpenID user experience research from Yahoo and Google show something obvious – they both suck at providing OpenID. OpenID in its most basic form allows the user to supply a URL. Even if that’s the best UX you can come up with, don’t give the user a hash they can’t remember (Yahoo!). But that’s not the best you can do. There is no standard that says the user has to supply their own URL, you can should build it for them. Also, I don’t care what anyone says about fracturing the standard, GOOG is right – email is the obvious choice.

Facebook Connect is getting crazy adoption because it’s easy and the user doesn’t have to make a choice about what IDP to use. FBC is going to continue to mop up because they have a huge user base that is arguably more savvy than other large IDP’s. Facebook is making it easy to just get to what you want without caring about login.

Implementing OpenID shouldn’t be completely promiscuous. Choose a partner and be happy with your choice. What I mean by that is, if you think Yahoo!, AOL, Google are going to provide you with the right registered user base just pick one. Present only one or two IDP options and maybe an advanced option for power users if you really want it.

If you’re consuming OpenID and not making it simple for users you’re missing the boat. If you’re providing OpenID and trying to educate the user or filling your page with warning triangles and disclaimers your putting holes in your ship.