Federated ID, OpenID, and OAuth: A Web Authentication Primer

Federated ID

Federated ID, also called Federated Identity Management (FIM), allows a Service Provider (SP) to offer a service without implementing its own authentication system, and to instead trust another entity—an Identity Provider (IdP)—to provide authenticated users to them.

If that seems confusing, imagine two companies: IdentiCorp and ServiceInc. ServiceInc has great services, but they don’t like the idea of managing passwords for users. IdentiCorp, on the other hand, provides username and password management as their main business.

So these two companies come to an agreement—ServiceInc will allow people to log in to their websites using IdentiCorp credentials. This means when someone visits ServiceInc’s website and they haven’t yet authenticated to the site, they are redirected to IdentiCorp where they enter their IdentiCorp credentials. Once they authenticate, IdentiCorp then redirects the user back to ServiceInc, and tells ServiceInc in a cryptographicall secure way that, “this user is o.k., according to me.” ServiceInc trusts IdentiCorp, so the user is able to do what they need to do within ServiceInc.

Technology

The technology used to implement this functionality is XML-based, with two options being presented to implementers. SAML is backed by OASIS, and Micorosoft and IBM have partnered to push the WS-Security alternative. SAML seems to be the most popular right now, with the Liberty Alliance adopting the SAML 1.1 standard, but hopes in the industry are that SAML 2.0 will include the best of both SAML 1.1 and the latest WS-Security features.

OpenID

Rather than being something completely separate, OpenID is just one type of Federated Identity system. OpenID is focused more on the consumer market, whereas FID-proper is focused on the enterprise–but the concept is the same. It offers the ability for users to log into one website (Facebook, for example) using credentials from another website, such as Google (who is now an OpenID identity provider).

How It Works

1. You give the website you want to use your OpenID
2. It goes to that location to see where you need to authenticate
3. It sends you to that location (your OpenID provider)
4. You authenticate there
5. Your OpenID Identity Provider tells the website you want to use that you’re ok (but without giving it your password)
6. You are now able to use the website without having to give it any password

This sounds complex, but it all happens in a flash–just as if you were logging into the site itself. The difference is, you never had to remember or enter a separate password.

Keep in mind: this technology is not just theoretical; it’s already being used on many prominent sites today, with many more being added constantly. You can, for example, link your Facebook account (a service) to your Google account (an identity provider) and log into Facebook automatically if you are already signed in to Google. That kind of integration is taking place all over the web.

Here are a few of the main benefits of OpenID:

• Reduce the number of usernames and passwords you need to remember. Remember your OpenID to get into all OpenID-supporting sites rather than having individual passwords for each.
• Leverage information in your OpenID profile while signing up on new websites so that you don’t have to enter in the same information over and over for each new place.
• With OpenID you don’t have to worry about your password being compromised at a given website, OpenID-based sites don’t actually store your OpenID password at all.

OAuth

Many confuse OpenID and OAuth, but although they can be used together they are actually quite distinct from each other. While OpenID’s main purpose is to reduce the number of identities people need to maintain online, OAuth’s main goal is to eliminate the need to give website A your username and password for website B, and determines what website B can get from A once it’s been allowed access.

To simplify for the infosec geeks, OpenID is about authentication, and OAuth is about authorization.

The sharing scenario comes up quite often within social networking services, which often benefit from leveraging each other. Want to see if your Twitter friends are on Facebook? Or maybe you want a certain website to run stats on your Twitter ranking? In the past you had to give away your Twitter username and password to do this, which is a horrible idea. This is bad because a) that password could be compromised (you don’t use it anywhere else do you?), and b) it offers no granularity in what can be done with that password.

OAuth solves this by:

1. Allowing functionality to be shared between websites without passing your password between them, and
2. Giving only limited access to features between websites, so it’s not “all or nothing”

This way you can give a social site like Facebook access to your images on an Image site like Flickr without giving Facebook your actual Flickr credentials.

The diagram below shows how Google’s description of the OpenID process, including the sending and receiving of OAuth tokens. The key there is that the OAuth piece was optional since it’s a separate authorization component added on top of the OpenID authentication protocol.

Summary

So that’s a short overview of Federated Identity, OpenID, and OAuth. If you remember anything, remember that:

1. Federated Identity is where one entity trusts another entity with user management.
2. OpenID is one type of Federeated Identity, where major websites are now allowing you to log into them using OpenID credentials rather than individual usernames and passwords for each specific site.
3. OAuth allows you to share information and content between sites without sharing your password and while limiting what all can be accessed from one to another.

I hope this has been informative, and feel free to contact me (either directly or in the comments) with any comments, corrections, or questions. ::

Links

[ OpenID | wikipedia.org ]
[ OAuth | wikipedia.org ]
[ List of OpenID Providers | wikipedia.org ]