I am very confused the difficult jargon available in web about OAUTH, OpenID and OPENID Connect. Can anyone tell me the difference in simple words.

up vote 140 down vote accepted

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.

  • Great Thanks. Can you just explain it in English jargon instead of server jargon. I like the hotel example. But for explaing the OPENID(first paragraph) you are using Server word – user960567 Oct 29 '13 at 14:08
  • 17
    "Server" here means "a computer which sits in some room, waiting for data to come through the network, and then responds to it". That's hardly jargon. – Thomas Pornin Oct 29 '13 at 14:15
  • 2
    @user960567 at some point you can't really distill details or ideas any further by switching 'jargons', especially when dealing with complex topics like authentication, authorization, or delegation. – Steve Oct 29 '13 at 16:37
  • 3
    @ThomasPornin, a hotel room key is analogous to an OAuth 2 access/bearer token; it is not analogous to an OpenID Connect ID token. – cobra libre Feb 20 '14 at 0:12
  • 1
    @GayanSanjeewa And now they don't. – BenV Jan 3 '15 at 21:25

Simple Terms

  1. OpenID is about verifying a person's identity.
  2. OAuth is about accessing a person's stuff.
  3. OpenID Connect does both.

All three let a person give their username/password (or other credential) to a trusted authority instead of to a less trusted app.

More Details

To understand something, look at its history.

OpenID & OAuth have developed on parallel tracks and in 2014 merged into OpenID Connect. Throughout their history, OpenID and OAuth have let an app use a trusted authority to handle private user credentials. Whereas OpenID let the authority verify a user's identity, OAuth let the authority grant limited access to a user's stuff.

OpenID 1.0 (2006) lets an app ask an authority for proof that an end user owns an identify (a URL).

  • End user to app: I am Steve A. Smith.
  • App to authority: Is this Steve A. Smith?
  • The end user and authority speak for a moment.
  • Authority to app: Yes, that is Steve A. Smith.

OpenID 2.0 (2007) does the same, but adds a second identity format (XRI) and adds flexibility to how the end user specifies the identity and authority.

OpenID Attribute Exchange 1.0 (2007) extends OpenID 2.0 by letting an app fetch & store end user profile information with the authority - in addition to verifying the end user's identity.

  • End user to app: I am Steve A. Smith.
  • App to authority: Is this Steve A. Smith? Oh, and if it is, also fetch me his email address and phone number.
  • The end user and authority speak for a moment.
  • Authority to app: Yes, that is Steve A. Smith. His email is steve@domain.com and phone number is 123-456-7890.

OAuth 1.0 (2010) lets an end user grant an app limited access to resources on a third-party server that an authority owns.

  • App to end user: We'd like to access your pictures on some other server.
  • The end user and authority speak for a moment.
  • Authority to app: Here is an access token.
  • App to third-party server: Here is the access token that proves I am allowed to access pictures for an end user.

OAuth 2.0 (2012) does the same thing as OAuth 1.0 but with a completely new protocol.

OpenID Connect (2014) combines the features of OpenID 2.0, OpenID Attribute Exchange 1.0, and OAuth 2.0 in a single protocol. It allows an application to use an authority...

  1. to verify the end user's identity,
  2. to fetch the end user's profile info, and
  3. to gain limited access to the end user's stuff.
  • 1
    Thanks for this great answer Shaun. The historical perspective and easy-to-read scenarios clarify a lot of confusions. – Hakan Serce Jan 3 '17 at 22:35
  • 1
    OAuth 2.0 does not do the same as OAuth 1.0, because OAuth 1.0 provides both authentication and authorization before using a resource, while OAuth 2.0 provides only authorization. In OAuth 1.0, every request is signed with a pre-negotiated secret shared key between the client and the server and thus every request is authenticated (because of the signing process) and authorized (because the user has authorized the token). While with OAuth 2 this may not be the case - you may have implementations where only having the Access token is enough to access resources (no authentication). – luben Mar 5 '17 at 11:25

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


