OAuth 2.0 delegation controls and identity risk for modern apps

At a glance

What this is: This guide explains OAuth 2.0 as a delegated access model that replaces password sharing with scoped tokens, and shows where implementations commonly create identity risk.

Why it matters: IAM, NHI, and application security teams need to govern token scope, storage, revocation, and flow selection because OAuth problems usually appear in the surrounding control plane, not the protocol core.

Context

OAuth 2.0 is an authorization framework for delegated access, not a login system. It lets apps act on a user’s behalf with scoped tokens, which changes the trust model from password sharing to permissioned access.

That shift matters for identity governance because the security boundary moves to consent, token lifecycle, and revocation. When teams treat OAuth as a simple integration feature, they often miss the controls that determine whether access stays bounded to the approved use case.

The article is a practical guide for modern application teams, including user-facing apps, CLIs, mobile clients, and service-to-service integrations. Its central message is that most OAuth risk comes from how the flow is implemented and governed over time.

Key questions

Q: What breaks when OAuth scopes are broader than resource permissions?

A: When OAuth scopes are broader than resource permissions, the connector can succeed while the downstream application allows access to objects the security team never meant to expose. That creates a split control plane where one layer says yes to invocation and another layer says yes to access, with no single governance decision in charge.

Q: Why do OAuth tokens create breach risk even after the original password is changed?

A: Because the token is often a separate bearer credential with its own scope and lifetime. Changing the user password does not automatically remove every delegated grant already issued to third-party apps. If the token remains valid, an attacker can keep using it until the organisation explicitly revokes it or the token expires.

Q: How should security teams govern refresh tokens in SaaS environments?

A: Treat refresh tokens as durable non-human identities with owners, expiry dates, and revocation procedures. Map where they are stored, who can redeem them, and which third parties hold them. Then tie offboarding, access review, and incident response to token custody, not just to user accounts.

Q: When should teams choose OAuth 2.0 with PKCE over legacy flows?

A: Teams should use OAuth 2.0 with PKCE for any public client such as SPAs, mobile apps, desktop apps, and CLIs. Legacy flows like Implicit and password-based grants remove too much protection from the exchange path and should only survive in migration plans, not new designs.

Technical breakdown

Authorization code flow and PKCE

The authorization code flow is the dominant OAuth pattern for user-facing applications because it keeps credentials away from the client and exchanges a short-lived code for tokens through the authorization server. PKCE adds a proof step that binds the login attempt to the same app instance that completes it, which matters for public clients such as SPAs, mobile apps, desktop apps, and CLIs. Without PKCE, code interception becomes a practical attack path. With it, the flow can support modern app types without relying on a hidden client secret.

Practical implication: require Authorization Code with PKCE for public clients and reject legacy patterns that expose codes or secrets.

Access tokens, refresh tokens, and revocation

OAuth separates immediate permission from renewal permission. Access tokens are short-lived credentials used to call APIs, while refresh tokens allow a client to obtain new access tokens without re-prompting the user. That separation reduces password exposure but creates a governance obligation: refresh tokens become the durable trust anchor, so storage, rotation, and revocation handling determine how long delegated access can persist. If refresh tokens are leaked or never revoked, temporary access becomes effectively standing access.

Practical implication: treat refresh token handling as a privileged credential lifecycle with explicit rotation and revocation paths.

Scopes, audiences, and exact redirect validation

OAuth security depends on constraining where tokens can be used and what they can do. Scope limits the actions granted, audience and issuer checks ensure the token was minted for the correct service, and exact redirect URI matching prevents authorization responses from being diverted to an unintended endpoint. These controls fail most often when teams broaden scopes for convenience, accept weak token validation, or allow redirect patterns instead of exact matches. The result is delegated access that is broader or leakier than the user approved.

Practical implication: validate issuer, audience, expiry, scope, and redirect URIs exactly, then review every scope for least privilege.

Threat narrative

Attacker objective: Exploit delegated access to reach user data or API capabilities without needing the user’s password.

