What s the difference between OpenID and OAuth

Question

I m really trying to understand the difference between OpenID and OAuth  Maybe they re two totally separate things

User · Answer

OAuth builds authentication on top of authorization  The user delegates access to their identity to the application  which  then  becomes a consumer of the identity API  thereby finding out who authorized the client in the first place http   oauth net articles authentication

User · Answer

OpenId uses OAuth to deal with authentication    By analogy  it s like  NET relies on Windows API  You could directly call Windows API but it s so wide  complex and method arguments so vast  you could easily make mistakes bugs security issue    Same with OpenId OAuth  OpenId relies on OAuth to manage Authentication but defining a specific Token  Id token   digital signature and particular flows

User · Answer

Many people still visit this so here s a very simple diagram to explain it    Courtesy Wikipedia

User · Answer

At finally OAuth gives you back the access token to access the resource from resource server  OpenID gives you back meta data details about resources in JWT   encrypted token

User · Answer

OAuth   Used for delegated authorization only -- meaning you are authorizing a third-party service access to use personal data  without giving out a password  Also OAuth  sessions  generally live longer than user sessions  Meaning that OAuth is designed to allow authorization  i e  Flickr uses OAuth to allow third-party services to post and edit a persons picture on their behalf  without them having to give out their flicker username and password   OpenID  Used to authenticate single sign-on identity  All OpenID is supposed to do is allow an OpenID provider to prove that you say you are  However many sites use identity authentication to provide authorization  however the two can be separated out   i e  One shows their passport at the airport to authenticate  or prove  the person s who s name is on the ticket they are using is them

User · Answer

I am currently working on OAuth 2 0 and OpenID connect spec  So here is my understanding  Earlier they were    OpenID was proprietary implementation of Google allowing third party applications like for newspaper websites you can login using google and comment on an article and so on other usecases  So essentially  no password sharing to newspaper website  Let me put up a definition here  this approach in enterprise approach is called Federation  In Federation  You have a server where you authenticate and authorize  called IDP  Identity Provider  and generally the keeper of User credentials  the client application where you have business is called SP or Service Provider  If we go back to same newspaper website example then newspaper website is SP here and Google is IDP  In enterprise this problem was earlier solved using SAML  that time XML used to rule the software industry  So from webservices to configuration  everything used to go to XML so we have SAML  a complete Federation protocol OAuth  OAuth saw it s emergence as an standard looking at all these kind of proprietary approaches and so we had OAuth 1 o as standard but addressing only authorization  Not many people noticed but it kind of started picking up  Then we had OAuth 2 0 in 2012  CTOs  Architects really started paying attention as world is moving towards Cloud computing and with computing devices moving towards mobile and other such devices  OAuth kind of looked upon as solving major problem where software customers might give IDP Service to one company and have many services from different vendors like salesforce  SAP  etc  So integration here really looks like federation scenario bit one big problem  using SAML is costly so let s explore OAuth 2 o  Ohh  missed one important point that during this time  Google sensed that OAuth actually doesn t address Authentication  how will IDP give user data to SP  which is actually wonderfully addressed in SAML  and with other loose ends like   a  OAuth 2 o doesn t clearly say  how client registration will happen b  it doesn t mention anything about the interaction between SP  Resource Server  and client application  like Analytics Server providing data is Resource Server and application displaying that data is Client    There are already wonderful answers given here technically  I thought of giving of giving brief evolution perspective

User · Answer

There are three ways to compare OAuth and OpenID  1  Purposes OpenID was created for federated authentication  that is  letting a third-party authenticate your users for you  by using accounts they already have  The term federated is critical here because the whole point of OpenID is that any provider can be used  with the exception of white-lists   You don t need to pre-choose or negotiate a deal with the providers to allow users to use any other account they have  OAuth was created to remove the need for users to share their passwords with third-party applications  It actually started as a way to solve an OpenID problem  if you support OpenID on your site  you can t use HTTP Basic credentials  username and password  to provide an API because the users don t have a password on your site  The problem is with this separation of OpenID for authentication and OAuth for authorization is that both protocols can accomplish many of the same things  They each provide a different set of features which are desired by different implementations but essentially  they are pretty interchangeable  At their core  both protocols are an assertion verification method  OpenID is limited to the  this is who I am  assertion  while OAuth provides an  access token  that can be exchanged for any supported assertion via an API   2  Features Both protocols provide a way for a site to redirect a user somewhere else and come back with a verifiable assertion  OpenID provides an identity assertion while OAuth is more generic in the form of an access token which can then be used to  quot ask the OAuth provider questions quot   However  they each support different features  OpenID - the most important feature of OpenID is its discovery process  OpenID does not require hard coding each the providers you want to use ahead of time  Using discovery  the user can choose any third-party provider they want to authenticate  This discovery feature has also caused most of OpenID s problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don t get  Other features OpenID has is its support for ad-hoc client registration using a DH exchange  immediate mode for optimized end-user experience  and a way to verify assertions without making another round-trip to the provider  OAuth - the most important feature of OAuth is the access token which provides a long lasting method of making additional requests  Unlike OpenID  OAuth does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service  However  since OAuth does not support discovery  it requires pre-selecting and hard-coding the providers you decide to use  A user visiting your site cannot use any identifier  only those pre-selected by you  Also  OAuth does not have a concept of identity so using it for login means either adding a custom parameter  as done by Twitter  or making another API call to get the currently  quot logged in quot  user  3  Technical Implementations The two protocols share a common architecture in using redirection to obtain user authorization  In OAuth the user authorizes access to their protected resources and in OpenID  to their identity  But that s all they share  Each protocol has a different way of calculating a signature used to verify the authenticity of the request or response  and each has different registration requirements

