*

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

Date: : Last modified:2014/03/02 identity, OpenID Connect

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.

Ads by Google

関連記事

no image

OAuth 2.0 Mobile WebApp Flow

In February, I have posted an article about oauth_

Read more

no image

Is expressing Levels enough for LoA2+?

LoA stands for Level of Assurance. Most popular

Read more

no image

Alice to Bob resource sharing

So I was in UMA call today and that reminded me of

Read more

no image

URI Template in OpenID Connect Provider Configuration Response

OpenID Connect Provider Configuration Response for

Read more

no image

Workshop: Online Constituent Identity

Uniting the identity and citizen engagement softwa

Read more

OpenID Connect Provider Testing

OpenID Connect Test Facility Preview Available

Andreas Åkre Solberg and Roland Hedberg from Fedla

Read more

openid-icon-250x250

What to read when you want to build OpenID Connect

OpenID Connect has many components. Sometimes, it

Read more

no image

JSON Signature and Encryption Spec.

At IIW 2010B, we had a major advancement in the JS

Read more

no image

JSON Schema enhanced OAuth

In the previous post, I wrote about HAL enhanced O

Read more

openlabs.go.jp

Japanese government went live with OpenID/AB

Japanese government went live with OpenID Artifact

Read more

Ads by Google

  • Matt Tebo

    Nice summary Nat.

  • Pingback: Dummy’s guide for the Differ… « oracle fusion identity()

  • Pingback: Litte - tvorba stránek » Ohlédnutí za IETF 83()

  • Pingback: Matching Google Cloud ID to Cloud End Points – Canada Cloud()

  • Pingback: Personal Cloud EMR – Matching Google Cloud ID to Cloud End Points – Cloud Computing Best Practices()

  • Pingback: Google+ Sign-In:联合身份认证、授权和语义活动流 | 技术宅改变世界()

  • Jin Wen

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

    • http://www.sakimura.org Nat Sakimura

      Right. Although I love clams, especially littleneck clams, the figure is wrong. It is Claims.

  • Tosheer Kalra

    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.

    Thanks

    Tosheer.

    • http://www.sakimura.org Nat Sakimura

      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.

  • Abdulaziz Algublan

    It is really amazing article that points the differences between Auth and OpenID.

    Thanks

    • http://www.sakimura.org Nat Sakimura

      Thanks!

  • Petra Van OOrsel

    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.

    • http://www.sakimura.org Nat Sakimura

      “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.

      • Petra Van OOrsel

        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.

        • http://www.sakimura.org Nat Sakimura

          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 http://openid.net/specs/openid-connect-core-1_0.html#SelfIssued 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.

  • Pingback: My take on RESTful authentication | No silver bullet()

  • Pingback: Læseliste | Christian Lysdahl()

  • Pingback: Does the tussle between OpenID and OAuth really amount to much? - Smart421()

  • Pingback: What's in a Name? Or a version number come to that - Smart421()

Ads by Google

Sato no aki
Autumn Greetings from Japan

Japan is now fully in Autumn. Leave

openid-icon-250x250
draft 02 of OpenID 2.0 to Connect Migration is now available

OpenID 2.0 to OpenID Connect Migrat

UMA-logo
Public Review of UMA 0.9 is going on

June 24: The three main UMA Version

CCS Injection
New vulnerability on OpenSSL found

A new bug in OpenSSL was found by M

no image
Covert Redirect is not new but.. A risk analysis and recommendations

So, there has been a flurry of worr

more...

PAGE TOP ↑