Which four roles does OAuth 2.0 define, and what does each one do?
Resource owner (the user who owns the data), client (the application that wants access), authorization server (authenticates the user and issues tokens) and resource server (hosts the data and accepts tokens).
| Role | Also called | Job |
|---|---|---|
| Resource owner | User, subject | Owns the data (for example a social-media profile) and grants an application access to it. Hands over only a scope, never their credentials. |
| Client | Application, relying party (RP) | The app that wants to access the user's data; it must be authorised by the resource owner first. |
| Authorization server | Identity provider (IdP) | Authenticates the subject, obtains consent, and issues a time-limited access token for a scope it defines. |
| Resource server | API | Hosts and protects the user's resources; serves requests that carry a valid access token. |
Resource server and authorization server together are also called the OAuth server or service API. They are often run by the same provider (the same company that hosts your photos also runs the login and token service), but they are logically separate: one issues tokens, the other checks them.
Tip: Map it onto a valet: you (resource owner) give the parking attendant (client) a valet key, issued by the car maker's key service (authorization server), that opens your car (resource server) but not the glovebox.
Go deeper:
RFC 6749, Section 1.1: Roles — the four roles in the specification's own words.- DigitalOcean: An Introduction to OAuth 2 — roles, flows and registration in a single walk-through.