An Introduction to the Difference Between OAuth Authentication (?) and OpenID for Non-Technical Readers [2023 Edition]

38.3k VIEWS

People have long said things like, “OpenID is authentication, while OAuth is authorization.” However, I get the feeling that quite a few people misunderstand what those words mean. I think the frequent appearance of claims like, “We don’t need OpenID anymore. OAuth alone is enough,” is evidence of that. “OAuth authentication” is another example.

So today, I would like to consider the difference between OAuth and OpenID.

Watch this video on YouTube.
Playing the video connects to YouTube.

YouTube version

Table of Contents

OpenID Is a Letter of Introduction; OAuth Is a Spare Key

First, let us review the basics of OpenID. Let us begin by revisiting what people mean when they say, “OpenID is authentication.”
“Authentication” is a very broad term used in many contexts, but when people say, “OpenID is authentication,” they mean that OpenID authenticates the identity of the person who has just arrived (user authentication). The flow is shown in Figure 1.

In this example, Ms. Arisu, the customer, visits Mr. Ibe’s site, which provides a service.

“Mr. Ibe, Mr. Ibe, I would like you to provide me with your service.”
“So your name is Ms. Arisu. I’m sorry, but I don’t know whether you really are Ms. Arisu. Could you please obtain a letter of introduction from Mr. Miyaki? And don’t forget to have your email address included in it.”
“All right.”
“Mr. Miyaki, I have a favor to ask.”
“Yes, what is it?”
“Could you write me a letter of introduction for Mr. Ibe that includes my email address?”
“Certainly, Ms. Arisu. Please take this with you.”
“Thank you.”
“Mr. Ibe, Mr. Ibe, I brought the letter of introduction.”
“Oh, this certainly is a letter from Mr. Miyaki. It appears that you really are Ms. Arisu. Now I also know your email address. Very well, I will provide you with the service.”

That is how it works. To prove to Mr. Ibe that she is Ms. Arisu, she asks the introducer (Identity Provider), Mr. Miyaki (“Google”), to write a letter of introduction, which she gives to Mr. Ibe. Thinking, “I can probably trust an introduction from Mr. Miyaki,” Mr. Ibe accepts that she really is Wakako Arisu and provides her with various services.

Next, let us look at a case that is described as using OAuth for authentication.

I called it “pseudo-authentication” in Figure 2 because an act that is not actually user authentication is being used in place of authentication. Here, to prove to Mr. Ibe that she is Ms. Arisu, she asks the building manager (OAuth Server), Mr. Tsuitta (“Twitter”), to make a spare key to her apartment, which has her nameplate on the door, and gives it to Mr. Ibe.

“Mr. Ibe, Mr. Ibe, I would like you to provide me with your service.”
“So your name is Ms. Arisu. I’m sorry, but I don’t know whether you really are Ms. Arisu. Could you give me a spare key to Ms. Arisu’s home? Then I can look inside the room and check whether you are Ms. Arisu.”
“All right.”
“Mr. Tsuitta, I have a favor to ask. I would like a spare key to give to Mr. Ibe.”
“Certainly. Please give him this key.”
“Thank you.”
“Mr. Ibe, here is the spare key.”
“Oh, thank you.”

Mr. Ibe uses the spare key to enter Ms. Arisu’s room and says,
“Well, I was indeed able to enter Ms. Arisu’s room. That means I will accept that you are Ms. Arisu.”
He then provides Ms. Arisu with various services.

The major difference from OpenID is this: with OpenID, Mr. Ibe merely has a letter of introduction, so even if he wanted to do something malicious, the most he could do would be to sell Ms. Arisu’s email address to a mailing-list broker. With OAuth, however, Mr. Ibe can enter Ms. Arisu’s home and do whatever he wants: read the love letters exchanged with her partner while saying, “Yay, I found love letters! Wow, so these are the kinds of photos you exchange,” break things, or send spam to Ms. Arisu’s friends. What? You think that could never happen? It actually happened with Twitter OAuth authentication: ¹. Apps had been given unrestricted access to DMs. It was fixed immediately, though.

If Ms. Arisu knows Mr. Ibe well and can truly trust him, that is fine. For example, in my household, we give a spare key to the person who cleans our home. This is both extremely convenient and entirely legitimate. But going around logging in to websites you barely know using OAuth pseudo-authentication is the equivalent of scattering spare keys everywhere you go, and it is extremely dangerous. You can see why, both now and in the past, more sites have wanted to use OAuth authentication rather than OpenID: having a spare key is more convenient for providing various services—or for doing malicious things. But someone who has a spare key is not necessarily a resident of the home. In many cases, they are not. That is why “OAuth authentication” does not constitute user authentication.

