What OAuth solves: roles and delegation

Before OAuth, an app that wanted your calendar asked for your password and stored it: full access, forever, revocable only by changing the password. OAuth 2.0 (RFC 6749) replaces that with delegated authorization: the app gets an access token that grants limited access (scopes), for limited time, and can be revoked without touching the password.

The four roles:

• Resource owner: the user who owns the data.
• Client: the application wanting access (web app, SPA, mobile app, CLI, backend service).
• Authorization server (AS): authenticates the user, asks for consent and issues tokens (Okta, Auth0, Entra ID, Keycloak, Google...).
• Resource server (RS): the API that accepts access tokens.

The user only ever types credentials into the authorization server, never into the client.

OAuth is about authorization ("this app may read my calendar"), not authentication ("this is Ann"). An access token is meant for the API, and the client should treat it as opaque. Logging users in with plain OAuth led to many vulnerabilities, which is why OpenID Connect adds an identity layer on top.

OAuth 2.0 is a framework of many RFCs. The current security guidance is RFC 9700 (OAuth 2.0 Security Best Current Practice, 2025), and the OAuth 2.1 draft consolidates it: authorization code with PKCE for everyone, no implicit or password grants.