OAuth 2.0 for API calls shows why bearer token handling matters

At a glance

What this is: This developer guide explains OAuth 2.0 for API calls and shows how bearer-token authentication, JWTs, and client credentials secure OneSpan Sign integrations.

Why it matters: It matters because API integrations are non-human identities in practice, and IAM teams need to govern their credentials, lifetimes, and revocation paths with the same discipline they apply to other machine access.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read OneSpan's developer guide on securing API calls with OAuth 2.0

Context

OAuth 2.0 is an authorisation pattern, not a substitute for identity governance. In API-heavy environments, the real question is how the client ID, client secret, access token, and token lifetime are controlled when the calling system is effectively a non-human identity.

That matters for IAM, PAM, and NHI programmes because API access often outlives the developer who configured it, the workflow it supports, or the service account that stores the secret. When token handling is weak, the integration becomes a standing credential with a business process attached.

OneSpan’s guide is a typical developer-focused tutorial, but the governance implications are broader than the code examples suggest.

Key questions

Q: How should security teams govern OAuth client credentials in API integrations?

A: Treat the client ID and client secret as non-human credentials with an owner, a purpose, an expiry model, and a revocation path. Inventory them centrally, scope them tightly, and test whether disabling the secret actually stops API access across every environment that can mint or reuse tokens.

Q: Why do bearer tokens create governance risk in API-driven workflows?

A: Bearer tokens confer access to whoever holds them, so the token itself becomes the credential. That means exposure in code, logs, pipelines, or SDK caches can create immediate misuse potential unless the API validates expiry, audience, and signature consistently and the organisation can revoke access quickly.

Q: What do teams get wrong about SDK-managed token renewal?

A: Teams often assume that automatic renewal means the identity problem is solved. In reality, the SDK only hides the refresh mechanics. The application still owns secret protection, token reuse boundaries, logging hygiene, and the business approval model for each API action the service account can perform.

Q: How can security teams know whether OAuth-connected applications are actually under control?

A: They should be able to name every integration owner, every granted scope, every active token, and every revocation trigger. If any of those four elements is missing, the environment does not have real governance over delegated access, only partial visibility.

Technical breakdown

Client credentials flow and bearer token exchange

In a client credentials flow, the application proves its identity to the authorisation server with a client ID and client secret, then receives an access token for API calls. The API accepts the bearer token as proof of authorisation, which means the token becomes the actionable credential. In practice, this shifts the trust boundary from the user to the integration. The security value comes from scoped, time-limited tokens and server-side validation, not from the SDK or the language used to call the API.

Practical implication: Treat the client secret as a governed secret and the bearer token as a short-lived NHI credential with explicit ownership and revocation.

JWT access tokens, expiry, and validation

A JWT access token is a signed token that can carry claims such as issuer, audience, expiry, and token identifier. Those claims help the resource server validate that the token was issued by the expected authority, for the expected API, and only for a bounded period. The important control point is not just token generation, but whether expiry, audience, and signature checks are enforced consistently. If validation is weak, the integration may accept tokens beyond their intended scope or trust boundary.

Practical implication: Verify that token validation is enforced at the API edge and that expired or mis-scoped tokens fail closed.

SDK token caching and renewal mechanics

The Java and .NET SDK behaviour described here caches the authenticated client and reuses the token until expiry, then renews it automatically. That reduces application complexity, but it also hides some credential lifecycle handling from developers. The governance issue is that automation does not remove lifecycle responsibility. The organisation still needs to know where credentials are stored, how token renewal behaves during outages, and what happens when an integration must be disabled quickly.

Practical implication: Map every SDK-managed token path to an owning team, a revocation process, and a credential inventory record.

Threat narrative

Attacker objective: The attacker wants to abuse delegated API access to perform authorised-looking actions without needing user credentials.

1. Entry occurs when an application obtains a client ID and client secret and uses them to request an OAuth access token from the authorisation server.
2. Escalation occurs if the token, client secret, or refresh-like renewal path is exposed in logs, code, CI/CD, or configuration and then reused outside the intended integration boundary.
3. Impact occurs when an attacker or unauthorized process uses the bearer token to call the API as the integration and perform actions within its granted scope.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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 turns API calls into governed identities, not just technical sessions. The article is about developer convenience, but the identity lesson is that client credentials and bearer tokens behave like NHI credentials with a lifecycle. That means ownership, scope, expiry, and revocation must be visible to IAM and security teams, not left inside the application layer. Practitioners should treat every API integration as an identity with a control boundary.

