It has long been said that "OpenID is authentication and OAuth is authorization." However, I feel that there are quite a few people who misunderstand the meaning of these words. I think that the evidence of this is the frequent discourse that "We don't need OpenID anymore. OAuth is enough." OAuth authentication is one such example.
So today, I would like to consider the differences between OAuth and OpenID.
OpenID is a letter of introduction, OAuth is a duplicate key
First, let's review the overview of OpenID. Let's first review what the phrase "OpenID is authentication" means.
"Authentication" is a very broad term that is used in many different situations, but when you say "OpenID is authentication," it means "OpenID authenticates the identity of the person who is currently visiting" (user authentication). The flow can be illustrated as shown in Figure 1.
In this example, Alice goes to Ibe's website, where she provides services as a customer.
"Ibe-san Ibe-san, I would like you to provide a service for your home."
"You say your name is Arisu-san. I'm sorry, but I'm not sure if this is really you, Arisu-san, so could you please get a letter of introduction from Miyaki-san? Don't forget to include an email address on the letter of introduction."
「わかりました。」
"Miyaki-san, I have a favor to ask of you."
"Yes, what is it?"
"I would like you to write a letter of introduction for Ibe-san, including his email address."
"I understand, Arisu-san. Then please take this."
"thank you."
"Ibe-san, Ibe-san, I've brought you a letter of introduction."
"Oh, it's definitely a letter of introduction from Miyaki-san. You certainly seem to be Arisu-san. I also got your email address. Now, let me provide you with my service."
It goes something like this. In order to prove to Ibe that she is Alice, Alice gets her identity provider Miyaku (Guuguru) to write her a letter of introduction, which she gives to Ibe. Thinking that "I can trust an introduction from Miyaku," Ibe recognizes that Alice is really Alice Wakako and provides her with various services.
Next, let's look at the case where authentication is performed using OAuth.
The reason why it is called "pseudo authentication" in Figure 2 is because an action that is not actually user authentication is used instead of authentication. Here, in order to prove to Ibe that she is Alice, she has Tsuitta, the manager (OAuth Server), make a duplicate key for the apartment room with her nameplate on it, and gives it to Ibe.
"Ibe-san Ibe-san, I would like you to provide a service for your home."
"You say you're Alice-san. I'm sorry, but I'm not sure if you're really Alice-san, so could I have the spare key to your house? Then I can look around the room to make sure you're Alice-san."
「わかりました。」
"Tsuita-san, I have a favor to ask of you. I would like a spare key to give to Ibe-san."
"Okay, then give me this key."
"thank you very much."
"Ibe-san, here's the spare key."
"Oh, thank you."
Ibe-san used this key to enter Alice-san's room,
"Oh, you did indeed enter Alice's room. That means I'll have to admit that you are Alice."
and provides a variety of services to Arisu.
The big difference with OpenID is that with OpenID, it's just a letter of introduction, so even if Ibe wanted to do something bad, the most he could do is sell Alice's email address to a list broker, whereas with OAuth, Ibe could go into Alice's house and read the love letters exchanged between her and her boyfriend, saying, "Wow, I found some love letters. Wow, so they're exchanging photos like this," or he could break things, or he could send spam to Alice's friends, or he could do whatever he wanted. What? You think that can't be true? No, that's actually what happened with Twitter's OAuth authentication.1I had unlimited access to DMs. I fixed it right away.
If Arisu knows Ibe well and can really trust him, that's fine. For example, in my house, I give a duplicate key to the person who cleans my house. This is very convenient and a good thing. However, logging in to websites you don't know well using OAuth-like authentication is like walking around with duplicate keys scattered all over the place, which is very dangerous. You can see why there are more and more sites that want OAuth authentication rather than OpenID, both now and in the past. It's because it's more convenient to provide various services and do bad things if you get a duplicate key. However, the person who has the duplicate key is not necessarily the resident of the house. In many cases, it's not. Therefore, "OAuth authentication" does not become user authentication.
How to properly authenticate with OAuth: OpenID Connect
Now, I think you understand that it is very dangerous to perform "pseudo authentication" using Twitter's OAuth, for example. To perform proper authentication, it is better to use a letter of introduction. In OpenID Connect (OIDC), this letter of introduction is called an ID token.
Various information can be written in an ID token. In addition to the person's name and email address, information such as when and how the user actually verified their identity (using a driver's license, who, when, and on what basis, etc.) and user authentication (SMS authentication, passkey, etc.) can also be written and sent. This "verification" is not information about the person, but rather information (metadata) about the person's identity verification and user authentication. Without knowing this information, it is actually impossible to know how secure the user authentication is. That is why OpenID Connect makes it possible to send this information together in a letter of introduction. This is the flow up to step 3 in Figure XNUMX.
In addition to the letter of introduction, we also make it possible to check the current status of the person later. This is achieved by handing over the letter of introduction along with the key (access token) to Ibe's personal locker, which contains only a copy of Alice's current status explanation for Ibe. Using this key, Ibe can find out about Alice's current status as needed. This locker is called the "UserInfo Endpoint." It is a protected resource for OAuth. With this, Ibe can find out about Alice's current status even when the user is not present.
In this way, OpenID Connect uses ID tokens to pass the user's authentication information and then allows secure confirmation of their current status at a later date using OAuth, which is why OpenID Connect is called an identity layer on top of OAuth.
Distributed and Aggregated Claims
Distributed claims
In this locker for Ibe-san's use, not only does it contain a paper with Alice's current status written on it, but it can also contain other things that you want to give to Ibe-san. For example, a certificate of qualifications given to you by a third party, or keys to other lockers. Ibe-san can use the keys he retrieves in this way to go to other lockers and retrieve the information stored there. Figure 4 shows this relationship.
In OpenID Connect, this model of retrieving information from other lockers is called Distributed Claims. The word "claim" is unfamiliar to most people, and in Japanese it sounds like a "complaint," but in English it does not have that nuance and simply means "assertion." Here, each attribute is called a "claim" because it is a value that each site claims to be correct. That's what a letter of introduction is like.
Sites X, Y, and Z are OAuth Protected Resources. In OpenID Connect, the keys that Ibe needs to access each site are also stored in the UserInfo Endpoint, and Ibe can use these keys to access these sites and retrieve the latest information.
Aggregate claims
On the other hand, there is also a method called Aggregated Claims, which is shown in Figure 5. In this case, the UserInfo Endpoint accesses sites X, Y, and Z using the key (access token) that Alice obtained in advance to retrieve the claims, aggregates them, and returns them to Ibe.
My Feelings, Then and Now
So that's the summary.
OpenID Connect is a distributed identity architecture that not only securely authenticates users using OAuth, but also enables the exchange of various information scattered across the Internet and the provision of services. As of 2023, it has become so widespread that it is said that there is almost no one who uses the Internet who does not use OpenID Connect. "Sign in with Apple," "Google Sign in," and "Microsoft Sign in" are all OpenID Connect. The catchphrase "The Identity Layer of the Internet" is not a lie.
Change log
- First published: May 2011, 5 15:6 PM
- 2nd edition: June 2023, 6 8:1 AM
- Version 2.1 June 2023, 6 8:11 AM
Related article
- Participating in the panel "Current Status and Future of OSS Initiatives in Economic Security" at Okinawa Open Days
- Public comments have been submitted to the Financial Services Agency regarding the partial revision (draft) of the "Comprehensive Supervision Guidelines for Financial Instruments Business Operators, etc."
- The final version of OpenID for Verifiable Presentation 1.0 has been published.
- 🚀 It's finally here! Final specification review for FAPI 2.0 Message Signing has started!
- 🎉 A new era for OpenID has begun! A historic achievement: ITU-T standardization
- OpenID Workshop Update
- The Evolution of Digital Identity: Important Changes to OpenID4VP
- GOV.UK Wallet and One Login
- March 3th Global Trends in FAPI and VC - FAPI4 & Verifiable Credentials
- I am running for the OpenID Foundation Board of Directors in 2025
Wow. I'm a non-technical person so this was really easy to understand.
The fact that Twitter's OAuth doesn't allow for fine-grained authorization is a problem with Twitter, not with OAuth, right?
I think it is normal for general OAuth servers to allow detailed authorization. For example, Facebook, Mixi, etc. are like that. Is it possible to grant authorization to only view basic profiles? In that case, there should be no problem in using it as a substitute for authentication.
In particular, since you are the chairman of the OpenID Foundation, this article seems to be FUD against OAuth in order to promote OpenID Connect. What are your thoughts on this?
If you read it carefully, you will understand that the purpose of this document is to make people properly understand the difference between authentication and authorization. To make this clear, I have given the example of Twitter's OAuth authentication to make people realize that it is not good to use authorization instead of authentication too easily. On top of that, I say that if you use an authorization framework for authentication, you should first carefully consider the scope (there is currently a tendency to give too broad permissions), and that the scope should be standardized. Also, it is actually not enough to use it for authentication, and so-called authentication context is also required. If the expression of this is not standardized, it will be very inconvenient. Also, a standardized identifier system is necessary to function as a distributed system. OpenID Connect is intended to realize these as an extension of OAuth.
As mentioned above, OpenID Connect is an extension of OAuth 2.0. There is no incentive to FUD OAuth, as you would be shooting yourself in the foot.
Speaking of positions, I am the Chair of the OpenID Foundation, but at the same time, I am one of the contributors to OAuth2.0. I know Eran, Dick, and David, the authors of OAuth 2.0, very well (← Eran created XRD1.0 together. Dick and David are together at the OpenID Foundation), and I also know Mike, the author of OAuth 2.0 Bearer Token, very well (I wrote JWT and Connect together). In that sense, I have no intention of disparaging OAuth.
However, I think it is not FUD or anything but the fact that OAuth should not be used for authentication. If we do not take proper measures, OAuth itself will be branded as a bad protocol. We must avoid that.
Easy to understand explanation, thank you!
I was just researching OpenIDConnect, so this was easy to understand and helpful!