Authenticating Correctly with OAuth: OpenID Connect

By now, I think you understand that using Twitter OAuth for “pseudo-authentication,” for example, is extremely dangerous. To perform authentication alone correctly, it is best to use a letter of introduction. In OpenID Connect (OIDC), this letter of introduction is called an ID Token.

An ID Token can contain many kinds of information. In addition to the person’s name and email address, it can convey when and how the user’s identity was actually verified (such as who used a driver’s license, when, and on what basis), and how the user was authenticated (through SMS authentication, a passkey, and so on). This information about “what kind of verification was performed” is not so much information about the person as information (metadata) about the person’s identity verification and user authentication. Without it, the actual security level of that user authentication cannot be determined. OpenID Connect therefore makes it possible to include this information in the letter of introduction as well. This is the flow shown in Figure 3 through step 4.

In addition to the letter of introduction, it is also possible to check the person’s current status later. This is achieved by providing, along with the letter, a key (an Access Token) to a locker dedicated to Mr. Ibe that contains only a copy of Ms. Arisu’s status report intended for him. Using this key, Mr. Ibe can learn about Ms. Arisu’s current status as needed. This locker is called the “UserInfo Endpoint.” It is an OAuth Protected Resource. Because it exists, Mr. Ibe can learn about Ms. Arisu’s current status even when the user is not present.

In this way, OpenID Connect uses an ID Token to convey authentication information about the user who has just arrived, while also making it possible to check the user’s current status safely at a later date using OAuth. This is why OpenID Connect is called an identity layer on top of OAuth.

Distributed Claims and Aggregated Claims

Distributed Claims

Mr. Ibe’s dedicated locker can contain not only the paper describing Ms. Arisu’s current status, but also other things she wants to give him. These might include, for example, a credential received from a third party or keys to other lockers. Mr. Ibe can then use a key retrieved in this way to visit another locker and retrieve the information stored there. Figure 4 illustrates this relationship.

In OpenID Connect, this model of going to retrieve information from other lockers is called Distributed Claims. “Claim” may sound unfamiliar; in Japanese, the borrowed word can sound like it means a “complaint,” but it has no such nuance in English and simply means an “assertion.” Here, each attribute is called a “claim” because it is a value that the respective site asserts to be correct. That is what a letter of introduction does, after all.

Sites X, Y, and Z are OAuth Protected Resources. In OpenID Connect, the UserInfo Endpoint also contains keys that Mr. Ibe can use to access each site, allowing him to access those sites and retrieve the latest information.

Aggregated Claims

There is also a method called Aggregated Claims. Figure 5 illustrates it. Here, the UserInfo Endpoint uses keys (Access Tokens) that Ms. Arisu obtained in advance to access Sites X, Y, and Z and retrieve claims; it then aggregates those claims and returns them to Mr. Ibe.

Summary

So, to summarize:

OpenID Connect is a distributed identity architecture that uses OAuth not only to perform user authentication safely, but also to exchange a variety of information scattered across the Internet and enable services to be provided. As of 2023, it is so widespread that it is said virtually everyone who uses the Internet uses OpenID Connect. “Sign in with Apple,” “Sign in with Google,” and “Sign in with Microsoft” all use OpenID Connect. The slogan “the identity layer of the Internet” is not so far from the truth.

Revision History

First edition: May 15, 2011 6:05 PM
Edition 2: June 8, 2023 1:00 AM
Edition 2.1: June 8, 2023 11:10 AM

Footnotes

Twitter to Automatically Remove Apps’ Access to DMs (2011-05-19)

On May 19, I Will Deliver a Keynote at EIC 2026 in Berlin, Titled “When Software Becomes Staff: Governance, Security & Safety for Agentic AI”

On the first day of EIC 2026, I will deliver the keynote “When Software Becomes Staff: Governance, Security & Safety for Agentic AI.”

AI · 2026-04-28

I Will Appear on the Okinawa Open Days Panel “Current and Future OSS Initiatives in Economic Security”

It is already the day of the event—in fact, I am writing this now (12/4 9:45) at my desk while preparing for the panel—but I will…

Events · 2025-12-04

We Submitted Public Comments on the FSA’s Proposed Partial Amendments to the “Comprehensive Guidelines for Supervision of Financial Instruments Business Operators, etc.”

The U.S.-based OpenID Foundation submitted the following public comments on the Proposed Partial Amendments to the “Comprehensive Guidelines for Supervision of Financial Instruments Business Operators, etc.”…

Identity · 2025-08-19