Static client secrets create credential persistence that survives the code path. The guide shows the secret being entered once and then reused through SDK caching and token renewal. That persistence is exactly why NHI governance matters: if the secret is leaked, the integration survives until someone revokes it. Practitioners should read this as a standing-access problem, not a developer tutorial problem.

Bearer token controls only work when the organisation knows where tokens can be minted and replayed. OAuth centralises issuance, but it does not centralise governance unless the client inventory, token lifetime, and revocation path are also centralised. That is where many programmes still split responsibilities across development, platform, and IAM teams. The practical conclusion is that integration identity needs a lifecycle owner.

SDK automation reduces friction but not accountability. Automatic token regeneration is useful operationally, yet it can mask the real question of who can disable the integration, who monitors token abuse, and which systems store the client secret. This is where IAM, PAM, and NHI governance converge. The programme implication is that convenience features must be mapped to explicit control ownership.

Identity blast radius is determined by token scope, not by whether the integration was built in-house or delivered through a vendor SDK. Once a client secret can mint tokens for an API, the meaningful control question is how much authority that token carries and how fast it can be cut off. Practitioners should manage that blast radius as a design constraint, not an afterthought.

From our research:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• The same research reports that only 44% of developers follow security best practices for secrets management, which helps explain why API credentials still leak through the build and deployment chain.
• For a broader view of how secret handling failures become breach paths, see the Secret Sprawl Challenge and the Ultimate Guide to NHIs, static vs dynamic secrets.

What this signals

API security will increasingly be judged as identity governance rather than application plumbing. The organisations that succeed will be the ones that can tell you, at any moment, which integrations hold client secrets, how long those credentials can live, and who can revoke them without waiting for a release cycle.

Identity blast radius: once OAuth is used for machine access, the critical variable becomes the scope and revocation speed of the token, not the elegance of the SDK. Security teams should expect audit pressure to shift from authentication method selection to evidence of lifecycle control, especially where bearer tokens can be cached, renewed, or replayed.

As more workloads and workflows depend on delegated API access, the distinction between developer convenience and governance control will matter more. Programmes that cannot inventory or disable integration identities cleanly will struggle to prove least privilege across NHI, PAM, and IAM domains.

For practitioners

• Inventory every OAuth client as a non-human identity Record the client ID, client secret location, token audience, owner, and revocation path for each integration so security and IAM teams can see the full access surface.
• Set explicit token lifetime and rotation rules Require short-lived access tokens, time-boxed client secret rotation, and a documented process for replacing credentials before they become difficult to trace.
• Separate SDK convenience from governance control If Java or .NET SDKs auto-renew tokens, make sure the renewal path is still logged, monitored, and tied to a named application owner.
• Test revocation as an operational runbook Validate that disabling a client secret or token actually blocks API access across all environments, including sandbox, production, and cached client sessions.

Key takeaways

• OAuth 2.0 secures API calls only when the underlying client credentials and tokens are treated as governed non-human identities.
• The real control problem is lifecycle management, because bearer tokens and client secrets create a reusable access path that can outlive the workflow that created it.
• Security teams should inventory, scope, renew, and revoke integration credentials as if they were any other privileged identity, because functionally they are.

Key terms

• OAuth Client: An OAuth client is the application or service that requests delegated access on behalf of a user or workload. In identity governance terms, it is a non-human identity that must be owned, scoped, and revoked like any other privileged integration.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Token Lifetime: Token lifetime is the period during which an issued access token remains valid. In machine and API access, short lifetimes reduce exposure if a token leaks, but they do not replace governance. Organisations still need to know who can mint tokens and how quickly access can be cut off.
• Integration identity: An integration identity is the non-human credential or trust relationship used to connect one system to another. In practice, it often includes API keys, OAuth grants, service accounts, certificates, and the permissions that let automation read, transform, or publish identity data.

What's in the full article

OneSpan's full developer guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step cURL examples for obtaining and using OAuth access tokens with OneSpan Sign APIs
• Java and .NET SDK configuration details for automatic token reuse and renewal
• Specific request parameter handling, including how grant_type must be sent as form data in release 24.R5
• Implementation-oriented notes on sandbox API calls, authentication server settings, and client caching behaviour

👉 OneSpan's full guide includes cURL examples, SDK token handling, and API request details for implementation teams.

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.