User · Answer

OpenID proves who you are   OAuth grants access to the features provided by the authorizing party

User · Answer

I believe it makes sense revisit this question as also pointed out in the comments  the introduction of OpenID Connect may have brought more confusion   OpenID Connect is an authentication protocol like OpenID 1 0 2 0 but it is actually built on top of OAuth 2 0  so you ll get authorization features along with authentication features  The difference between the two is pretty well explained in detail in this  relatively recent  but important  article  http   oauth net articles authentication

User · Answer

OpenID is  mainly  for identification authentication  so that stackoverflow com knows that I own chris boyle name  or wherever  and therefore that I am probably the same person who owned chris boyle name yesterday and earned some reputation points   OAuth is designed for authorization to take actions on your behalf  so that stackoverflow com  or wherever  can ask permission to  say  Tweet on your behalf automatically  without knowing your Twitter password

User · Answer

OpenID is an open standard and decentralized authentication protocol controlled by the OpenID Foundation  OAuth is an open standard for access delegation  OpenID Connect  OIDC  Combines the features of OpenID and OAuth i e  does both Authentication and Authorization    OpenID take the form of a unique URI managed by some  OpenID provider  i e  identity provider  idP    OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies   OIDC uses simple JSON Web Tokens  JWT   which you can obtain using flows conforming to the OAuth 2 0 specifications  OAuth is directly related to OIDC since OIDC is an authentication layer built on top of OAuth 2 0       For example  if you chose to sign in to Auth0 using your Google account then you used OIDC  Once you successfully authenticate with Google and authorize Auth0 to access your information  Google will send back to Auth0 information about the user and the authentication performed  This information is returned in a JSON Web Token  JWT   You ll receive an Access Token and  if requested  an ID Token  Types of Token   Source  OpenID Connect  Analogy  An organisation use ID card for identification purpose and it contains chips  it stores details about Employee along with Authorization i e  Campus Gate ODC access  ID card act as a OIDC and Chip act as a OAuth  more examples and form wiki

User · Answer

More an extension to the question than an answer  but it may add some perspective to the great technical answers above   I m an experienced programmer in a number of areas  but a total noob to programming for the web   Now trying to build a web-based application using Zend Framework     Definitely will implement an application-specific basic username password authentication interface  but recognize that for a growing number of users the thought of yet another username and password is a deterrent   While not exactly social networking  I know that a very large percentage of the application s potential users already have facebook or twitter accounts   The application doesn t really want or need to access information about the user s account from those sites  it just wants to offer the convenience of not requiring the user to set up new account credentials if they don t want to   From a functionality point of view  that would seem a poster child for OpenID   But it seems that neither facebook nor twitter are OpenID providers as such  though they do support OAuth authentication to access their user s data   In all the articles I ve read about the two and how they differ  it wan t until I saw Karl Anderson s observation above  that  OAuth can be used for authentication  which can be thought of as a no-op authorization  that I saw any explicit confirmation that OAuth was good enough for what I wanted to do   In fact  when I went to post this  answer   not being a member at the time  I looked long and hard at the bottom of this page at the options for identifying myself   The option for using an OpenID login or obtaining one if I didn t have one  but nothing about twitter or facebook  seemed to suggest that OAuth wasn t adequate for the job   But then I opened another window and looked for the general signup process for stackoverflow - and lo and behold there s a slew of 3rd-party authentication options including facebook and twitter   In the end I decided to use my google id  which is an OpenID  for exactly the reason that I didn t want to grant stackoverflow access to my friends list and anything else facebook likes to share about its users - but at least it s a proof point that OAuth is adequate for the use I had in mind   It would really be great if someone could either post info or pointers to info about supporting this kind of multiple 3rd-part authorization setup  and how you deal with users that revoke authorization or lose access to their 3rd party site   I also get the impression that  my username here identifies a unique stackoverflow account that I could access with basic authentication if I wanted to set it up  and also access this same account through other 3rd-party authenticators  e g  so that I would be considered logged in to stackoverflow if I was logged in to any of google  facebook  or twitter       Since this site is doing it  somebody here probably has some pretty good insight on the subject   -   Sorry this was so long  and more a question than an answer - but Karl s remark made it seem like the most appropriate place to post amidst the volume of threads on OAuth and OpenID   If there s a better place for this that I didn t find  I apologize in advance  I did try

