OAuth, OpenID…they sound like the same thing and they kind of do vaguely similar things But I’m here to tell you, OAuth is not Open ID. They have a different purpose. I’ve been playing around with OAuth a bit in the past couple weeks and have a grip on what it’s aiming to do and what it’s not aiming to do.
To start with, here’s what OAuth does have in common with Open ID:
- They both live in the general domain of security, identity, and authorisation
- They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance. Think REST, not SOAP. Think Bar Camp, not The 25th Monosemiannual International Convention for the Society of Professionals who Devise Acronyms Quite a Bit.
- They both celebrate decentralisation. There is no central Open ID or OAuth server that holds all the security information in the universe (cf Passport). Anyone can set up as a server or a client.
- They both involve browser redirects from the website you’re trying to use – the “consumer” website – to a distinct “provider” website, and back again. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.
- The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.
With that much in common, the casual observer could be forgiven for confusing them. But they’re different. Not different as in “vying to be the no. 1 standard”, but different as in “they let you do different things”. How so?
Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr. OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.
With OAuth, you still need to log into the provider. e.g. When Moo sends you to Flickr, you still have to log into Flickr (or be logged in already). How Flickr decides you’re logged in is completely orthogonal to OAuth. It could be a standard username-password login, it could be via a physical password device, or it could well be via Open ID.
With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you, e.g. some photos, addresses, phone numbers, etc., and with your consent, send it back to the consumer so you don’t have to re-enter all the boring profile details again. However, this is data of a generic, non-application-specific, nature. (And even this limited form of sharing is an extension to the core Open ID spec.) With OAuth, any information you hold on any website can be shared with another website. You could share your GMail with a clever consumer that automatically tags items by inspecting the content, if GMail was an OpenAuth consumer.
Or you could copy your GMail address book into Facebook, by allowing Facebook to read your GMail account. Right now, the only way to do that is to give Facebook your GMail username and password. Clearly a dumb thing to do, and that’s exactly the kind of thing OAuth is set up to prevent. OAuth prevents it by explicitly asking you if you want to let Facebook grab your details from the provider. That’s not a problem Open ID solves. Even if Facebook and GMail used Open ID and you had accounts with both against the same Open ID, you still couldn’t get Facebook to read your GMail account. The Open ID provider wouldn’t let Facebook log in to GMail as if it was you. Even if an Open ID extension came along to allow it, you wouldn’t want it. It’s too coarse-grained and would allow the consumer to do too much potential damage. OAuth is more fine-grained – consumers can do some things with your provider data, not everything.
Brilliantly clear, thank you.
I was just reading an article about how the Twitter developers were griping bout implementing OAuth and that it was vulnerable to certain phishing schemes as OpenID is; and I thought to myself “what’s the difference?” You answered very succinctly and clearly.
Red Rover, Red Rover - Send Twitter On Over « Roo-minations // Feb 8, 2009 at 5:15 pm
[...] an open authentication model that promotes application authentiaction and data sharing. Â OAuth is not the same thing as OpenID (which is for user/personal authentication). Â At the same time, they DID NOT annouce support for [...]
» OAuth, OpenId and why they are two different things. // Feb 16, 2009 at 12:32 pm
[...] http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thin... [...]
Great post, thanks for this good explanation.
Enterprise Web vs Consumer Web [2.0]: Top Six Differences | Bits And Buzz, by Jeremy Chone // Mar 6, 2009 at 8:45 pm
[...] of both enterprise and consumer Web applications is the single sign-on. In the consumer Web, Open Auth and OpenID seem to have gained some momentum while the enterprise is using a mix of proprietary technology [...]
Great explanation, thanks. I’ve put a link to this entry on a page on our new website where I attempt to explain OpenID/OAuth in the context of researcher activity on the Internet. Please have a look, I’d appreciate suggestions for improvements!:
http://www.gen2phen.org/researcher-identification/researcher-identification-primer/tying-it-all-together
Thanks Mahemoff, that’s of great help to me! Mind, I’m still having trouble writing a simple OAuth server in PHP…
This is a convoluted area with many words being ambiguous! Register? A new user? A new session? Login? Which way?
Hopefully I’ll get there soon enough!
Now I can see the light! Great post
A great, clear explanation. Thanks.
Simply put, OpenID is for authentication across sites; while OAuth is for authorization one site to the other. When access one site by OAuth, the authentication is combined with authorization.
Can OpenId + oAuth be used for Single Signon to Multiple sites ate once that are not using subdomains lets say there are 3 sites
http://www.mylogindomain.com http://www.mysiite1no-subdomain.com http://www.mysite2-no-sub-domain.com
if the user logs in using a login widget on any one of these sites i want to log them into all of the above domans andthey should remain active for the typical session of programmed timeout period of inactivity. Which of these tools is best for that?
in the above example the sites are all hosted on the same instance of apache if that helps. thanks
Johnny, at a glance, I’d say no, but I suggest asking on StackOverflow.
Google as an OpenID provider – Shizzle // Dec 14, 2009 at 9:00 am
[...] Why is Google doing this, you may ask? They are usually very good about these things and usually support an open standard (like they have done with XMPP, which they use for Google Chat.) My suspicion is that they want to plug their own OAuth instead, which is a similar protocol, but they effectively solve different problems. [...]
Thanks for the clear explanation.
Thanks for a nice, clear explanation.
Thanks for a straightforward explanation – this is very difficult to find
Good & clear explanation, thx!!
Blog bookmarks 05/19/2010 « My Diigo bookmarks // May 19, 2010 at 4:30 am
[...] OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing [...]
Exactly the kind of explanation I was looking for – very clear, concise and kept pretty short.
Thanks for this article!
While I was aware of similarities, differences between OAuth and OpenID are new to me. Thanks for this amazing article.
links for 2010-06-27 • Bare Identity // Jun 28, 2010 at 12:01 am
[...] OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing A nice, simple explanation of the two identity "standards". (tags: openid oauth identity security) [...]