169

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.

Xander
  • 35,525
  • 27
  • 113
  • 141
user960567
  • 2,461
  • 4
  • 16
  • 16

7 Answers7

203

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    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
  • 23
    "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
  • 1
    @ThomasPornin: Wouldn't you say that OAuth is about authorization AND authentication? Because authentication is always the base of a successful authorization, isn't it? Although in your example of OAuth (at least in the Authorization Grant Type) authentication takes place on the server of entity B where authorization is done on Server S. Right? – pfust75 Oct 30 '13 at 06:53
  • @ThomasPornin, Hey expert please check this, there are lot of confusion out there, http://security.stackexchange.com/questions/44843/how-secure-is-redirecting-user-from-http-normal-bank-com-to-https-secure-ban/44880?noredirect=1#44880 – user960567 Nov 04 '13 at 05:35
  • 5
    @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 00:12
  • It seems this distinction: "OpenID is a protocol for authentication while OAuth is for authorization" is no longer valid. Google use OAUTH 2.0 for both authentication and authorization now (https://developers.google.com/accounts/docs/OAuth2Login) – GayanSanjeewa May 19 '14 at 01:34
  • 1
    @GayanSanjeewa And [now they don't](https://developers.google.com/accounts/docs/OpenID#shutdown-timetable). – BenV Jan 03 '15 at 21:25
  • OK, so A is the Consumer and B is the ID-provider. What is Server S? – Johan Jan 21 '15 at 10:34
  • @BenV according to the page you linked, Google now uses ONLY OAuth 2.0 functionality within OpenID Connect. They've stopped supporting OpenID 2.0 in favor of OAuth 2.0 merely because the latest version of OpenID has support for OAuth, without making it clear to the user the apparent vast differences that I'm still trying to figure out. This would seem to suggest OpenID in and of itself is no longer used?? – Ber Sep 25 '16 at 07:56
  • According to [the link](https://developers.google.com/accounts/docs/OpenID#shutdown-timetable) BenV provided, OpenID Connect does not even support a separate OpenID protocol anymore. Instead it is a pseudo-authentication layer built entirely on OAuth 2.0, requiring the user give the site access to his e.g. Google account and allowing both sites to monitor the users' activity of the other. Is this true?? Does OpenID exist as a separate protocol anymore? – Ber Sep 25 '16 at 08:18
  • So OpenID is about letting users log in using another service. OAuth is about letting some server do stuff on your behalf. Right? In some sense, they seem to be going in opposite directions. – jpmc26 Aug 22 '18 at 02:09
  • Great explanation! I was using OAuth to Authenticate. You saved my day man! – bruno.bologna Oct 05 '18 at 18:21
108

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 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.
Community
  • 1
Shaun Luttin
  • 1,423
  • 3
  • 12
  • 13
  • 3
    Thanks for this great answer Shaun. The historical perspective and easy-to-read scenarios clarify a lot of confusions. – Hakan Serce Jan 03 '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 05 '17 at 11:25
60

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

OpenID_vs._pseudo-authentication_using_OAuth

Courtesy Wikipedia

KyleMit
  • 119
  • 7
Vrashabh Irde
  • 719
  • 5
  • 5
  • Why couldn't someone snap up the certificate in the OpenID Authentication and pretend to be the authenticated user? – ptf Sep 30 '16 at 08: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
12

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.

Pace
  • 221
  • 2
  • 3
11

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 :)

Guillaume
  • 210
  • 2
  • 6
  • 2
    Yes, I thought the same. If we try to grant the user access to resources then it should be handled in a different way because it is not a delegation like what oauth2 does – Barış Velioğlu Jan 19 '20 at 20:15
4

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)
Mike Schwartz
  • 261
  • 2
  • 2
  • 1
    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 09 '18 at 07:22
3

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.

johnaweber
  • 31
  • 1