Fig.3 OpenID Connect Authentication

Dummy’s guide for the Difference between OAuth Authentication and OpenID

Many people say that “OpenID is Authentication and OAuth is Authorization.” However, people often mis-understand the phrase. Such phrase like “OpenID is dead. OAuth authentication is better” depicts it well.

So, today, I would like to think a bit on the difference between OAuth and OpenID.

OpenID is a referral letter, OAuth is a valet key

Let us recap OpenID first. What does “OpenID is authentication” mean?

“Authentication” is a word used for many purposes, but in our case “OpenID is authentication” really means “OpenID attests an identity of the person who is at the site.” Figure below depicts the flow.


Fig. 1  OpenID Authentication

 In the figure, Alice attests Eve her identity by showing the referral letter written by a notary (Identity Provider) Google. Since Eve asked for it, Alice’s email address is also on the letter. Even things “Ok, Google says that she is Alice, so I will believe it” and accepts her as “Alice de Wonderland” and provides various services to her.

Next, let us see what happens with “OAuth Authentication”.

Fig.2  Pseudo-Authentication using OAuth

I wrote “Pseudo-Authentication” in Fig.2 because it is using what is not an authentication process to emulate authentication. Here, to prove that she is Alice, Alice asks the Apartment Controller (OAuth server), “Mr. Twitter”, to create a valet key for Alice’s apartment and hands it to Eve. Eve enters Alice’s apartment using this key and thinks “OK. Now I am in Alice’s apartment. That really was a key of Alice’s apartment. I shall recognize that she really is Alice.” And he starts providing services to Alice.

The main difference is that in the case of OpenID, since it was just a referral letter, the worst Eve can do is to sell the mail address to a spammer while in case of OAuth, Eve can enter Alice’s apartment and read her love letters to her boy friend, spam her friends, etc[*1]. If Alice knows Eve well, and Alice trusts Eve, that may be OK. For example, I have handed a key to my house to my house cleaner so that she can clean my house while I am not there. This is very convenient, useful, and proper thing to do. However, signing in to a web site that you do not know well using pseudo-authentication of OAuth is same as spreading your valet key everywhere and that is very dangerous. Now you see why many sites want OAuth “authentication” rather than OpenID. Having a valet key is much more useful than a referral letter to provide services or doing something bad for you.

How to “Authenticate” properly using OAuth – OpenID Connect

Now you understand that it is very dangerous to randomly authenticate yourself to the sites using plain OAuth [*1]. Then, what should we do to authenticate safely and properly using OAuth? What about just handing a valet key to a locker that only has a copy of the letter of referral instead to your apartment?

In this case, even the worst happens, you only lose the copy of referral letter. The damage is not so different than the case of OpenID.

This indeed is the basic idea behind “OpenID Connect.”

The locker is called “UserInfo Endpoint.” This allows a site to verify the user’s identity information using OAuth 2.0. This is why OpenID Connect is often called “an identity layer on OAuth.”

UserInfo is good but it only tells the site the user information. It does not tell how the user was authenticated (e.g., OTP, Client Certificates, etc.). Information like “What kind of identity vetting and authentication was done” is meta-data about the user rather than the user information. Unless we know them, we cannot tell how trustworthy the authentication is. Thus, OpenID Connect also sends the letter containing “how and when” the authentication was performed, together with the UserInfo locker key. This letter is called “id token”. (Alternatively, you can ask ID Token endpoint to obtain it later.)

Fig.3 OpenID Connect Authentication
Fig.3 OpenID Connect Authentication

The key handed to Eve here is only good for the locker prepared for Eve. In it is the letter that contains Alice’s basic information. You can add any other things that you want to hand to Eve in the locker. For example, you can put a certificate of qualification, or even keys to other lockers. Putting various letters / certificate (they are called “claims” in our terminology) is called “Claims aggregation.” Putting keys to other lockers form which Eve can get additional information is called “Distributed Claims”.

Fig.4 OpenID Connect's Clams aggregation and distributed claims.
Fig.4 OpenID Connect’s Claims aggregation and distributed claims.


The way Eve accesses site X,Y,Z is same as the Resource Accesses of OAuth 2.0. However, there is a subtle difference in the way key is created. In a standard OAuth, the key is created by the each site. In OpenID Connect, the keys are created by the UserInfo Endpoint. In another word, site X,Y,Z knows how to understand the keys provided by the UserInfo endpoint. For this to happen, the sites must (1) Trust the key providing party (2) be able to verify the validity of the keys. To achieve this, OpenID Connect uses JSON Web Token (JWT) as the format for the key (Access Token) using some cryptography, but this is beyond the scope of this document. For now, just remember that OpenID Connect can serve the sites with cached “letters” or give pointer from which the site can obtain the required information.

OpenID Connect is a distributed identity framework on top of OAuth that not only allows safe authentication but also make it possible for the sites to move the distributed data in the internet and provide better services.

[*1] Indeed, twitter allowed any apps that the user authorized to read all his direct messages (DMs) until the end of June, 2011.

(from Berlin)

This article was translated from the original Japanese blog entry to English at Keystone, CO on July 18.

