OAuth 2.0 security
OAuth 2.0 delegates access through tokens and defined authorization flows.
What it means
OAuth 2.0 delegates access through tokens and defined authorization flows. It is not, by itself, a complete user authentication protocol. Security depends on the chosen flow, registered redirect destinations, token handling, client properties, and protections against interception and replay.
A practical example
A client uses an authorization-code flow with appropriate protections and sends an access token only to its intended API. It does not treat an arbitrary access token as a reliable login assertion or expose long-lived credentials in browser-visible locations.
What to check
Use current protocol guidance, constrain redirect URIs, bind authorization responses to the initiating flow, and review token audience and scope. Prefer maintained libraries and test failure and replay paths.
A common pitfall
Confusing OAuth with OpenID Connect can cause an application to infer identity from the wrong token or endpoint. Delegated access and user authentication require distinct protocol decisions.
Think it through
Why distinguish an access token from an identity token?
Answer: They serve different recipients and purposes; using one as the other can create invalid trust assumptions.
Delegation has several participants
A fictional calendar service lets a scheduling app read a user's free times. The user authorizes access through an authorization server, the scheduling app receives a credential under the selected flow, and the calendar API enforces the resulting grant. Naming these participants prevents the common assumption that one token is simply a universal proof of login.
The client has its own properties. A public client cannot safely keep a shared secret merely because its source code contains a value called client-secret. A server-side confidential client can protect credentials differently. Choose a supported flow that fits the client and use current security guidance rather than reusing an older integration pattern unchanged.
Redirect-based flows require the browser to return to an expected destination and the response to belong to the initiating interaction. Protect the authorization code exchange, avoid exposing tokens to unintended recipients, and constrain the permissions granted. Each of those decisions closes a different route to misusing delegated access.
Draw the intended token journey
For the calendar example, label the authorization server, client, browser, and resource API on a diagram. Mark where the authorization code and access token appear, which participant consumes each, and what permission the user grants. Then add a second unrelated API and explain why the calendar token should not be accepted there.
Operationally, users need a way to inspect and withdraw integrations. Logs should help investigate grants without recording raw bearer credentials. Review expiry, refresh behavior, and incident revocation before launching the integration. Delegation is a continuing relationship with a defined permission set, not a one-time consent screen that makes later access automatically safe.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: OAuth2IETF RFC 9700: OAuth 2.0 Security Best Current Practice