Federated Login with OpenID
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.
- On your consumer sites take a username and figure out the identity url for the user (don’t ask for it)
- Setup a regular login page on your OpenID provider
- Setup the appropriate release policy for your consumer sites
- By default turn on a remember me cookie at the IDP
- 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.
