.Nat Zone

Digital Identity et al.

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.

 - identity, OpenID Connect