The Four OAuth Roles

Every OAuth exchange has four roles. The resource owner is the user whose data it is. The client is the application that wants access. The authorization server signs the user in, asks for consent and issues tokens. The resource server is the API that holds the data and accepts the tokens. Picture a photo printing app, the client, that wants to read a user's photos from a storage service.

Resource owner. The person who can grant access. They interact only with the authorization server, so their password never reaches the client.

Client. The printing app. It is registered with the authorization server in advance and has a client id. A client that runs on a server can also hold a client secret; one that runs in a browser or on a phone cannot keep a secret, and is called a public client.

Authorization server. The photo service's login and consent system. It knows the users, the registered clients and the scopes, and it issues tokens.

Resource server. The photo API. It checks each token it receives, and serves only what the token's scopes allow.

One organisation, two roles. The authorization server and the resource server usually belong to the same company, and may be one product, but they are separate jobs: one issues tokens, the other accepts them.

Why the split matters. The resource server never sees the user's password, only tokens, so the photo API never holds a password that could leak.

So when reading any OAuth flow, first name who plays each of the four roles.