OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing

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.

Also published on Medium.

45 thoughts on OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing

  1. 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.

  2. Pingback: Red Rover, Red Rover - Send Twitter On Over « Roo-minations

  3. Pingback: » OAuth, OpenId and why they are two different things.

  4. Pingback: Enterprise Web vs Consumer Web [2.0]: Top Six Differences | Bits And Buzz, by Jeremy Chone

  5. 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!

  6. 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.

  7. 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?

  8. Pingback: Google as an OpenID provider – Shizzle

  9. Pingback: Blog bookmarks 05/19/2010 « My Diigo bookmarks

  10. Pingback: links for 2010-06-27 • Bare Identity

  11. Pingback: OAuth vs. Open ID @ ???? Ennovation Technologies

  12. Pingback: 37signals will drop support for OpenID | Just enough code to be dangerous

    • OAuth. Nothing is ever clearcut :). Twitter shows it’s possible to do login via OAuth, if you accept that “identifying the user” is one of many possible services you could delegate to a third party with OAuth. And in fairness, it’s worked out well and lets Twitter developers focus on a smaller surface area.

  13. Pingback: How long until our Facebook profile becomes our proof of ID? | digitalcuisine

  14. Pingback: What’s the difference between OpenID and OAuth? | Everyday I'm coding

  15. Pingback: OpenID and OAuth using DotNetOpenAuth in ASP.NET MVC

  16. Pingback: What’s the difference between OpenID and OAuth? | ASK AND ANSWER

Leave a Reply