OAuth 2.0 delegation controls and identity risk for modern apps

At a glance

What this is: OAuth 2.0 is a delegated authorization framework that lets apps access data without passwords, and its key risk is implementation failure around scopes, tokens, and revocation.

Why it matters: IAM, NHI, and autonomous programmes all depend on the same delegation logic, so OAuth mistakes can expand blast radius across user sessions, service accounts, and agent-driven integrations.

👉 Read WorkOS's guide to OAuth 2.0 delegation, tokens, and safe implementation

Context

OAuth 2.0 is a delegation model, not a login model, and that distinction matters because many identity programmes still treat it like a generic access pattern. In practice it controls what an application can do with another system's data, using tokens instead of passwords. That makes it central to NHI governance wherever apps, services, or tools act on behalf of an identity.

The governance gap is usually not in the spec. It appears when teams over-scope consent, store tokens badly, skip issuer and audience validation, or let refresh tokens live longer than the trust relationship that justified them. Those are identity control failures, not protocol inevitabilities, and they create exposure across human, NHI, and automation-led workflows.

Key questions

Q: How should security teams implement OAuth 2.0 safely in production apps?

A: Start with Authorization Code plus PKCE for public clients, exact redirect URI matching, and full token validation. Then treat scopes, token storage, and revocation as identity controls, not implementation details. The goal is to ensure delegated access stays bounded, observable, and removable when trust changes.

Q: Why do OAuth integrations become NHI governance problems?

A: Because every token-bearing integration behaves like a non-human identity with its own ownership, permissions, and lifecycle. If the organisation cannot inventory, scope, and revoke those tokens, delegated access persists beyond the business need that created it. That is an identity governance failure, not just an app integration issue.

Q: What do security teams get wrong about OAuth scopes?

A: They often treat consent as a one-time checkbox instead of a durable entitlement decision. Broad scopes, unclear prompts, and bundled permissions make the actual blast radius much larger than the user expects. Good governance requires reviewing scopes as carefully as roles and service account permissions.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

Technical breakdown

Authorization Code flow and PKCE in delegated access

Authorization Code is the standard OAuth flow for user-mediated access. The app sends the user to the authorization server, receives a short-lived code, and exchanges it for tokens. PKCE adds proof that the same client started and completed the exchange, which closes code interception risk for public clients such as mobile apps, browser apps, and CLIs. In identity terms, PKCE reduces the value of intercepted authorization codes but does not change the underlying delegation model. The app still receives a token that can act within whatever scopes were approved. The real control boundary is therefore scope, audience, and token handling, not user login alone.

Practical implication: Use Authorization Code plus PKCE for public clients and verify issuer, audience, scopes, and redirect URI exact match.

Access tokens, refresh tokens, and token lifetime control

Access tokens are the short-lived artefact used to call APIs, while refresh tokens are the longer-lived credential used to obtain new access tokens. That separation is what makes OAuth practical, because sessions can continue without re-prompting the user every hour. It also creates a governance decision point: the refresh token effectively extends the trust relationship beyond the original consent event. If storage, rotation, or revocation is weak, the refresh token becomes the durable identity artefact attackers care about. For NHI governance, that means token lifecycle discipline is as important as initial authorization.

Practical implication: Treat refresh tokens as high-value credentials, rotate them on use where possible, and revoke them when trust changes.

OAuth for machine-to-machine and CLI identities

Client Credentials and Device Code extend OAuth beyond browser login. Client Credentials represents the application itself, not a user, and is common in backend integrations and service-to-service calls. Device Code allows constrained devices to complete login through a second device, which is useful for CLIs, TVs, and IoT interfaces. These flows are operationally useful but easy to over-trust because they feel temporary or low-friction. In governance terms, they still create non-human identities with defined scope, revocation needs, and audit requirements. The difference is not whether a human is present at the moment of consent, but whether the resulting token can be governed as a discrete identity artefact.

Practical implication: Inventory machine and CLI OAuth clients separately and assign ownership, scope limits, and revocation procedures to each one.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth sprawl is really delegated identity sprawl. Once OAuth is used for third-party integrations, CLIs, background jobs, and machine-to-machine calls, the organisation is no longer managing a single login pattern. It is managing a population of token-bearing identities with different lifetimes, scopes, and offboarding needs. The practitioner conclusion is simple: OAuth belongs in the same governance conversation as NHI lifecycle and privilege control.

