In OAuth 2.0, which four roles does RFC 6749 define, and what is each one responsible for?

juniormust knowfreq 74%

answer

Four parties, not two
Who owns, who asks, who issues, who guards
A person in this model is an end-user
Issuer and validator are separate roles
Authorization server mints, resource server checks

basics

~20 s

RFC 6749 defines four roles: the resource owner who grants access, the client that asks for it, the authorization server that authenticates the owner and issues an access token, and the resource server that holds the data and validates that token.

solid answer

~40 s

RFC 6749 §1.1 names four parties. The resource owner owns the protected data and grants access to it; when that party is a person the specification calls it an end-user. The client is the application making requests on the owner's behalf — it is whatever software was issued a client_id, very often a server rather than a browser. The authorization server authenticates the resource owner, obtains their authorization and issues an access_token. The resource server hosts the protected resources and validates a presented access token before serving the request. Bind them to one case: an animal's owner, a scheduling application they chose, the veterinary practice's authorization server, and the practice's appointment API. Only the authorization server issues; deciding whether an access token is valid is the resource server's job, not the client's.

RFC 6749 §1.1 names four parties. The **resource owner** owns the protected data and grants access to it; when that party is a person the specification calls it an *end-user*. The **client** is the application making requests on the owner's behalf — it is whatever software was issued a `client_id`, very often a server rather than a browser. The **authorization server** authenticates the resource owner, obtains their authorization and issues an `access_token`. The **resource server** hosts the protected resources and validates a presented access token before serving the request. Bind them to one case: an animal's owner, a scheduling application they chose, the veterinary practice's authorization server, and the practice's appointment API. Only the authorization server issues; deciding whether an access token is valid is the resource server's job, not the client's.

code

pseudocode · 15 lines

pseudocode

resource owner        the animal's owner
  holds                account password at the authorization server
  grants               authorization for this client's request

client                the scheduling application
  holds                client_id (+ client_secret if confidential)
  presents             access_token to the resource server

authorization server  run by the veterinary practice
  authenticates        the resource owner
  issues               access_token

resource server       the practice's appointment API
  holds                the protected appointment records
  validates            every access_token presented to it

go deeper

for a junior

Name all four roles in the specification's own words and bind each to one concrete case. Then say which party issues an access token and which validates it — that pair is what a first screen is actually checking.

for a middle

Explain why the roles are defined before any flow, and show that a client is defined by holding a client_id rather than by being a browser or a front end. Place the redirection endpoint on the client, not the authorization server.

for a senior

Demonstrate that roles attach to an exchange rather than to a deployment: one service can be a resource server for inbound calls and a client for its own outbound ones. Say what stays true when the authorization server and resource server are co-deployed.

for a principal

The angle is how many parties your estate should have in each role. One authorization server serving every resource server keeps the model simple and the trust decisions few; several issuers mean every API must decide which issuers it accepts at all, and that decision has to be owned somewhere.

Why the framework starts with roles

OAuth 2.0 does not begin with a flow or a token format. RFC 6749 begins by naming four roles, then defines every message in the framework as travelling between two of them. That is why the role model is the first thing an interviewer checks: a candidate who can place the four parties can usually reason their way through any grant, and a candidate who cannot is reciting a library quickstart.

Take one concrete booking. An animal's owner keeps their pet's records with a veterinary practice. They want a third-party scheduling application, which they found and chose themselves, to book the next check-up on their behalf. Four parties are in the picture and the specification has a name for each.

The four roles

Resource owner — the party that owns the protected resource and can grant access to it: the animal's owner. RFC 6749 adds one naming rule worth knowing, that when the resource owner is a person it calls that party an end-user. The resource owner holds an account, and a password for it, at the authorization server.
Client — the application making protected-resource requests on the resource owner's behalf: the scheduling application. The word is a trap. An OAuth 2.0 client is not the browser, not the device and not "the front end". It is whichever piece of software was issued a client_id, and it is frequently a server-side process.
Authorization server — the party that authenticates the resource owner, obtains their authorization, and issues an access_token to the client: here, a service the practice runs. It is the only role in the model that issues tokens.
Resource server — the party that hosts the protected resources and accepts access tokens presented with requests for them: the practice's appointment API. It is the role that validates a token before acting on the request.

Who holds what, who issues, who validates

role	in this booking	credential it holds	issues access tokens?	validates them?
resource owner	the animal's owner	their own account password	no	no
client	the scheduling application	`client_id`, plus `client_secret` if confidential	no	no — it presents one
authorization server	the practice's authorization service	the keys behind the tokens it mints	yes	n/a — it is the issuer
resource server	the appointment API	none in this model	no	yes

Three readings of that table are what the question is really testing.

The client's credential identifies the application, not the person. A client_id says "this is the scheduling application". It is not, and never becomes, the resource owner's password.
Issuing and validating are different roles. The authorization server mints; the resource server checks. An answer in which the client validates the access token, or the resource server issues it, is backwards, and every later answer built on it inherits the error.
The resource owner authenticates at the authorization server and nowhere else. The resource server does not see the owner's password, and neither does the client.

Two structural facts that catch people out

The authorization server and the resource server may be one deployment or two separate parties. Nothing requires them to be different processes, hosts or teams. They are distinct roles, and the roles survive being co-deployed.
One authorization server can serve many resource servers. The same authorization server may issue access tokens an appointment API accepts and access tokens a billing API accepts, with each resource server validating for itself.

