One of the readers of the ID book asked me the powerful words, "Why do we need an access token? Can't we just save the password?" Oh, come to think of it, I didn't explain such a basic thing. So, I'll add it if I have the opportunity to revise it, but for now I'll post it on my blog.
OAuth and Two Tokens
OAuth's participants include:
- Protected Resource: A resource to which access should be controlled.
- Resource Owner: A person or organization that can make access decisions about protected resources.
- Authorization Server: Software that issues tokens (tickets) to clients according to instructions from resource managers.
- Client: Software that accesses protected resources and performs some processing with the permission of the resource administrator.
- User-agent: Software that allows a user (resource manager) to interact with a system, such as a browser.
There are five actors:
The OAuth framework is a framework that compiles a method in which the resource administrator issues a resource access grant to a client as two types of storable "tokens (tickets)" that the authorization server issues, and the client that receives them stores them and uses one of them, an "access token," to access resources. The basics are defined by RFC6749 and RFC6750, documents established by a standards organization called the IETF.
The two tokens are an access token and a refresh token, which the client stores for later use.
Access Tokenis a token used to access resources. It represents the minimum authority required. The destination (recipient) is the resource. Since it is used for multiple resources and the protection level of resources is usually lower than that of the authorization server, there is a certain risk of leakage. Also, since it is usually a bearer token, a stolen one can be used. To reduce this risk, it is often only valid for a short period of time.
Another token =Refresh Tokenis only used for the authorization server (destination of use = authorization server). Therefore, the possibility of it being stolen is low. Moreover, since it is a sender constrained token, even if it is stolen, it cannot be used unless the client credentials are stolen as well, so the risk of it being stolen and used is significantly lower than that of an access token. For that reason, it is common to keep it valid for a long period of time. The client can use this refresh token to obtain a new access token. It is called a refresh token because it refreshes the access token.
Please take a look at the video below which uses animation to explain this.
Is it okay to save the password?
Now, regarding the question at the beginning, it seems that you don't need to go through all this trouble, and if the client (a shared client on the network) stores the username and password of each resource administrator, they can access the resource. There's no need for OAuth. (The resource also has a web interface that accepts the username and password and accepts users.)
I can give you a number of reasons why it's a bad idea.
- The way passwords are stored gives all the authority of the resource administrator to the client. It is not possible to delegate limited authority to the client. (Violation of the principle of least privilege)
- From the perspective of the resource, it is not clear whether the person accessing the resource is the resource administrator or a client. This makes it impossible to effectively manage risk. (Violation of the principle of prohibiting impersonation)
- Resources cannot be protected by advanced authentication (passkey, etc.) (violation of the principle of appropriate authentication strength)
- The passwords of multiple resource administrators must be stored in a reversible form on the network, and the risk of leakage cannot be ignored. (Violation of the principle of prohibiting reversible storage of passwords) etc.
Enough now, right? Password storage is no good.
The version where two high school girls were talking at McDonald's
Since it seemed a bit stiff, I asked Claude.ai to create a version that sounds like "two high school girls talking at McDonald's," so please take a look.
Mai: Hey hey, I just saw it online, isn't it amazing?
Yuka: What? What are you talking about?
Mai: I thought, if a web app could just store everyone's passwords instead of using OAuth, you could do anything on the site, and it would be easy to make and convenient.
Yuka: What? Isn't that really scary?
Mai: That's right! But that's totally wrong.
Yuka: Eh, why? It seems convenient.
Mai: Well, there are a lot of reasons. First of all, if you give your password to the web app, you're basically leaving it all up to them.
Yuka: Wow, that's too dangerous! There's no way to put any restrictions on it.
Mai: That's right! And then, from the site's perspective, it becomes impossible to know who is accessing it.
Yuka: Seriously? I'd get totally confused as to whether it was the person or the web app.
Mai: What's more, you won't be able to use super cool authentication methods like passkeys anymore.
Yuka: Eh, isn't that just too lame?
Mai: Right? The worst thing is that everyone's passwords will be stored online in a way that makes them public.
Yuka: Wow, that's super scary! There's no way I could do that.
Mai: That's right! That's why it's really impossible to save passwords on a web app!
Yuka: I see. So it's better to use OAuth properly. I learned something new!