2.3k VIEWS
Pinterest LinkedIn LINE

One reader of the ID book asked the striking question, “Why do we need access tokens? Couldn’t we just store passwords?” Come to think of it, I had not explained such a basic point. I will add it if there is an opportunity to revise the book, but for now I am posting it on the blog.

OAuth and Its 2 Tokens

OAuth has the following participants:

  1. Protected Resource: A resource whose access should be controlled
  2. Resource Owner: A person or organization capable of deciding access to a protected resource
  3. Authorization Server: Software that issues tokens (tickets) to a client according to the resource owner’s instructions
  4. Client: Software that accesses a protected resource with the resource owner’s authorization and performs some operation
  5. User-agent: Software such as a browser that the resource owner, as user, employs to interact with the system

These are the 5 actors.

The OAuth framework is a framework in which the authorization server issues the resource owner’s grant to the client for resource access as 2 types of storable “tokens (tickets).” The client receives and stores them, then uses one of them, the “access token,” to access the resource. Its fundamentals are defined by RFC6749 and RFC6750, documents established by the IETF standards organization.

The 2 types of tokens are access tokens and refresh tokens. The client stores them for later use.

An access token is used to access a resource. It represents the minimum necessary privileges. Its destination, or recipient, is the resource. Because it is used with multiple resources, and because resources generally have a lower level of protection than the authorization server, there is a meaningful risk of leakage. It is also usually a bearer token, so a stolen token can be used. To reduce this risk, access tokens are often valid only for a short time.

The other token, the refresh token, is used only with the authorization server, which is its destination. It is therefore less likely to be stolen. Moreover, because it is a sender-constrained token, even if it is stolen it cannot be used unless the client credentials are stolen as well. Its risk of theft and misuse is therefore substantially lower than that of an access token. For this reason, it is commonly valid for a long period. The client can use the refresh token to obtain a new access token. It is called a refresh token because it refreshes, or replaces, the access token.

I have made the following video explaining this with animation, so please take a look.

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

Why Not Store Passwords?

Now to the question at the beginning. The idea seems to be that instead of doing anything this complicated, each client, a shared client on the network, could store each resource owner’s username and password and thereby access the resource. In other words, OAuth would be unnecessary. (The resource also has a web interface that accepts users by receiving a username and password.)

There are many reasons why this is unacceptable.

  1. Storing the password gives the client all of the resource owner’s privileges. It is impossible to delegate limited privileges to the client. (Violation of the principle of least privilege)
  2. From the resource’s perspective, it cannot tell whether the party accessing it is the resource owner or the client. Effective risk management therefore becomes impossible. (Violation of the prohibition against impersonation)
  3. The resource can no longer be protected by advanced authentication such as passkeys. (Violation of the principle of appropriate authentication strength)
  4. The passwords of multiple resource owners must be stored on the network in reversible form, creating an unacceptable leakage risk. (Violation of the prohibition against reversibly storing passwords), and so on.

That is enough, right? Storing passwords is not acceptable.

The Version with Two High School Girls Talking at McDonald’s

It felt rather stiff, so I asked Claude.ai to create “the version with two high school girls talking at McDonald’s.” Here it is for your consideration.

Mai: Hey, hey, I just saw something online. Isn’t it crazy?

Yuka: What, what? What was it about?

Mai: Like, instead of using OAuth, a web app could just store everyone’s passwords. Then it could do anything on the site, and it would be easy and convenient to build, right?

Yuka: What!? Isn’t that seriously dangerous?

Mai: Exactly! But apparently it is totally unacceptable.

Yuka: Huh, why? It sounds convenient.

Mai: No, no, there are tons of reasons. First, if you hand over your password, you are basically entrusting everything to that web app.

Yuka: Wow, that’s way too dangerous! You couldn’t put any limits on it.

Mai: Exactly! And from the site’s perspective, it can’t tell who is accessing it.

Yuka: Seriously? It would be really confusing whether it was the person or the web app.

Mai: And apparently you also couldn’t use super-cool authentication methods like passkeys.

Yuka: What? Isn’t that so lame?

Mai: Right? And the worst thing is, everyone’s passwords would be stored online in a form that could be exposed.

Yuka: Wow, that’s terrifying! Absolutely not.

Mai: Exactly! So having a web app store passwords is totally out of the question!

Yuka: I see. So you should use OAuth properly. I learned something!

Related posts