26 Replies to “Dummy’s guide for the Difference between OAuth Authentication and OpenID”

  1. There might be a typo on Fig 4: OpenID Connect’s Clams Aggregation, should it be “OpenID Connect’s Claims Aggregation”?

  2. Nice explanation, Nat. But i have a few queries.

    1. What open ID connect provide on the Top of OAuth 2.0? Is this only the distributed identity framework ? If yes then difference distributed identity framework make?

    2. OAuth 2.0 also provide only those attributes for which the End user has aloowed the Site. Then What difference User Info End make in Open id Connect which is also providing the same data to SIte?

    The only difference i can figure out in OpenID connect and OAuth 2.0 is providing the ID Token endpoint which provide us more details around the authentication.

    Please share your thoughts. Let me know incase you need any other info from my side.



    1. OAuth 2.0 does not provide anything on user identity or attributes.
      It does not define such things.
      The attributes you are getting from bunch of providers as “OAuth” is their proprietary API output that uses OAuth 2.0 or something similar.

      I repeat. OAuth defines nothing on attributes nor identity.
      If you think it does, you are mistaken. Go read RFC6749.

      OpenID Connect standardized the attributes/claims and how they are to be generated with an authentication event.

  3. OK, nice article, but I still don’t get why this is called OpenID Connect and not OAuth Connect as it fills a gap in OAuth. It builds upon the idea of OpenID, but in the end it turns OAuth into an authentication provider and hardly has any affinity with OpenID, at least not more than with SAML. I like the way the problem is presented here. Giving a valet to my referrals but to me it seems I still have no control over what is stated in my referral.

    1. “OpenID” portion signifies the SDO and the IPR regime that this standard is under. Besides the WG that worked on this standard predates OAuth WG at IETF, it actually is good to have stricter IPR regime to foster the interoperatiliby. In case of OAuth, you could still call something that is not OAuth as an OAuth. We do see something like that going on in the wild. It has not been perceived as a big problem since in most case OAuth is hub and spoke: you program against an OAuth server. In case of OpenID Connect, it is a mesh. An RP talks to many OpenID Provider and vice versa. So interoperability was very important and being able to deny the label of “OpenID Connect” if it is not interoperable as trademark license violation was a good thing.

      From the feature point of view, OpenID Connect still has dynamic registration and discovery feature, which were the main features of OpenID Authentication 2.0, by the way.

      Re: referral: If you feel that you do not have good control over what is stated in your referral, then you should stop using that IdP. You are not trusting it. The IdP is supposed to be a trusted party from the point of view of the user. If you cannot trust the IdP, you had better not use it.

      1. I agree with the first part of your answer. It’s an area with which I’m not really familiar but it does seem to make sense.
        But for the second part, no, I can’t live with that. I want a solution in which I can enforce my own DR (Digital Rights) statement. So, yes, I can share any private data with Google, Facebook or whoever, but only in an encrypted way. But I want to have control over with whom I share the decryption keys. And these keys go into the Access Token and should somehow be restricted to the IdP and in time.
        So, I decide e.g. what piece of data is my physical address and with whom I want to share it. For the IdP it’s only an encrypted blob.
        I don’t have all the answers, but I’m sure the technology is there to make this happen.

        1. I can understand your “wants” of protecting your data by encryption.

          Now, there is a catch.

          You said you want to share decryption keys with whom you decided to provide the data.

          If you share a key among multiple party, I regard it as not secret any more. To be secure, the key can be shared by at most two parties, and preferably be accessible by only one party.

          Moreover, in many cases, you cannot use the same key twice because that would undermine the security. So, you need to encrypt the data for each party each time always afresh. i.e.l, there has to be a component that decrypts the data and re-encrypts the data with a fresh key.

          In OpenID Connect, this happens at the IdP because in general you cannot trust the browser for the key storage right now. (That’s why we asked browser people to develop WebCrypto API. Once that gets ubiquitous, the situation would change.)

          This in turn means that IdP (or more correctly, an attribute provider) is decrypting the data and is able to see your data. So, your requirment of “an attribute provider (IdP) MUST NOT see the raw data” is not achievable technically. Instead, what you need to do is to contractually bind them or otherwise trust them.

          The other option is to operate the crypto portion yourself. OpenID Connect explicitly has modes for that.

          One is called Self-Issued provider. This typically lives in your smartphone as an app, but it can be on your PC as well. See for more details.

          The second option is to operate the IdP yourself. It is perfectly fine to do so Problem is that not many RPs are willing to put such an OP as the clickable icon on their login screen. Hopefully, they will adopt WebFinger or AccountChooser pretty soon so that this will become less of the problem. One of the biggest problem here though is how to security operate the authentication bit. It is non-trivial.

          The third option is to use the distributed claim mode in which you operate an attribute provider yourself. This way, you do not have to operate the authentication bit. Problem of this mode is that I see not many IdPs would be supporting this feature. I expect this to proliferate in the end since data source can never be consolidated but it will take time.

          There were other potential technologies that we have looked at which may come closer to what you want while desigining OpenID Connect. However, we have opted in the current design in consideration of many factors including IPR freedom and ease of implementation. The later is quite important to make it actually useful. Even if the technology was perfect, what is the use of it if nobody implements it?

          So, that’s where we are now technologically.

  4. I have read a lot on all the nice behind the scenes parts of openID Connect but no one seems to explain the basic interface part of things and its now 2015, two years from the last post. 1) Will a user see the difference between this and oauth or from what i believe, this is not transparent to the user. 2) How do i actually use it? Because i believe its the same set of nascar buttons that are being used. (So if the rp does not support my idp it wont work). Or am i wrong? Can openID connect be called in a different way and function even when the rp does not support my idp? An mostly please put up a video showing this signon process if its any different. I have seen enough of the back end details and i get that part.

    1. A.1 From the pure end-user point of view, you will not see the difference.
      However, if you look at the redirect uri, you will see “openid” there in “scope” parameter if it is.

      A.2 It could be either through NASCAR, Account Chooser, or input box where you put your email like address.
      The last one will not work unless your IdP supports dynamic registration and your RP supports it.

  5. You might want to consider improving your mobile responsiveness… (desktop version seems
    fine but the mobile version is a bit glitchy on my end.
    Something is wrong with the scrolling.
    When was the last time you checked on the mobile responsiveness
    of your blog?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.