Courtesy Wikipedia

  • Why couldn't someone snap up the certificate in the OpenID Authentication and pretend to be the authenticated user? – ptf Sep 30 '16 at 8:44
  • @ptf Sounds like a separate question! – jtpereyda Oct 18 '16 at 22:12
  • @ptf If they can get access to it, then of course they can. An OAuth token, and, well, any form of access token is of course capable of being used by a third-party whose gained access to it somehow. The server said could, in either case, attempt to apply heuristics (e.g. geolocation, access behavior) to assert that it may be a malicious actor and expire session or force MFA assertion. – Andrew Marshall Jun 22 '17 at 16:16

In addition to the other responses: I think that a lot of confusion comes from inacurrate, or at least unusual use of the terms Authentication and Authorization

OpenID Connect 1.0 is marketed as an Authentication solution, while it does not, by itself, handle the authentication. The "real" authentication in its basic sense (process of validating the user credentials to prove an identity) is out of scope of OpenID Connect.

OpenID Connect should be better marketed as a Federation protocol, allowing a Relying Party to use the existing authentication process, user database and session handling from a third-party ID Provider. That is functionnaly similar to SAML 2.0.

Note: strictly speaking, from a Relying Party point of view, obtaining and validating an ID Token from an ID Provider can be considered as an Authentication method. I believe that is where "OpenID Connect is a Authentication protocol" comes from.

Same reasoning for OAuth 2.0 being an Authorization protocol: usually authorization is the process of defining an access policy that determines which users have access to which resources. That definition hardly applies to OAuth.

OAuth 2.0 is actually giving a way for users to allow an application/client to access their own resources on their behalf. In other words, OAuth 2.0 is authorizing clients applications, not users, to access the resources. The Authorization Policy (granting users access to resources) is supposed to be existing prior to deploying OAuth.

I would have labeled OAuth an access delegation protocol.

I apologize if that post raises the confusion even further :)

We already have a diagram and a lot of good data so here is an example in case that helps.

Let's say I want to post a comment to StackOverflow. StackOverflow only allows comments if a user has 50 reputation.

StackOverflow must authorize this request (e.g. only allow it if the user has >= 50 rep). StackOverflow would not use OAuth to do this because StackOverflow owns the protected resource. If StackOverflow were trying to post a comment to Facebook on the user's behalf then it would use OAuth. Instead, StackOverflow will use local authorization (e.g. if (user.reputation < 50) throw InsufficientReputationError();)

In order to do this StackOverflow must first know who is making the request. In other words, in order to authorize the request it must first authenticate the request.

StackOverflow first checks the session and the HTTP headers to see if the user can be quickly authenticated (e.g. this is not their first request) but that fails.

Let's pretend StackOverflow has decided to use OpenID Connect. This means that StackOverflow trusts an identity provider. This is a service that StackOverflow trusts which can tell StackOverflow who the current user is. In this example we will assume that is Google.

StackOverflow now asks Google who the current user is. However, Google must first ensure that StackOverflow is allowed to know who the current user is. In other words, Google must authorize StackOverflow. Since Google is the owner of the protected resource and StackOverflow is the one accessing it we can use OAuth here. In fact, OpenID Connect mandates it.

