OAuth 2.0 remains foundational, but IAM assumptions still break

At a glance

What this is: OAuth 2.0 is a delegated authorization standard that swaps direct password sharing for token-based access, with the authorization code flow as its common operating pattern.

Why it matters: IAM and NHI teams need to govern OAuth carefully because the same delegation model that improves usability can also widen blast radius when tokens, clients, or scopes are over-trusted.

👉 Read Beyond Identity's explanation of OAuth 2.0 authorization flows

Context

OAuth 2.0 is an authorization standard, not a full identity control plane. It lets one application access another service on a user’s behalf, which is useful for user experience but creates governance questions around scope, client trust, token lifetime, and revocation. For IAM and NHI programmes, the concern is not whether OAuth works. It is whether the organisation can see and control every delegated grant, especially when third-party apps and automation enter the picture.

The article presents OAuth 2.0 as simple at the point of use, and that is exactly why it can be easy to under-govern. In practice, delegated access creates non-human identity behaviour inside enterprise systems, because tokens and client credentials can persist beyond the original user action. That makes OAuth a core NHI governance topic, not just an application integration pattern. For teams building controls, the right question is whether the environment can continuously account for who or what is acting with delegated authority.

Key questions

Q: How should security teams govern OAuth 2.0 in enterprise environments?

A: Security teams should govern OAuth 2.0 as a delegated access model with lifecycle controls. That means inventorying clients, limiting scopes, reviewing grants on a schedule, and revoking stale tokens and client secrets. OAuth is safest when it is treated as managed NHI behaviour rather than a one-time integration choice.

Q: Why do OAuth tokens create risk for NHI governance?

A: OAuth tokens create risk because they act like credentials for non-human access. If they are long-lived, over-scoped, or poorly monitored, they can preserve access long after the original business need has ended. NHI programmes need visibility into issuance, usage, and revocation or those tokens become hidden privilege paths.

Q: What is the difference between OAuth 2.0 and OIDC?

A: OAuth 2.0 governs authorization, while OIDC adds an identity layer for authentication. OIDC tells you who signed in, but OAuth controls what the application can do after sign-in. Organisations need both, but they must not confuse login assurance with downstream API authority.

Q: When should organisations treat OAuth as a security control issue?

A: Organisations should treat OAuth as a security control issue whenever third-party apps, automation, or high-value APIs are involved. The protocol itself is not the risk. The risk appears when scopes are broad, tokens persist, or ownership of grants is unclear. That is when OAuth becomes an access governance problem.

Technical breakdown

How the OAuth 2.0 authorization code flow works

OAuth 2.0 separates authentication from authorization by issuing an authorization code first, then exchanging it for an access token. The client redirects the user to the authorization server, the server validates the client and user consent, and the client later trades the code for a token that can call APIs. Refresh tokens may extend that session without re-prompting the user. The security value comes from avoiding direct password disclosure, but the architecture still depends on trust in the client, correct redirect handling, and scope discipline.

Practical implication: Review every OAuth client as a delegated trust relationship, not a convenience feature.

Why OAuth tokens create NHI governance problems

An access token is effectively a temporary credential that can act with specific rights until expiry or revocation. In enterprise environments, that makes it an NHI artifact because it represents non-human access with execution authority. The governance problem is that tokens often outlive the original business need, and their scope can be broader than the task requires. If teams do not inventory token issuance, usage, and revocation, OAuth becomes a shadow access layer that bypasses normal identity review cycles.

Practical implication: Treat OAuth tokens as managed secrets and include them in discovery, rotation, and offboarding processes.

OAuth, OIDC, and delegated access boundaries

OAuth 2.0 handles authorization, while OIDC adds an identity layer for federated authentication. That distinction matters because teams sometimes assume that a signed-in user session automatically means safe delegated access. It does not. OIDC can confirm who authenticated, but OAuth still governs what the client can do afterwards. Many risks arise when organisations conflate login assurance with downstream API authority, especially in app-to-app integrations and third-party consent models.

Practical implication: Separate login assurance from delegated API privilege in policy, review, and monitoring.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 2.0 is now an NHI governance problem, not just an application protocol. The standard relies on access tokens, client secrets, and delegated grants that behave like non-human credentials. That means every OAuth deployment creates a population of machine-executed rights that must be inventoried, reviewed, and revoked like any other NHI. Practitioners should stop treating OAuth as a point integration and start treating it as a governed identity surface.

