In this article I want to show the differences between OpenID and its younger cousin OAuth by providing for each a typical user scenario.
First the scenario for OpenID:
- User wants to access his account on example.com
- example.com (the “Relying Party” in OpenID lingo) asks the user for his OpenID
- User enters his OpenID
- example.com redirects the user to his OpenID provider
- User authenticates himself to the OpenID provider
- OpenID provider redirects the user back to example.com
- example.com allows the user to access his account
And now the scenario for OAuth:
- User is on example.com and wants to import his contacts from mycontacts.com
- example.com (the “Consumer” in OAuth lingo) redirects the user to mycontacts.com (the “Service Provider”)
- User authenticates himself to mycontacts.com (which can happen by using OpenID)
- mycontacts.com asks the user whether he wants to authorize example.com to access his contacts
- User makes his choice
- mycontacts.com redirects the user back to example.com
- example.com retrieves the contacts from mycontacts.com
- example.com informs the user that the import was successful
From those scenarios we can see that OpenID is about authentication (i.e. I can identify myself with an url) whereas OAuth is about authorization (i.e. I can grant permission to access my data on some website to another website, without providing this website the authentication information for the original website).
I hope this helps to keep apart those two standards :)
Thanks for the article – now I can point people to it instead of saying – don’ compare apples to oranges.
A concept we are currently working on is using OpenID to grant OAuth….
@Tarique: Thanks for your comment, I hope you will blog about it when it is finished ;-)
Yeah, I agree. This is really good primer for understanding the difference. Thanks!
@Ryan: You are welcome!
Wow this is great, i just read something about OAuth, and they mention something about OpenID, and now I understand the difference. Thank you.
@Malih: You are welcome!
[...] interesting links: Link1 [...]
I see the different and I also see redundancy which does NOT make for a smooth and simple user experience. Why is the user authenticating twice? How does it work in this scenario:
1. User goes to example.com which uses OpenID/OAuth exclusively (does not offer local logins itself)
2. User logs in with OpenID and a profile is created on example.com connecting the user’s OpenID to this new profile.
3. User wants to change settings to allow accessing and using their Picasa or Flickr (or both) photos on example.com
4. Setting page redirects to Picasa/Google and logs in with their OpenID and authorizes access.
5. User is redirected back to example.com
6. User is redirected to Flickr to login yet again (3rd time?) and authorize access and then back to example.com
This looks like a freaking mess to me. Can someone explain how this scenario is handled with OpenID/OAuth/OAuth WRAP/other if not as described? FB Connect offers a single API to do both and it works and has become a defacto standard for interoperability.
I’m really struggling with connecting these into a cohesive whole.
@Erik: Thanks for your comment!
Yes, the described scenario is correct. And I agree with you, the user experience is not that great in such a use case…
OAuth Wrap could, theoretically, simplify this process if the two services (Picasa, Flickr) trust each other’s Authorization Servers (or use the same Authorization Server). In that case the scenario would look like:
1. – 3. Same as above
4. Settings page redirects the user to the Authorization Server and the user authorizes access
5. Same as above.
6. No such step ;-)
But as always with new protocols: it will take quite some time until it gets implemented…
I hope this answers your question.
@cakebaker: yes it definitely does help and I thank you for your response.
My struggle to put all of this together into a cohesive whole continues and may well forever but I’m very excited about the prospects this sort of effort will offer. I found a YouTube video http://www.youtube.com/watch?v=6SYnlH5FXz0 which is exceptional in filling in the missing pieces, at least conceptually.
I feel strong enough about the righteousness of the OpenID and OAuth concepts that I’ll be committing to using them exclusively in all of my future projects even if it’s a bumpy, partially paved road. I suppose if it wasn’t, it wouldn’t be interesting.
Keep up the great work!
@Erik: Thanks for the link to that video, and good luck on your journey with OpenID and OAuth :)