OAuth 2.0 Roles and Terminology

Analogy categoryAnalogies

RFC 6749 defines OAuth 2.0 around four distinct roles: the resource owner (the user who owns the data), the client (the application requesting access), the authorization server (which authenticates the resource owner and issues tokens), and the resource server (which hosts the protected data and validates tokens on each request). Understanding which role is which is the single most useful mental model for reading OAuth diagrams, since almost every flow is just these four parties exchanging messages in a specific order.

🏏

Cricket analogy: Picture the BCCI as the authorization server, a player like Virat Kohli as the resource owner of his own image rights, a sponsor's app as the client requesting endorsement usage, and the broadcaster's footage archive as the resource server that actually serves the clips.

The Four Roles in Practice

The resource owner and client are the two parties most people think about first: the resource owner is a human sitting at a browser deciding whether to grant access, and the client is the application — a web app, mobile app, or backend service — that wants to act on the resource owner's behalf. Critically, the client never sees the resource owner's password; it only ever receives a token after the resource owner has approved a consent screen presented by the authorization server, not by the client itself.

🏏

Cricket analogy: The resource owner is like a franchise owner deciding whether to let a documentary crew (the client) film training — the crew never gets the owner's private office key, only a filming permit issued by ground management.

The authorization server and resource server are often the same company but frequently run as physically separate services with different responsibilities. The authorization server owns the login screen, the consent UI, and the token-issuing endpoints (/authorize and /token); the resource server owns the actual data endpoints (like /api/photos or /api/repos) and its only job regarding OAuth is to validate an incoming access token — checking its signature, expiration, and scope — before returning any data.

🏏

Cricket analogy: Like the ICC's accreditation office (authorization server) issuing media passes separately from each individual stadium's turnstile system (resource server), which only checks whether the pass presented is valid for that day's gate.

json

// A typical OAuth 2.0 authorization server metadata document
// (served at /.well-known/oauth-authorization-server, per RFC 8414)
{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "revocation_endpoint": "https://auth.example.com/revoke",
  "introspection_endpoint": "https://auth.example.com/introspect",
  "scopes_supported": ["openid", "profile", "photos.readonly", "repo:read"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"]
}

Key Terms You'll See Everywhere

Every client that wants to use OAuth must first register with the authorization server and receive a client_id (a public identifier) and, for confidential clients, a client_secret (a private credential used to authenticate the client itself, not the user). It also registers one or more redirect_uri values — exact URLs the authorization server is allowed to send the user back to after login — which exists specifically to prevent an attacker from redirecting a stolen authorization code to a malicious endpoint.

🏏

Cricket analogy: The client_id is like a broadcaster's public accreditation number printed on every pass, while the client_secret is the private PIN only the broadcaster's ops team knows to activate their feed at the production truck.

Two more terms round out the vocabulary: the grant_type identifies which OAuth flow is being used (authorization_code, client_credentials, refresh_token, and so on), and the state parameter is a random, unguessable value the client generates before redirecting, then verifies matches on the callback — its entire purpose is to prevent cross-site request forgery (CSRF) attacks where an attacker tricks a victim into completing someone else's authorization flow.

🏏

Cricket analogy: The grant_type is like choosing between a 'Test match pass' versus a 'T20 pass' at the gate — same stadium, different entry procedure — while state is like a numbered stub torn off your ticket that the gate re-checks matches the one you were issued, so no one swaps tickets mid-queue.

A useful shortcut: the authorization server issues tokens and handles login/consent; the resource server never sees a password and only ever inspects tokens. If a service is checking a Bearer token's scope on an API call, it's acting as a resource server in that moment, even if it's the same company running both roles.

Never register a redirect_uri with a wildcard or an overly broad pattern. Authorization servers must do exact-match validation; a loose redirect_uri allowlist is one of the most common real-world OAuth misconfigurations and enables authorization code interception attacks.

OAuth 2.0 defines four roles: resource owner, client, authorization server, and resource server.
The client never sees the resource owner's password — consent happens on the authorization server's own UI.
The authorization server issues tokens (/authorize, /token); the resource server validates tokens on data requests.
client_id is public; client_secret is private and authenticates the client application itself, not the user.
redirect_uri must be registered and exactly matched to prevent authorization code interception.
grant_type selects which OAuth flow is used; state prevents CSRF by being verified on the callback.
The same company can run both authorization and resource servers, but the responsibilities remain distinct.