Delegation without lifecycle control creates hidden privilege persistence. OAuth is designed to reduce password exposure, but it can also leave behind long-lived access paths that no one revisits after the initial consent event. When clients, scopes, and refresh tokens are not lifecycle-managed, the organisation inherits access that is technically valid but operationally stale. Practitioners should map OAuth grants into access review and offboarding workflows.

Ephemeral token issuance does not solve trust assumptions. Short-lived tokens can reduce exposure windows, but they do not fix over-broad scopes, weak client validation, or poor revocation discipline. The real governance challenge is the relationship between the user, the client, and the downstream resource server. Practitioners should evaluate OAuth controls as part of Zero Trust and least-privilege enforcement, not as a substitute for them.

OIDC reduces ambiguity at login, but it does not govern what happens next. Identity confirmation and authorization are related but not interchangeable, and teams that blur the two lose visibility into delegated access paths. That confusion becomes more expensive as third-party apps and automation increase. Practitioners should separate authentication assurance from API entitlement governance in their control design.

OAuth sprawl is a visibility problem before it is a technology problem. The hardest failure mode is not the protocol itself, but the number of grants, apps, and tokens that accumulate outside normal review. Once that sprawl exists, revocation becomes reactive and incomplete. Practitioners should build an OAuth inventory before they expand usage further.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• For a broader control lens, review OWASP Non-Human Identity Top 10 alongside this guidance to map OAuth grants to NHI risk classes.

What this signals

OAuth governance should be folded into NHI lifecycle management now, not after the next delegated-access incident. The operational issue is not whether an app can get a token. It is whether the organisation can prove who owns that token, when it expires, and how it is revoked. With only 20% of organisations having formal processes for offboarding and revoking API keys, according to the Ultimate Guide to NHIs, the control gap is already familiar.

Delegated access will keep expanding as AI systems and automation consume more APIs. That means OAuth reviews need to sit beside service account reviews, secrets rotation, and privileged access controls, not in a separate application security silo. Teams that align OAuth monitoring with the NIST Cybersecurity Framework 2.0 will find it easier to connect grant inventory, detection, and recovery into one operating model.

Identity blast radius is the right lens for modern OAuth programmes. Once a client is trusted, it can inherit authority quickly across applications and data domains. The practical response is to narrow consent, shorten token life where possible, and make revocation observable across systems. That is how OAuth moves from a convenience layer to a governed control surface.

For practitioners

• Inventory all OAuth clients and grants Create a complete register of authorized clients, scopes, refresh tokens, and owning business units. Include third-party apps, internal automation, and any service that can request delegated access.
• Limit scopes to the minimum viable access Review every permission request against the actual business task and remove broad, persistent, or speculative access. Prefer narrow scopes that can be approved and revoked independently.
• Add OAuth grants to access review workflows Treat delegated grants like other NHI entitlements. Re-certify them on a fixed cadence, tie them to application owners, and revoke grants that no longer map to an active use case.
• Monitor refresh token and client secret exposure Track where tokens and secrets are stored, where they are used, and how quickly they can be revoked. Include logs for consent changes, anomalous client behavior, and repeated token refreshes.

Key takeaways

• OAuth 2.0 reduces password exposure, but it introduces delegated access that must be governed like any other NHI surface.
• The main risk is not the protocol itself, but long-lived grants, broad scopes, and weak revocation discipline.
• Teams should inventory OAuth clients, tie grants to ownership, and fold token lifecycle control into NHI governance.

Key terms

• OAuth 2.0: OAuth 2.0 is an authorization protocol that lets one application access another service on a user’s behalf without sharing the user’s password. It uses tokens and scoped consent so access can be delegated, limited, and revoked, which makes it a core control surface for modern IAM and NHI governance.
• Access Token: An access token is a credential issued by an authorization server that allows a client to call protected APIs for a limited time and within defined permissions. In practice, it behaves like a short-lived non-human credential, so expiry, scope, storage, and revocation all matter to security teams.
• Authorization Code Flow: Authorization code flow is the common OAuth pattern where the client first receives a temporary code and then exchanges it for an access token. The design keeps tokens off the front channel and reduces exposure, but it still depends on correct client validation and careful redirect handling.
• Delegated Access: Delegated access is the practice of allowing one application or service to act with authority derived from a user or another system. It is useful for automation and integration, but it also creates hidden privilege paths when ownership, scope, and expiry are not actively governed.

Deepen your knowledge

OAuth 2.0 governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to turn OAuth grants into a managed identity surface, it is worth exploring.

This post draws on content published by Beyond Identity: What is OAuth 2.0? Read the original.