User · Answer

OpenId - Used only for Authentication  OAuth - Used for both Authentication and Authorization  Authorization depends on the access token which comes as part of JWT token  It can have details of user permissions or any useful information  Both can rely on 3rd party auth provider which maintains their accounts  For example OKTA identity provider  User provides the credentials on OKTA login page and on successful login the user is redirected on the consumer application with the JWT token in the header

User · Answer

Use OAuth if your users might just want to login with Facebook  or Twitter  Use OpenID if your users are neckbeards that run their own OpenID providers because they  don t want anyone else owning their identity

User · Answer

I d like to address a particular aspect of this question  as captured in this comment      OAuth  before granting access to some feature  authentication must be done  right    so OAuth   what OpenId does   grants access to some features       Hassan Makarov Jun 21 at 1 57   Yes    and no  The answer is subtle  so bear with me   When the OAuth flow redirects you to a target service  the OAuth provider  that is   it is likely that you ll need to authenticate with that service before a token will be handed back to the client application service  The resulting token then allows the client app to make requests on behalf of a given user   Note the generality of that last sentence  specifically  I wrote  on behalf of a given user   not  on behalf of you   It s a common error to assume that  having a capability to interact with a resource owned by a given user  implies  you and the owner of the target resource s  are one in the same    Don t make this mistake   While it s true that you authenticate with the OAuth provider  say  by user name and password  or maybe SSL client certs  or some other means   what the client gets in return should not necessarily be taken as proof of identity  An example would be a flow in which access to another user s resources was delegated to you  and by proxy  the OAuth client   Authorization does not imply authentication   To handle authentication  you ll likely want to look into OpenID Connect  which is essentially another layer on top of the foundation set by OAuth 2 0  Here s a quote that captures  in my opinion  the most salient points regarding OpenID Connect  from https   oauth net articles authentication        OpenID Connect is an open standard published in early 2014 that defines an interoperable way to use OAuth 2 0 to perform user authentication  In essence  it is a widely published recipe for chocolate fudge that has been tried and tested by a wide number and variety of experts  Instead of building a different protocol to each potential identity provider  an application can speak one protocol to as many providers as they want to work with  Since it s an open standard  OpenID Connect can be implemented by anyone without restriction or intellectual property concerns       OpenID Connect is built directly on OAuth 2 0 and in most cases is deployed right along with  or on top of  an OAuth infrastructure  OpenID Connect also uses the JSON Object Signing And Encryption  JOSE  suite of specifications for carrying signed and encrypted information around in different places  In fact  an OAuth 2 0 deployment with JOSE capabilities is already a long way to defining a fully compliant OpenID Connect system  and the delta between the two is relatively small  But that delta makes a big difference  and OpenID Connect manages to avoid many of the pitfalls discussed above by adding several key components to the OAuth base          The document then goes on to describe  among other things  token IDs and a UserInfo endpoint  The former provides a set of claims  who you are  when the token was issued  etc  and possibly a signature to verify the authenticity of the token via a published public key without having to ask the upstream service   and the latter provides a means of e g  asking for the user s first last name  email  and similar bits of info  all in a standardized way  as opposed to the ad-hoc extensions to OAuth that people used before OpenID Connect standardized things

User · Answer

OAuth 2 0 is a Security protocol  It is NEITHER an Authentication NOR an Authorization protocol    Authentication by definition the answers two questions    Who is the user  Is the user currently present on the system    OAuth 2 0 has the following grant types   client credentials  When one app needs to interact with another app and modify the data of multiple users  authorization code  User delegates the Authorization server to issue an access token that the client can use to access protected resource refresh token  When the access token expires  the refresh token can be leveraged to get a fresh access token password  User provides their login credentials to a client that calls the Authorization server and receives an access token   All 4 have one thing in common  access token  an artifact that can be used to access protected resource   The access token does not provide the answer to the 2 questions that an  Authentication  protocol must answer    An example to explain Oauth 2 0  credits  OAuth 2 in Action  Manning publications   Let s talk about chocolate  We can make many confections out of chocolate including  fudge  ice cream  and cake  But  none of these can be equated to chocolate because multiple other ingredients such as cream and bread are needed to make the confection  even though chocolate sounds like the main ingredient  Similarly  OAuth 2 0 is the chocolate  and cookies  TLS infrastucture  Identity Providers are other ingredients that are required to provide the  Authentication  functionality   If you want Authentication  you may go for OpenID Connect  which provides an  id token   apart from an access token  that answers the questions that every authentication protocol must answer