This means that StackOverflow has to authenticate with an authorization server that Google trusts (in reality, this would also be Google, but that doesn't have to be the case) and get an access token. It takes that access token to Google and asks for the user's identity. Google then returns the user's identity (signing the identity on the way) and StackOverflow then authorizes the request now that it knows the user's identity.

In case you missed it there were multiple authentication and authorization steps each.

  • StackOverflow attempted to authenticate the request using session cookies but that failed.
  • StackOverflow then authenticated the request by using OpenID Connect
  • Google authorized SO's request for identity by using OAuth
  • The Authorization Server authenticated StackOverflow (probably using a client id & client secret).
  • In addition, as part of the OAuth workflow, the Authorization Server may have authenticated the request by asking the user for her username & password.
  • Furthermore, the user herself may have authorized SO's request for identity by responding to a grant screen (e.g. "do you want to allow StackOverflow to have access to your email?")
  • StackOverflow authorized the request by ensuring the user had >50 reputation.

What is OpenID (without the connect)?

This was an earlier protocol that allowed an identity provider (like Google) to pass user information to a service (like StackOverflow). However, it used another method (not OAuth) for Google to authorize that StackOverflow is allowed to access the user's identity. OpenID had some security flaws (which I believe were addressed) but in my opinion the real killer was simply the fact that OAuth had better support and thus tended to be less work than learning OpenID's custom protocol.

As of today everyone is abandoning it. Don't use it. Use OpenID Connect.

"Abusing" OAuth

In the scenario I described above OAuth is being used exactly as intended for authorization. However, there is another workflow which can often confuse people. This arose because in many situations (most?) the server providing the user's identity and the OAuth authorization server are the same server.

In this case it seems a bit excessive that an HTTP request is first made to the authorization server to get an access token and then again made to the same server to get an identity token. So an extension was created for the OAuth spec to allow the authorization server to bundle user identity information with the access token.

This allows authentication to happen entirely in the browser (e.g. StackOverflow's servers need not be involved). However, that sort of authentication is less useful and (I think?) is less commonly used.

As mentioned already, Oauth is one thing, OpenID is another, and OpenID Connect combines the two.

But, as mentioned already, the use of authentication and authorization to differentiate Oauth and OpenID is just plain wrong. Authentication, the confirmation of the veracity of an entity's claim to a stored identity, is attributed to OpenID but it is definitively part of the Oauth process. Authorization, permission to access a specific resource or container, is attributed to Oauth but it is definitively part of the OpenID process.

In my experience, the real difference between Oauth and OpenID can be seen in the typical non-auth-related activities being performed, and by whom, under each scheme.

  • OpenID facilitates user access to a permissioned container with bundled resources (e.g. web site access).
  • Oauth facilitates automated access to a permissioned resource within a container (e.g. CRUD ops on a file or record through a web api).

OpenID Connect, then, allows a user to access a web address and once in, gives the underlying web application a way to retrieve additional, off-site resources on the user's behalf.

To summarize: OpenID Connect is a federated identity API that includes a profile and extension of OAuth 2.0 that enables a client (i.e. mobile app or website) to redirect a person to a central identity provider for authentication, and enables that person to authorize the release of information to that client.

You should read my blog OAuth vs. SAML vs. OpenID Connect: https://gluu.co/oauth-saml-openid

The OpenID Connect API includes a number of endpoints, not all related to OAuth:

OAuth Endpoints

  • Authorization : Front channel website which renders the login page and authorization (consent) page. (RFC 6749)
  • Token : Back channel endpoint, normally requiring authentication, where a client can request access tokens, id_tokens, and refresh tokens. (RFC 6749)
  • Configuration : provider metadata published at .well-known/openid-configuration, including the location of endpoints, supported cryptographic algorithms, and other information needed by the client to interact with the OP. (RFC 8414)
  • Client registration : Endpoint for an application to create or update an OAuth client (RFC 7591)

Non-OAuth endpoints

  • Userinfo : Access token protected API at which the client can request claims about a subject. This is the Resource Server in OAuth terms.
  • JWKS : The current public keys of the OP used for signing and encryption
  • Session management : Used by all three OpenID logout specs (none working that well)
  • Webfinger : Used to bootstrap OP discovery working backwards from an email address (or other identifier), i.e. how do you figure out the configuration endpoint for a domain. (RFC 7033, but not part of the OAuth WG)
  • You mean, all this time, with all your answers, Gluu and OXD are your products? Please note that you must disclose your relationship to the links you provide and especially with the products you reference. I'm afraid that every reference to Gluu that you have posted is "promotion" and could be considered an ad. – schroeder Jul 9 at 7:22
  • Also, there is no need to pile onto an (old) answer and go on and on about how much you do not like it. Downvote and move on or provide constructive help on how the answer might be improved. – schroeder Jul 9 at 7:27

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.