OAuth 2.0.

OAuth 2.0 (RFC 6749) separates four roles: the resource owner (user), the client (application), the authorization server that issues tokens, and the resource server that hosts the API. The client obtains an access token through a defined grant — authorization code with PKCE (RFC 7636) for interactive apps, client credentials for service-to-service calls, device code (RFC 8628) for input-constrained devices — then calls the API with that token as a bearer credential. Scopes and audiences constrain what the token can do.

Security guidance and pitfalls

RFC 9700 (BCP 240, published January 2025) consolidates OAuth security practice: it deprecates the implicit grant and the resource owner password credentials grant, mandates PKCE for every authorization-code client, and requires exact redirect-URI matching to defeat code-interception and open-redirect attacks. Because access tokens are bearer credentials, sender-constraining them with DPoP or mutual-TLS limits replay after theft.

The dominant real-world abuse is OAuth consent phishing (illicit consent grant): rather than steal passwords, attackers register a malicious app and trick users into approving broad scopes. The May 2017 "Google Docs" worm spread this way in about an hour, and APT29/Nobelium repeatedly abused Microsoft 365 consent grants to persist through MFA. Defences include admin consent workflows, publisher verification, short-lived tokens, and revoking unused grants.

flowchart LR
  U[Resource owner] -->|1 authorize + code_challenge| AS[Authorization server]
  AS -->|2 auth code via redirect| C[Client app]
  C -->|3 code + code_verifier| AS
  AS -->|4 access token| C
  C -->|5 bearer token| RS[Resource server / API]
  RS -->|6 protected data| C