There is also one misplacement more common than the rest put together: the redirection endpoint belongs to the client. The authorization endpoint and the token endpoint are the authorization server's; the URL the user-agent is returned to afterwards is a route the client hosts.

Saying it well in an interview

Name the four roles in the specification's own words, then bind each to the concrete case in one clause: the owner is the person whose data it is, the client is the application they chose, the authorization server is the party they already have an account with, the resource server is the API holding the records. Then volunteer the two directions nobody asks about and everybody gets wrong — who issues, and who validates.

One last piece of hygiene: say which token you mean. On this subject "the token" is ambiguous between an access token and a refresh token, and the roles answer is about the access token the client presents to the resource server.

## Why the framework starts with roles OAuth 2.0 does not begin with a flow or a token format. RFC 6749 begins by naming four roles, then defines every message in the framework as travelling between two of them. That is why the role model is the first thing an interviewer checks: a candidate who can place the four parties can usually reason their way through any grant, and a candidate who cannot is reciting a library quickstart. Take one concrete booking. An animal's owner keeps their pet's records with a veterinary practice. They want a third-party scheduling application, which they found and chose themselves, to book the next check-up on their behalf. Four parties are in the picture and the specification has a name for each. ## The four roles - **Resource owner** — the party that owns the protected resource and can grant access to it: the animal's owner. RFC 6749 adds one naming rule worth knowing, that when the resource owner is a person it calls that party an *end-user*. The resource owner holds an account, and a password for it, at the authorization server. - **Client** — the application making protected-resource requests on the resource owner's behalf: the scheduling application. The word is a trap. An OAuth 2.0 client is not the browser, not the device and not "the front end". It is whichever piece of software was issued a `client_id`, and it is frequently a server-side process. - **Authorization server** — the party that authenticates the resource owner, obtains their authorization, and issues an `access_token` to the client: here, a service the practice runs. It is the only role in the model that issues tokens. - **Resource server** — the party that hosts the protected resources and accepts access tokens presented with requests for them: the practice's appointment API. It is the role that **validates** a token before acting on the request. ## Who holds what, who issues, who validates | role | in this booking | credential it holds | issues access tokens? | validates them? | |---|---|---|---|---| | resource owner | the animal's owner | their own account password | no | no | | client | the scheduling application | `client_id`, plus `client_secret` if confidential | no | no — it presents one | | authorization server | the practice's authorization service | the keys behind the tokens it mints | yes | n/a — it is the issuer | | resource server | the appointment API | none in this model | no | yes | Three readings of that table are what the question is really testing. 1. **The client's credential identifies the application, not the person.** A `client_id` says "this is the scheduling application". It is not, and never becomes, the resource owner's password. 2. **Issuing and validating are different roles.** The authorization server mints; the resource server checks. An answer in which the client validates the access token, or the resource server issues it, is backwards, and every later answer built on it inherits the error. 3. **The resource owner authenticates at the authorization server and nowhere else.** The resource server does not see the owner's password, and neither does the client. ## Two structural facts that catch people out - **The authorization server and the resource server may be one deployment or two separate parties.** Nothing requires them to be different processes, hosts or teams. They are distinct *roles*, and the roles survive being co-deployed. - **One authorization server can serve many resource servers.** The same authorization server may issue access tokens an appointment API accepts and access tokens a billing API accepts, with each resource server validating for itself. There is also one misplacement more common than the rest put together: the **redirection endpoint belongs to the client**. The authorization endpoint and the token endpoint are the authorization server's; the URL the user-agent is returned to afterwards is a route the client hosts. ## Saying it well in an interview Name the four roles in the specification's own words, then bind each to the concrete case in one clause: the owner is the person whose data it is, the client is the application they chose, the authorization server is the party they already have an account with, the resource server is the API holding the records. Then volunteer the two directions nobody asks about and everybody gets wrong — who issues, and who validates. One last piece of hygiene: say **which** token you mean. On this subject "the token" is ambiguous between an access token and a refresh token, and the roles answer is about the access token the client presents to the resource server.

Is the resource owner always a person?
No. RFC 6749 calls the resource owner an *end-user* only when that party is a person. The role is defined by owning the protected resource and being capable of granting access to it, so an organisation can occupy it too. The naming rule is about people; the role is not.
Which of the four roles does the resource owner's browser play?
None. RFC 6749 calls it the user-agent. It carries the resource owner between the client and the authorization server, but it is not one of the four roles and holds no credential of its own in the model. Calling the browser "the client" loses the model's most important distinction.
Can one piece of software be both a client and a resource server?
Yes, in different exchanges. A service that validates access tokens presented to it is acting as a resource server; if that same service also holds a `client_id` and obtains access tokens to call another API, it is a client for those requests. Roles attach to the exchange, not to the deployment.

saying these in an interview costs you the question

Says the browser is the OAuth 2.0 client
Has the resource server issuing the access token
Has the client deciding whether an access token is valid
Cannot separate the client from the resource server
Thinks the resource owner must always be a human being
Calls client_id the user's identifier

In OAuth 2.0, which four roles does RFC 6749 define, and what is each one responsible for?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why the framework starts with roles

The four roles

Who holds what, who issues, who validates

Two structural facts that catch people out

Saying it well in an interview

▾common follow-ups3 questions

▾red flags6 flags

Why the framework starts with roles

The four roles

Who holds what, who issues, who validates

Two structural facts that catch people out

Saying it well in an interview

answer

go deeper