Every OAuth token issued by your identity provider represents a non-human identity with standing access to something. Your SaaS integrations, CI/CD pipelines, internal microservices, and third-party applications each hold tokens that authenticate as your organisation — silently, continuously, without the friction of a login prompt. Understanding the lifecycle of those tokens — and the governance failures that accumulate across it — is the foundation of any serious NHI security programme.
How Tokens Are Born: The Shadow IT Problem
OAuth token issuance in enterprise environments is rarely a controlled, centralised process. Developers connecting a new SaaS tool to their Slack workspace, a product manager authorising a reporting integration with the company's Google Workspace, a data analyst granting a third-party analytics platform access to the data warehouse — each of these interactions creates a token. Each token carries scopes. Each token persists until it is explicitly revoked or its refresh chain is interrupted.
In a mature enterprise, this informal token creation — shadow IT at the credential layer — results in hundreds of active OAuth authorisations that security and identity teams have never reviewed. The organisation's identity provider holds the record of these grants, but that record is rarely consulted. Most OAuth tokens are created with no owner of record beyond the individual employee who clicked "Authorise", no expiry policy beyond the identity provider's default (often indefinite for refresh tokens), and no decommissioning plan for when the employee leaves or the integration is abandoned.
Discovery exercises at enterprises running their first NHI audit consistently find OAuth grants to applications that have been decommissioned, vendors whose contracts have lapsed, and third-party tools whose security posture has materially changed since the grant was issued. Each one is an active credential — and an active attack surface.
Scope Creep: The Silent Privilege Escalation
OAuth scopes define what a token can do. In practice, they are almost always over-provisioned. The reason is operational: developers request broad scopes to avoid having to re-authorise integrations when they need additional capabilities later. The result is a population of tokens holding permissions that far exceed what the consuming application ever uses.
Scope creep compounds over time. An integration provisioned with read:all scope two years ago may have only ever needed read:reports. The excess scope has persisted for two years, representing two years of unnecessary blast radius if that token is compromised. At scale — across an enterprise with hundreds of OAuth-connected applications — the aggregate over-privilege is substantial and rarely visible in any single system.
Effective token governance requires scope auditing: comparing the permissions a token holds against the permissions the consuming application actually exercises. This requires log-level visibility into API calls made using each token — a capability that many enterprises have not built, because the need for it only becomes apparent after an incident where an attacker used broad scopes to pivot well beyond their initial foothold.
OAuth access tokens are short-lived by design — typically 15 minutes to an hour. But refresh tokens, which allow applications to obtain new access tokens without user re-authentication, are often valid for months or indefinitely. A compromised refresh token is effectively a permanent credential: the attacker can generate fresh access tokens at will. Refresh token rotation and expiry policies are the most important and most overlooked control in OAuth token lifecycle management.
The Rotation Trap
Token rotation — regularly replacing long-lived credentials with new ones — is widely recommended and widely misunderstood. Rotation addresses the risk that a credential has already been compromised and is being silently used by an attacker. It does not address over-provisioning, orphaned tokens from decommissioned integrations, or tokens held by applications with poor secrets management practices that will simply store the rotated token in the same insecure location as the original.
Rotation strategies that do not account for how applications consume and store tokens can introduce new risks. An application that hard-codes its OAuth client secret in source code will have the rotated secret hard-coded in the next commit. An application that stores its refresh token in an unencrypted database field will store the replacement the same way. Rotation without remediation of the underlying storage and handling practices rotates the credential but not the risk.
The architecture target for OAuth token security is short-lived access tokens (15 minutes or less) with refresh token rotation enabled — meaning each refresh operation issues a new refresh token and invalidates the previous one. This limits the window of exposure from any single token compromise to the access token lifetime, and means a compromised refresh token can only be used once before the legitimate application triggers rotation and the attacker's copy becomes invalid.
Revocation: Why It Doesn't Work at Scale
OAuth token revocation is technically specified (RFC 7009) but operationally underdeveloped in most enterprises. The fundamental challenge is that revocation requires the relying party — the application consuming the token — to check revocation status on each use, or the authorisation server to push revocation notifications to relying parties. Most SaaS applications do neither: they accept tokens that appear structurally valid without checking whether the token has been revoked at the issuing authority.
This means that revoking a token at the identity provider level — which is the correct response to an employee departure or a vendor offboarding — does not reliably terminate access at the application level until the token expires. For long-lived tokens, that window can be significant. The practical consequence: token revocation on employee offboarding must be paired with direct API calls to each connected application's revocation endpoint, not just the identity provider's revocation mechanism. Automating this at scale requires a complete, current inventory of every OAuth-connected application — which brings us back to discovery.
Governance, Not Just Rotation
The organisations that manage OAuth token risk effectively treat it as an identity governance problem, not a credential management problem. Every token is a non-human identity: it needs an owner, a documented purpose, a scope justified by actual usage, and a lifecycle that ends when the purpose ends. The identity provider's token management interface is the starting point for visibility, but it is not sufficient on its own.
Effective governance adds three layers: continuous discovery (monitoring new token grants as they occur, not just auditing annually), scope right-sizing (using API access logs to identify and trim over-privileged scopes), and automated decommissioning (revoking tokens when the associated user leaves, when the connected application is removed from the approved vendor list, or when no API activity has been recorded within a defined window). Each layer reduces the ambient risk that any single token compromise becomes a significant breach — because governance determines how much a compromised token can actually do.