In OAuth 2.0, why is a client issued an access token instead of the resource owner's password?
answer
- Delegation, not credential sharing
- Where does the password actually go?
- client_id names the application, not the person
- The owner authenticates at one party only
- Client gets an issued access token instead
basics
~20 sThe resource owner's password is a credential shared only with the authorization server, the party they already have an account with. That server authenticates the owner itself and issues the client a separate credential, an access token, which the resource server validates.
solid answer
~50 sIn OAuth 2.0 the resource owner's password belongs to exactly two parties: the owner and the **authorization server** where their account lives. The **client** — a third-party application such as a scheduling app booking a veterinary appointment — is a different party, identified by a `client_id` it was issued and, if it is a *confidential* client, able to authenticate with a `client_secret`. Neither of those is the owner's password, and the client does not receive the owner's password at all. What crosses to the client is an `access_token` that the authorization server issues once the owner has authorised the request, and that the **resource server** validates when the client presents it. The point of the split is that an application can act on the owner's behalf at one API without ever holding the credential that unlocks the whole account.
go deeper
Be able to say where the resource owner's password goes — to the authorization server and nowhere else — and what the client gets instead. Naming the two credentials as belonging to two different parties is the whole answer at this level.
Explain the mechanics: the authorization server authenticates the owner and issues the access token, the client identifies itself with a client_id, and the resource server validates what the client presents. Note that client_id is an identifier, not a secret.
Show what the split buys operationally: a compromised client does not yield an account credential, and the authorization server has a record that a third party is acting for this owner. Be able to say which grant the 2.1 draft removed and why.
The angle is which credentials your organisation is willing to have in circulation at all. Every party that holds a credential is a party you must be able to rotate, audit and cut off, and the role model is what tells you how many of those parties you have created.
## The pattern the framework was written to replace Before delegated authorization was standardised, an application that needed to act for you at another service asked you for your username and password *for that service* and signed in as you. That one design choice creates several problems at once. The application now holds a credential that works everywhere on the account. It holds it for as long as it keeps it. You cannot take it back without changing the password, which breaks every other application you gave it to. And the service you actually trust has no record that a third party is acting for you. RFC 6749 takes that credential off the table by splitting the parties and giving each one its own. ## Who holds what - The **resource owner** — the animal's owner, in a veterinary booking — holds an account and a password at the **authorization server**. That credential is shared between exactly those two parties and no others. - The **client** — the scheduling application the owner chose — holds a `client_id` it was issued. If it is a *confidential* client, one able to keep a secret, it also holds a `client_secret`. Both identify the *application*. - The **resource server** — the practice's appointment API — holds the protected records and holds no credential belonging to either of the other two parties. Nothing in that list hands the client the owner's password, and nothing hands the owner's password to the resource server either. ## Why `client_id` is not a secret A `client_id` is an identifier rather than a credential: it says which application is asking. It travels in a request that passes through the resource owner's user-agent, so it is visible by design. Whether an application can additionally *authenticate* itself, and by what means, depends on whether it is a public or a confidential client — a separate subject. For the role model the point is narrower: the credential belongs to the application, never to the person. ## What the client receives instead The authorization server authenticates the resource owner itself, establishes that the owner authorises this client's request, and issues the client an `access_token`. The client presents that token to the resource server when it asks for the protected records, and the resource server validates it before serving them. | | the resource owner's password | the access token the client holds | |---|---|---| | who produced it | the resource owner chose it | the authorization server minted it | | who it identifies to | the authorization server at login | the resource server on each request | | what it reaches | everything the account can do | the access the owner authorised | | who checks it | the authorization server | the resource server | ## What the split achieves, and what it does not - It does mean that a compromised client yields no credential that can log in as the owner at the authorization server. - It does mean the authorization server knows a third party is acting for this owner, because it issued the token itself. - It does **not** make the access token unimportant. It is a credential, and the client has to protect it like one. - It does **not** turn the client into a party that can authenticate the resource owner. The owner authenticates at the authorization server and nowhere else. ## A version note that matters here RFC 6749 did define one grant in which the client handled the resource owner's password directly — the resource owner password credentials grant. The OAuth 2.1 draft removes it. Presenting it as a current option is a defect; knowing that it existed and was removed is the useful fact, because it is the exception people half-remember when they claim "OAuth sometimes takes the password". ## Saying it well in an interview If you are asked "why not just give the application the password", answer with the party list rather than with a slogan. The password is a credential shared between the resource owner and the authorization server. The client is a third party identified by a `client_id`. What crosses to the client is an access token the authorization server issued and the resource server validates. Then name the consequence in one line: the practice's appointment API can serve a scheduling application without that application ever holding the owner's own credential.
- If the client never sees the resource owner's password, how does the authorization server know the owner agreed?Because the authorization server is the party that authenticates the owner. It establishes who the owner is with the credential it already shares with them, and obtains their authorization directly, before issuing anything to the client. The client's role is to ask and then to receive.
- Does holding a client_secret make an application more trusted than the resource owner?No. A `client_secret` authenticates the application to the authorization server; it says nothing about any person and grants nothing on its own. Access still depends on a resource owner having authorised this client, and the resource server still validates the access token it is presented.
- Who is harmed first if a client's credentials leak, compared with the resource owner's password leaking?They are different incidents. A leaked `client_secret` compromises the application's identity at the authorization server. A leaked owner password compromises the account itself at that same server. The framework exists so that the first cannot become the second.
You give a delivery firm a pass the building's concierge issued, not your own front-door key. The firm proves nothing about you at the door — only that the concierge issued it that pass.
saying these in an interview costs you the question
- Says the client stores the user's password and replays it
- Treats client_secret as the resource owner's password
- Says client_id is secret and identifies the user
- Thinks the resource server authenticates the resource owner
- Claims the authorization server forwards the password to the client