Short-lived access tokens do not make governance optional. The protocol reduces password exposure, but the control failure moves to token handling, consent scope, and revocation hygiene. If those three are weak, the environment still accumulates durable access paths even when passwords never leave the browser. Practitioners should treat token lifecycle as identity lifecycle, not as a transport detail.

Least privilege fails when consent screens are treated as a formality. OAuth scopes define the real blast radius, and broad or unclear scopes turn delegated access into over-entitlement. That problem applies equally to human users approving app access and to machine clients acting at runtime. The implication is that entitlement design must be reviewed at the scope level, not only at the account level.

OAuth governance becomes brittle when implementation errors are normalised. Redirect mismatches, weak token storage, missing issuer checks, and legacy flows are not edge cases in mature environments, they are predictable failure modes. This is why a secure OAuth posture cannot rely on documentation alone. Practitioners need recurring review of flow choice, storage pattern, and revocation behaviour across every integration.

Token-based access creates an identity blast radius that outlives the initial decision. A consent event is only the start of the trust relationship, not the end. Once a refresh token or long-lived integration token exists, offboarding and re-authorization are as important as initial approval. The practitioner implication is that OAuth governance must be lifecycle-driven, not just deployment-driven.

From our research:

• 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
• Secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent in 38% of cases, according to The State of Secrets Sprawl 2025.
• For a broader view of how exposed credentials turn into access risk, see 52 NHI Breaches Analysis.

What this signals

Delegated access is becoming a standing governance surface, not a one-off integration task. As more applications rely on OAuth for user and machine access, IAM teams need to manage consent, token lifetime, and offboarding as a single control chain. The relevant operational shift is to treat every OAuth client as an owned identity object with a lifecycle, not as a convenience feature.

OAuth scope design is where blast radius is either contained or amplified. Broad scopes and weak revocation discipline create the same practical problem as over-privileged service accounts: access outlives the original need. For teams already aligning to OWASP Non-Human Identity Top 10, scope control belongs in the same conversation as secret storage and rotation.

The next maturity step is not more consent screens. It is building measurable token governance, including revoked-token verification, integration ownership, and periodic review of active third-party access across human and non-human workflows.

For practitioners

• Standardise on Authorization Code plus PKCE Use Authorization Code plus PKCE for browser, mobile, and desktop clients, and reject new deployments that depend on implicit or password-based flows. Require exact redirect URI matching and validate issuer, audience, scopes, and expiry on every token exchange.
• Classify OAuth integrations as governable identities Build an inventory of every app, CLI, service account, and partner integration that can mint or refresh tokens. Assign a clear owner, approved scopes, offboarding trigger, and revocation path so the integration can be retired when trust changes.
• Tighten scope design and consent review Review consent prompts for least privilege and remove broad or bundled permissions that are not essential to the task. Where possible, split high-risk scopes into separate approvals so a single token cannot overreach its intended function.
• Harden token storage and revocation controls Prevent access tokens and refresh tokens from appearing in logs, browser storage, or shared debug artefacts. Rotate refresh tokens where supported and test revocation workflows so disconnection actually ends access instead of merely hiding it.

Key takeaways

• OAuth 2.0 reduces password sharing, but it shifts the main risk to token scope, storage, and revocation.
• Machine-to-machine and CLI flows turn OAuth into an NHI governance problem because each integration becomes a token-bearing identity.
• Teams that cannot inventory, bound, and retire OAuth access are managing delegated identity by assumption, not by control.

Key terms

• Authorization Code Flow: The OAuth flow that swaps a temporary authorisation code for access tokens after the user approves access. It is the modern default for browser, mobile, and desktop clients because it keeps credentials out of the client and supports stronger protections such as PKCE.
• Access Token: A short-lived credential that lets an application call an API within a defined scope. In governance terms, it is the active proof of delegated permission, so expiry, audience checks, and secure storage are central to reducing misuse.
• Refresh Token: A longer-lived credential used to obtain new access tokens without asking the user to approve again. It extends the trust relationship beyond the original login event, which makes rotation, revocation, and ownership essential control points.
• PKCE: A protocol extension that proves the client that started an OAuth login is the same client that finishes it. It is especially important for public clients that cannot safely store a secret, and it reduces interception risk without changing the access model.

Deepen your knowledge

OAuth 2.0 delegation, token lifecycle, and scope governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for app-to-app access or third-party integrations, it is worth exploring.

This post draws on content published by WorkOS: What is OAuth 2.0? How modern apps get access to your data without your password. Read the original.