What are the four roles (participants) in the OAuth 2.0 Authorization Code flow?
The User, the Client (the regular web app), the Authorization Server (the identity provider, e.g. Auth0), and the Resource Server (the API holding the user's data).
* The four OAuth 2.0 roles and how they relate. — Herzmut, CC BY-SA 4.0, via Wikimedia Commons. *
And here is how the four roles interact across the Authorization Code flow — every numbered step runs between two of them (cyan = front channel through the browser; magenta = back channel, server to server):
* The four roles and the nine numbered steps: front-channel code, back-channel token, then the API call. *
Mapping the diagram onto the standard OAuth terms:
| Diagram label | OAuth role | Job |
|---|---|---|
| User | Resource Owner | Owns the data, grants consent |
| Regular Web App | Client | Wants access on the user's behalf |
| Auth0 Tenant | Authorization Server / Identity Provider | Authenticates the user, issues tokens |
| Your API | Resource Server | Holds protected resources, accepts access tokens |
Keeping these four straight is the key to reading the whole flow — every arrow in the sequence diagram goes between two of them.
Tip: The Authorization Server and Resource Server can be run by different parties (Auth0 issues tokens; your API consumes them). Separating "who proves identity" from "who holds the data" is OAuth's whole point.
Go deeper:
RFC 6749 §1.1 — OAuth roles — the authoritative definitions of resource owner, client, authorization server, resource server.