Difference Between OAUTH, OpenID and OPENID Connect in very simple term?

Question

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.

Answer 1

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.

Answer 2

Simple Terms

1. OpenID is about verifying a person's identity (authentication).
2. OAuth is about accessing a person's stuff (authorization).
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 [email protected] 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.

Answer 3

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

Courtesy Wikipedia

Answer 4

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.

Answer 5

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 an Authentication Delegation or 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 :)

Answer 6

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)

Answer 7

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.