OAuth 2.0 is an authorization framework for delegated API access, not a login protocol by itself. Many common breaches come from treating the original 2012 framework examples as today’s security baseline. RFC 9700, published in January 2025 as the OAuth 2.0 Security Best Current Practice, updates that baseline: use authorization code flows with PKCE, exact redirect URI matching, strong token protection, modern client authentication, resource/audience restrictions, and avoid legacy patterns such as the resource-owner password grant and ordinary implicit access-token delivery.
Within Security Engineering, OAuth security is about the whole authorization transaction: browser redirect, client, authorization server, token endpoint, resource server, refresh-token lifecycle, and the permissions represented by scopes.
Identity federation and SSO provides the broader trust-boundary context.
Do not use OAuth access tokens as proof of login
An access token authorizes a client to call a resource server. Its format and subject semantics are defined for API authorization, not necessarily for authenticating a user to your application.
Use OpenID Connect when you need interoperable user authentication and identity claims.
OpenID Connect Basics explains the ID-token boundary.
Use authorization code with PKCE
RFC 9700 requires public clients to use PKCE for authorization-code flows and recommends it for confidential clients as well.
PKCE binds the authorization request/code exchange to a client-generated verifier so a stolen/injected code cannot be redeemed by another client instance.
Generate a fresh verifier/challenge per transaction and do not use constant values that turn PKCE into decoration.
Avoid the implicit grant for new systems
RFC 9700 says clients should not use response types that place access tokens directly in the authorization response unless the known leakage/replay risks are mitigated.
Authorization code keeps access tokens out of browser URLs/fragments and allows stronger replay protections.
Legacy single-page applications should migrate to modern code+PKCE patterns supported by current identity platforms.
Never use the Resource Owner Password Credentials grant
RFC 9700 is explicit: the password grant MUST NOT be used.
It trains users to enter credentials into the client, expands where passwords can leak, and does not fit modern MFA/passkey authentication processes.
Move authentication to the authorization server and let the client receive tokens rather than credentials.
Redirect URIs must be matched exactly
Loose wildcard or prefix matching lets attackers steer authorization responses or codes toward attacker-controlled paths/domains.
RFC 9700 requires exact string matching except limited localhost-native-app port behavior.
Register explicit HTTPS redirect URIs and remove open redirectors from both authorization server and client.
state, nonce, issuer, and PKCE solve different attacks
CSRF, code injection, replay, and mix-up are related but distinct threats.
Use transaction-bound state/correlation, PKCE, OpenID Connect nonce where applicable, and issuer validation/mix-up defenses rather than relying on one random parameter to “secure OAuth.”
Validate the callback against the transaction that initiated it, not only against a signed token afterward.
Protect refresh tokens like long-lived credentials
Refresh tokens can mint new access tokens and are attractive theft targets.
RFC 9700 requires public clients that receive refresh tokens to use sender-constrained tokens or refresh-token rotation to detect replay.
Limit scope/resources, expire inactive refresh tokens, revoke on security events where appropriate, and keep them out of browser-accessible storage when architecture allows.
Restrict access tokens to minimum privilege
Use narrow scopes and audience/resource restriction so one token is not accepted across unrelated APIs.
Resource servers should validate issuer, intended audience, expiry, scopes/authorization context, and sender constraint where used.
A valid token presented to the wrong API should fail rather than becoming a bearer credential for the whole platform.
Sender-constrain high-value tokens
RFC 9700 recommends sender-constrained access tokens such as mutual TLS or DPoP to reduce the usefulness of stolen bearer tokens.
This is particularly valuable for high-risk financial, health, administrative, or machine-to-machine APIs.
Sender constraint adds key/device lifecycle complexity, so design key rotation and multi-instance behavior before rollout.
Log OAuth without leaking secrets
Record client ID, issuer, redirect URI, grant type, scope, authorization errors, token endpoint outcomes, resource/audience, and correlation IDs.
Do not log authorization codes, access tokens, refresh tokens, client secrets, or PKCE verifiers in plaintext.
Use Log Retention for Investigations so suspicious consent, token replay, and admin changes remain traceable long enough for response.
OAuth succeeds when authorization stays delegated and least-privilege
The mature implementation follows RFC 9700, uses code+PKCE, exact redirects, modern client authentication, narrow tokens, safe refresh-token handling, strong callback validation, and OIDC for authentication.
OAuth is flexible by design. Security comes from constraining that flexibility so browsers, clients, authorization servers, and APIs agree exactly which transaction and privilege they are processing.
Client registration should be tightly governed. Redirect URIs, grant types, token endpoint authentication method, allowed scopes, application type, and ownership are security configuration. Prevent developers from registering broad wildcard callbacks or unreviewed confidential clients, and periodically remove abandoned client registrations whose secrets or redirect domains may later be taken over.
Native applications should use external user-agents and claimed HTTPS or app-link style redirects according to platform best practice rather than embedding the authorization experience in a webview. Embedded browsers can expose credentials to the app and weaken SSO/security controls at the authorization server. Use mature platform libraries that implement PKCE and callback handling correctly.
Client secrets are not meaningful authentication for public applications that cannot protect them. Mobile and browser code can be inspected, so a hard-coded ‘secret’ should be treated as public. Use PKCE and platform-bound mechanisms instead; reserve confidential-client authentication for components that genuinely protect credentials on a backend.
Scope design should follow business operations. Replace broad scopes such as `admin` or `read_write_all` with resource-specific capabilities where the authorization server supports it. Consent screens and policy should make high-risk scopes recognizable so users and admins understand what an application is asking to do before tokens are issued.
Authorization servers should prevent mix-up across multiple issuers. Clients that talk to several identity providers need to bind each authorization response to the issuer that started the transaction and use issuer metadata consistently. Accepting a code from one authorization server at another server’s token endpoint can create confusion that attackers exploit.
Token storage is a client architecture decision. Browser local storage is exposed to successful XSS, while server-side sessions and HTTP-only cookies can reduce token exposure for web apps. Native clients should use operating-system secure credential stores. Choose the storage pattern from the client threat model instead of treating every OAuth token as an ordinary application string.
Revocation and logout expectations should be explicit. Revoking a refresh token may stop new access-token issuance while already-issued short-lived tokens remain usable until expiry. Applications that need rapid kill capability should use short access-token lifetimes, token introspection or sender constraints where supported, and backend authorization checks that can reflect account disablement quickly.
Third-party OAuth integrations should be monitored continuously. Track newly consented apps, unusual scopes, dormant high-privilege grants, token use from unexpected locations, and changes to redirect URIs or client credentials. OAuth abuse often appears as legitimate API traffic, so identity and app-governance telemetry is essential to distinguish compromised consent from normal application behavior.
Authorization servers should use modern metadata and discovery mechanisms. RFC 9700 recommends publishing OAuth Authorization Server Metadata so clients can discover endpoints and capabilities consistently. This reduces hard-coded endpoint mistakes and can make key/capability rotation easier, but clients should trust only configured issuers and validate metadata over secure channels.
Client authentication should prefer asymmetric methods for higher-assurance confidential clients when practical. Private-key JWT or mutual TLS avoids distributing one long-lived shared client secret across several servers. Shared secrets remain common, but they need secret-manager storage, rotation, environment separation, and strict prevention of logging or source-code inclusion.
Browser applications should defend against XSS because OAuth cannot compensate for arbitrary script execution in the client origin. Content Security Policy, dependency hygiene, secure cookies/server-side sessions, output encoding, and minimal token exposure remain essential. PKCE prevents some code theft; it does not stop malicious JavaScript already executing as your application.
Consent and delegated access need governance. Users can authorize apps that technically follow OAuth but request excessive scopes or come from risky publishers. Enterprise environments should review admin consent, OAuth app inventory, dormant grants, and privilege changes so secure protocol implementation does not become a channel for legitimate-but-unwanted access.
OAuth threat modeling should include multi-environment misconfiguration. Development and staging redirect URIs, client secrets, and localhost callbacks often remain enabled on production clients because they were convenient during testing. Separate clients by environment and remove callbacks that are no longer required so an attacker cannot redirect a production authorization response through a weaker environment.
Resource servers should enforce authorization independently of the client UI. Hiding an admin button or omitting a scope from a frontend request does not protect the API if a stolen or modified token can still call a privileged endpoint. Validate token scopes/audience plus business permissions at every sensitive API operation.
Security testing should include authorization-code replay, stolen refresh token, open redirect, cross-client code injection, scope escalation, consent phishing, logout/revocation, and malformed token handling. A standards-compliant happy path can coexist with exploitable edge behavior, so penetration and automated tests should exercise the failures the BCP is designed to prevent.