1. Entry occurs when a user grants an app delegated access through an OAuth consent flow instead of a password share.
2. Credential abuse follows when over-broad scopes, weak token storage, or weak redirect validation let the client or attacker reuse the issued token outside the intended trust boundary.
3. Impact occurs when the token gives durable access to user data or APIs that should have remained limited, revocable, and task-scoped.

Breaches seen in the wild

• Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth risk is rarely caused by the protocol itself. The failure usually sits in implementation choices around scopes, token storage, redirect handling, and revocation. OAuth creates a delegation channel, but the channel becomes identity risk when teams allow it to behave like permanent application access rather than bounded consent. The practitioner lesson is to govern the implementation surface, not just approve the standard.

Delegated access is a lifecycle problem, not a one-time consent event. A token that is issued correctly can still become a liability if refresh rights persist too long, revoke paths are incomplete, or the client keeps broader access than the task required. That is why OAuth belongs in the same governance conversation as secrets management, access review, and offboarding, especially where apps call user APIs on behalf of individuals.

Consent without containment is not control. Clear prompts and user approval matter, but they do not compensate for over-broad scopes or weak audience validation. In practice, the governance question is whether the application can do only what the user intended, only for as long as intended, and only against the intended resource. Practitioners should treat scope design as an authorization boundary, not a product detail.

OAuth 2.0 becomes safer when teams stop treating tokens as generic integration artefacts. Access tokens, refresh tokens, and authorization codes each have different risk profiles and different control requirements. The field still underestimates how often token handling turns an otherwise sound delegation pattern into an identity exposure problem. The right response is disciplined token governance across the full lifecycle.

Ephemeral token trust debt: Short-lived tokens reduce exposure windows, but they also create an illusion of safety if renewal, revocation, and storage are not governed with the same rigor as permanent credentials. Once an organisation normalises that debt, every new integration inherits it. The implication is straightforward: delegated access should be measured by how quickly it can be revoked, not only by how briefly it lasts.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

OAuth governance is really token governance. Security teams should stop thinking of OAuth as a login feature and start treating it as a delegated-access control plane. That means reviewing scopes, renewal rights, revocation paths, and token storage together, because a weakness in any one of them can turn consent into persistent access.

The sharpest operational failure mode is scope drift. Teams often approve broad permissions at integration time and then let those permissions remain in place after the original use case has changed. That creates hidden blast radius across user apps, mobile clients, CLIs, and service-to-service integrations.

Scope drift: This is the point at which a token still works but no longer reflects the minimum access needed for the task. It is a governance failure because the access model has outlived the business purpose, which is exactly where incident response and recertification need to converge.

For practitioners

• Enforce Authorization Code with PKCE Use Authorization Code with PKCE for browser, mobile, desktop, and CLI clients so the exchange does not depend on a client secret the app cannot protect.
• Tighten scope design Review requested scopes for every integration and remove permissions that are not required for the actual task, especially for calendar, repo, and messaging access.
• Validate tokens exactly Check issuer, audience, expiry, and scope on every token, and require exact redirect URI matching instead of wildcard or pattern-based acceptance.
• Govern refresh token lifecycle Treat refresh tokens as durable credentials by rotating them, storing them securely, and revoking them on disconnect, compromise, or suspicious behaviour.
• Separate auth and resource responsibilities Keep the authorization server, consent flow, and resource server roles cleanly separated so validation and enforcement happen at the right layer.

Key takeaways

• OAuth 2.0 is useful because it replaces password sharing with delegated tokens, but that control only holds when scope and lifecycle are tightly governed.
• Most OAuth failures come from implementation choices such as broad permissions, weak validation, and poor revocation handling rather than from the protocol itself.
• For practitioners, the priority is to manage tokens like credentials and to treat consent as the start of governance, not the end of it.

Key terms

• Delegated OAuth Access: Delegated OAuth access is a permission model where an application acts on behalf of a user or workspace after consent is granted. In NHI terms, the app becomes a non-human identity with real reach, so scope, revocation, and monitoring matter as much as the original account credentials.
• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• PKCE: Proof Key for Code Exchange is a binding mechanism that links the authorization request to the later token exchange. It helps stop authorization code interception and injection by requiring proof that the same client that started the flow is the one completing it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.