An authorization server issues an access token that a resource server accepts under defined conditions. The client may act for a user after delegated authorization or on its own behalf in a machine-to-machine flow.
OAuth defines roles and protocol flows rather than one token format or universal permission model. For user-facing applications, current security practice favors the authorization-code flow with Proof Key for Code Exchange (PKCE). Implementations must bind responses to the correct client and redirect URI, protect authorization codes and refresh tokens, and ensure that access tokens are accepted only by their intended resource servers.
Key points
Core rolesDistinguish the resource owner, client, authorization server, and resource server; document when one component performs more than one role.
Token controlsConstrain audience, scope, lifetime, and storage; validate tokens completely; rotate or revoke refresh tokens where appropriate; and avoid exposing bearer tokens in URLs or logs.
Current flow choicesFollow the OAuth security best current practice: clients should not use the implicit grant except where its specified injection and leakage risks are mitigated, and must not use the resource owner password credentials grant.
Important limitationOAuth 2.0 does not define user authentication or prove who is using an access token. A valid token also does not replace object-, function-, or transaction-level authorization inside the resource server.