Thu 13 Mar 2008
Explanation: The Difference Between OpenID and OAuth
Posted at 17:41 +1100
In the past five days or so I've seen three different posts on the web where somebody has either confused OpenID and OAuth or expressed confusion as to how they differ. I'm not going to name names or point to URLs. I'd prefer to try to fix the problem.
Therefore, here's a simple, and hopefully clear and accurate, guide to the purposes of and differences between the two systems. If I had a video camera, I'd act out the sock puppet version for you. But I don't, so you have to read this instead.
Preliminary: The Problem With The Word "Auth"
Lazy message writers, in email, on blogs, even in the printed media, will throw around the abbreviation auth as though it's well-defined and clearly understood. They'll talk about "the auth system" or use it as a verb (little realising that when I rule the world, there's going to be a severe accounting for that bad habit) "you've been auth-ed".
The problem is here that "auth" is an abbreviation for both authorisation and authentication and they are different aspects of identity management. Unless the context is very clear, it is often confusing as to which use is intended.
Authentication is the act of confirming authenticity. In an online sense, "Bob authenticates Alice" means that Bob is convinced Alice is who she claims to be to whatever level of scrutiny Bob might wish to apply. It's important to realise that authentication levels differ and this will be a notable part of the story below. When you sign into an online account, you are usually authenticated to the extent that means "you know the username and password" and people who are meant to have access to that account should be guarding those pieces of information. At a stricter level, authentication might also mean "...and you successfully responded to the challenge we sent, which means you possess our time-synchronised keypad" (a common part of two-phase authentication: combining something you know and something your have).
Authorisation (or authorization, if you live in North America) is the act of granting access to resources. It's connected to identity in the sense that authorisation is usually granted based on who you are, but it may not require authentication. Anonymous (unauthenticated) users can still be authorised to view or interact with resources online.
So authentication and authorisation are independent, but interacting concepts. Authentication establishes who you are, authorisation concerns what you can do.
OpenID: Identifying Yourself
(I know I tend to ramble when I write. For those with some kind of attention deficit problem, there's a capsule summary, the short version, at the end of both this and the OAuth section.)
OpenID provides a way for Alice to state "this OpenID provider will authenticate that I identify with this URL (or i-name or i-number)". That's a bit of a multi-barrelled assertion and isn't normally how OpenID is framed, so let's break it down into pieces.
Recall how the process works when using OpenID: Alice wants to leave a comment on Bob's blog. She elects to post non-anonymously and uses the OpenID form field to enter her identity URL. Let's say Alice's OpenID URL is her blog's front page URL. Bob's weblog software will fetch the URL Alice provided, notice that Alice has delegated OpenID verification to a third-party OpenID provider and consequently will talk to that provider to see if they will authenticate Alice. This might require Alice to be redirected to her OpenID provider and log in, or it may happen automatically. It depends on a number of things, but that doesn't change the basic process. The provider will ultimately say "authenticated" or "not authenticated" and possibly also send back some extra information about Alice — her profile information such as preferred handle and maybe an email address — to Bob's server.
I've simplified things a bit here without losing the pertinent pieces. The URL could be replaced with what's called an XRI; an i-name or i-number. Alice could also have more than one OpenID URL or XRI. Bob's end of the discussion doesn't care about that.
At the end of this exchange, which takes less time than it took you to read the above paragraph, Bob has an assertion from the OpenID provider that Alice is indeed somebody who is authenticated for that URL.
This is a very, very weak form of authentication. From Bob's perspective, he has the assertion of authenticity from a provider that he may or may not trust. OpenID doesn't have a whitelist of blessed providers, so it's up to Bob to decide how much he trusts the particular claim of authenticity. If he cares, he knows who the OpenID provider is, so he can validate the claim against some internal list of "providers I trust" if necessary. From Alice's perspective, when she was redirected to her OpenID provider by Bob, she needs to ensure it really is her provider and not a phishing site. This can be avoided with careful use of certificates and URL watching, but it's a genuine exploitation path to the unwary and careless.
Thus, OpenID is usually pitched as a form of identity management, rather than tying it to a word people expect to carry a bit more weight, namely authentication. This is a good way to view things, too. With some level of assurance (ranging from none at all to totally believable), Bob can accept that Alice is identified with the URL she entered. I've highlighted the trust boundaries above, but if you're interested in this stuff, there's a lot of writing on the web about how to use OpenID as a factor in stronger authentication systems (mostly by only accepting trusted providers and/or trusted identifiers).
This doesn't make OpenID useless, though. It very nicely fills the place of having to register and sign in for every website you ever wanted to leave a comment at, for example. Those sites don't really care that you are who you claim you are. Rather, they want to give you a way to identify yourself to other readers of the site. They can use your chosen identifier as their internal way of tracking you, too, if they want to. People reading comments on a website shouldn't be believing that just because somebody posts with my name it really is me. It's likely to be me because there's no really good reason to usurp my name, but if you were about to bet your life savings on that fact, it would be wise to take further steps to verify the identity of the poster.
The Short Version
OpenID allows you to identify yourself with one or more URLs.
Each URL is vouched for by a particular OpenID service provider. It is up to the websites consuming OpenID logins (these websites are called Relying Parties (RP) in the lingo) to determine how much they trust each service provider when assigning authorisation privileges based on the OpenID login.
OAuth: Handing Out Temporary Authorisation
OAuth is an authorisation mechanism. It allows Alice to provide access to information she has stored on Bob's website to a third-party, Matilda. Normally, Matilda would not be able to access this information, but by using OAuth, Alice can provide (possibly temporary) authorisation to Matilda.
The common sort of scenario that OAuth facilitates is something like providing a printing firm access to otherwise restricted documents on another system. Alice connects to Matilda's printing website and says she would like to print 200 copies of the Alice Annual Report. The source data for this report is stored on Bob's website. Matilda can use OAuth to request access from Bob. She then redirects Alice to Bob's website, where Alice logs in and confirms that the requested access parameters are okay. Bob will then accept requests for the appropriate information from Matilda, providing Matilda presents the right OAuth token with the request.
Notice that once Alice has given her permission for this access, the information exchange is between Bob and Matilda. Alice has granted access to Matilda, without having to reveal to Matilda what Alice's access credentials are on Bob's site. The authentication between Alice and Bob remains between them and, by agreement, they generate a token that Matilda can use for her access.
As with OpenID, OAuth isn't a cure for all evils. It's an authorisation from Alice that Matilda can retrieve certain information from Bob. It doesn't say anything about what Matilda will do with that information. So using OAuth to provide a third-party access to your online address book doesn't prevent that third party from downloading the information and subsequently spamming all your contacts. OAuth is simply one tooth on the cog. Communications security might be necessary (to prevent Eve from watching the information as it moves between Bob and Matilda). Bob might need to undertake extra checks to verify that Matilda really is who she says she is and not Mallory, the evil impersonator.
The Short Version
OAuth provides a way to grant authorisation (access permission) to your data on some website to a third website, without needing to provide this third website with your authentication information for the original website. It provides an authentication token that the third-party can use (and only that third-party).
Wrap Up
I've glossed over a number of details in the above descriptions, but hopefully haven't omitted any of the necessary conceptual pieces. Both the OpenID and OAuth standards are fairly well written. Both are fairly good at outlining the limits of the guarantees they can make about the process. Both omit a few situations that will need to be addressed in the future, but that shouldn't stop them from being used today (and it isn't).
The important thing I'm trying to convey in this post is that they address different aspects of your online life. OpenID is a (by default, exceedingly weak) form of authentication, probably better thought of as an identity claim. OAuth is a way to delegate access authorisation for sites wanting to access your online data. They can work together, but they are orthogonal feature sets for the most part.
Further Reading
There is lots and lots of writing around the web about both OpenID and OAuth. More of the former than the latter, merely because OpenID is an older standard. Here a few links to the more conceptual stuff. I'm concentrating on the "what does it mean", "how can it be used" stuff, rather than the "how do I use it technically", which you can find via Google.
-
Tim Bray wrestled a bit with trying to understand the buzz around OpenID early last year. The result is that he does a good job of explaining why it's not very useful as a real authentication system out of the box, but ideal for blog post comment identification. He also covers how it could be useful for large organisations like his employer (Sun).
-
Eran Hammer-Lehav posted something late last year about his thinking on trying to use either or both of OpenID and OAuth in a web service. He's talking about systems that are HTTP accessible, but not necessarily an HTML page.
-
James Henstridge, a good friend of mine, has written some clear posts about OpenID over time. His writing on identifier reuse highlights one of the things that might have to be addressed in a future OpenID revision. His post about improving the client's security (Alice's view, in my example) illustrates some of the possibilities.
I'd like to be clear that despite a lot of focus on the security limitations of OpenID and OAuth in this article, I don't think they're fatally flawed. Rather, it's a matter of knowing where the boundaries lie. A tire iron is fatally flawed or, at least, very limited as a tool for cooking lunch, but it's ideal when you need to replace the flat tire on your car. Use these specifications for the purposes they're designed for and use them as only one part of an holistic security strategy and things will go well. I really like both of these ideas and want to see them more widely used and understood.
Finally, as a sampler of what is possible on the website builder side of things, have a read through Simon Willison's openid category. Or skim through Planet OpenID. My own previous writing in this area (OpenID Doesn't "Just Work" Yet and OpenID and Google's Blogger) are more negative than positive, but you can think of it as the Consumer Review approach to things.