User · Answer

Both protocols were created for different reasons  OAuth was created to authorize third parties to access resources  OpenID was created to perform decentralize identity validation  This website states the following   OAuth is a protocol designed to verify the identity of an end-user and to grant permissions to a third party  This verification results in a token  The third party can use this token to access resources on the user   s behalf  Tokens have a scope  The scope is used to verify whether a resource is accessible to a user  or not  OpenID is a protocol used for decentralised authentication  Authentication is about identity  Establishing the user is in fact the person who he claims to be  Decentralising that  means this service is unaware of the existence of any resources or applications that need to be protected  That   s the key difference between OAuth and OpenID

User · Answer

OpenID is about authentication  ie  proving who you are   OAuth is about authorisation  ie  to grant access to functionality data etc   without having to deal with the original authentication    OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user   The blog post  OpenID versus OAuth from the user   s perspective  has a simple comparison of the two from the user s perspective and  OAuth-OpenID  You   re Barking Up the Wrong Tree if you Think They   re the Same Thing  has more information about it

User · Answer

OpenID and OAuth are each HTTP-based protocols for authentication and or authorization   Both are intended to allow users to perform actions without giving authentication credentials or blanket permissions to clients or third parties   While they are similar  and there are proposed standards to use them both together  they are separate protocols   OpenID is intended for federated authentication   A client accepts an identity assertion from any provider  although clients are free to whitelist or blacklist providers    OAuth is intended for delegated authorization   A client registers with a provider  which provides authorization tokens which it will accept to perform actions on the user s behalf   OAuth is currently better suited for authorization  because further interactions after authentication are built into the protocol  but both protocols are evolving   OpenID and its extensions could be used for authorization  and OAuth can be used for authentication  which can be thought of as a no-op authorization

User · Answer

The explanation of the difference between OpenID  OAuth  OpenID Connect      OpenID is a protocol for authentication while OAuth is for   authorization  Authentication is about making sure that the guy you   are talking to is indeed who he claims to be  Authorization is about   deciding what that guy should be allowed to do       In OpenID  authentication is delegated  server A wants to authenticate   user U  but U s credentials  e g  U s name and password  are sent to   another server  B  that A trusts  at least  trusts for authenticating   users   Indeed  server B makes sure that U is indeed U  and then tells   to A   ok  that s the genuine U        In OAuth  authorization is delegated  entity A obtains from entity B   an  access right  which A can show to server S to be granted access  B   can thus deliver temporary  specific access keys to A without giving   them too much power  You can imagine an OAuth server as the key master   in a big hotel  he gives to employees keys which open the doors of the   rooms that they are supposed to enter  but each key is limited  it   does not give access to all rooms   furthermore  the keys   self-destruct after a few hours       To some extent  authorization can be abused into some   pseudo-authentication  on the basis that if entity A obtains from B an   access key through OAuth  and shows it to server S  then server S may   infer that B authenticated A before granting the access key  So some   people use OAuth where they should be using OpenID  This schema may or   may not be enlightening  but I think this pseudo-authentication is   more confusing than anything  OpenID Connect does just that  it abuses   OAuth into an authentication protocol  In the hotel analogy  if I   encounter a purported employee and that person shows me that he has a   key which opens my room  then I suppose that this is a true employee    on the basis that the key master would not have given him a key which   opens my room if he was not     source      How is OpenID Connect different than OpenID 2 0       OpenID Connect performs many of the same tasks as OpenID 2 0  but does   so in a way that is API-friendly  and usable by native and mobile   applications  OpenID Connect defines optional mechanisms for robust   signing and encryption  Whereas integration of OAuth 1 0a and OpenID   2 0 required an extension  in OpenID Connect  OAuth 2 0 capabilities are integrated with the protocol itself     source      OpenID connect will give you an access token plus an id token  The id   token is a JWT and contains information about the authenticated user    It is signed by the identity provider and can be read and verified   without accessing the identity provider       In addition  OpenID connect standardizes quite a couple things that   oauth2 leaves up to choice  for instance scopes  endpoint discovery    and dynamic registration of clients       This makes it easier to write code that lets the user choose between   multiple identity providers     source   Google s OAuth 2 0     Google s OAuth 2 0 APIs can be used for both authentication and   authorization  This document describes our OAuth 2 0 implementation   for authentication  which conforms to the OpenID Connect   specification  and is OpenID Certified  The documentation found in   Using OAuth 2 0 to Access Google APIs also applies to this service  If   you want to explore this protocol interactively  we recommend the   Google OAuth 2 0 Playground     source

[authentication] What's the difference between OpenID and OAuth?

Examples related to authentication

Examples related to oauth

Examples related to openid