OAuth is used in access authorization while OpenID are used in user authentication.

OAuth does have in common with OpenID

  • They are open web standards.
  • They both celebrate decentralisation.
  • 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

Mainly different as in “they let you do different things”

  • OpenID gives you one login for multiple sites. Each time you need to log into Zooomr - a site using OpenID - you will be redirected to your OpenID site where you login
  • OAuth lets you authorise one website - the consumer - to access your data from another website - the provider. With OAuth, you still need to log in the provider. How the provider decides you’re logged in is completely orthogonal to OAuth. Maybe username, password, even maybe OpenID.

  • With OpenID, there is no suggestion of two web apps sharing your data. Except some profile details. However, this is data of a generic, non-application-specific, nature.
  • 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.

Their scenario

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

So OpenID just resolve one issue: User Dont want to manage many username and password!?

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

So OAuth is doing the really meaning stuff!