TL;DR: OAuth 2.0, JWT bearer tokens, and the client credentials flow are used to secure API calls without exposing user credentials, according to OneSpan’s developer guide, while noting that access tokens expire after 299 seconds and must be regenerated. The real governance issue is that short-lived tokens reduce exposure but do not eliminate trust assumptions around service credentials, token handling, and SDK-side caching.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Securing OneSpan Sign API calls with OAuth 2.0 relies on short-lived access tokens, but credential handling and renewal still raise governance questions.
Why it matters: IAM and NHI teams need to treat API authentication design as a lifecycle problem, not just a protocol choice, because service credentials, token expiry, and client-side caching all shape blast radius.
By the numbers:
- Access tokens expire after 299 seconds in the OneSpan Sign API flow described in the article.
Context
OAuth 2.0 is an authorisation framework that lets an application call an API on behalf of a resource owner without exposing the user's credentials. In this article, the identity problem is not human sign-in but how a backend service authenticates to eSignature APIs with scoped tokens, client credentials, and renewal logic.
That makes the governance question one of machine-to-machine access control. The controls that matter are secret handling, token lifetime, cache behaviour, and whether the application can reissue credentials safely when the token expires.
OneSpan's guide is therefore best read as an implementation example of API identity governance rather than a product story. The practitioner concern is whether the integration keeps service credentials out of reach while still limiting the usable window of any token that is issued.
Key questions
Q: What breaks when OAuth 2.0 token expiry is the only control for API access?
A: Token expiry reduces exposure only if the credential that mints the token is protected. If the client secret leaks, an attacker can request fresh tokens indefinitely, so the real failure is treating the bearer token as the only security boundary. Teams need lifecycle control over the issuing credential, not just the access token.
Q: Why do machine-to-machine APIs still need secrets governance after moving to OAuth 2.0?
A: OAuth changes how access is delegated, but it does not remove the need to protect the secret that authenticates the client. The service credential still determines who can mint tokens, where they can be refreshed, and how far the compromise can spread if the secret is reused or exposed.
Q: How can security teams tell whether SDK-based token renewal is safe?
A: Look for clear ownership of the OAuth client, visible token refresh events, environment separation, and evidence that the SDK does not cache credentials outside the intended runtime. Safe renewal is observable and scoped. If the refresh logic is opaque, teams cannot prove where the credential lives or who can use it.
Q: Should organisations manage OAuth client secrets as part of NHI governance?
A: Yes. OAuth client secrets are non-human credentials that control access to APIs, so they belong in the same governance lifecycle as other machine identities. That includes ownership, rotation, offboarding, and environment-specific segregation. If they are treated as ordinary application config, the organisation loses control of delegated API access.
Technical breakdown
How the client credentials flow changes API trust boundaries
The client credentials flow is used when a backend service, not a person, needs access to an API. The client authenticates with a client ID and client secret, receives an access token from the authorisation server, and then presents that token as a bearer credential to the resource server. In this pattern, the API never sees a user password, but it does inherit trust in the application that holds the client secret. The important technical distinction is that the token is an authorisation artefact, not an identity proof for a human operator.
Practical implication: govern the client secret as a privileged machine credential, not as a normal application setting.
Why short-lived bearer tokens still depend on secret hygiene
Bearer tokens reduce exposure because possession is sufficient for use and expiration limits the window of abuse. That does not mean the surrounding control plane is safe. If the client secret is copied into logs, cached in SDK state, or reused across environments, an attacker can mint fresh tokens even after one token expires. The article's 299-second expiry reduces dwell time, but the real security boundary is the lifecycle of the credential that can obtain the token in the first place.
Practical implication: protect the issuing secret with the same discipline you would apply to any long-lived service credential.
SDK caching turns renewal into a governance control
The article notes that the Java and .NET SDKs cache clients and automatically regenerate tokens when they expire. That convenience shifts responsibility from the caller to the library. The technical risk is not token reuse by itself, but opaque renewal behaviour that can hide when credentials are refreshed, where they are held in memory, and whether the application can distinguish expected renewal from abnormal repeated minting. In NHI terms, caching is an operational control that must be observable, not just functional.
Practical implication: monitor token minting and SDK cache behaviour so renewal events are visible to security operations.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Short-lived tokens are not the same thing as governed machine identity. The article reduces token exposure, but the identity problem sits one layer deeper in the client secret, renewal path, and application cache. That means the programme is not securing an access token alone, it is governing the full credential issuance chain. Practitioners should treat the issuing secret, not the token, as the durable control point.
SDK automation can hide the real custody boundary for NHI credentials. When a library regenerates tokens automatically, teams may lose sight of where the credential lives, who can access it, and whether it crosses environment boundaries. The useful security question is not whether renewal works, but whether renewal is constrained, logged, and attributable. Practitioners should audit the runtime path, not just the OAuth settings screen.
Ephemeral access reduces blast radius but does not resolve trust assumptions. OAuth still assumes the client can be trusted to hold credentials, request tokens correctly, and present them only where intended. That assumption is manageable in a tightly controlled backend service and much weaker in distributed development or shared integration environments. Practitioners should map where client credentials can persist beyond the intended service boundary.
Token governance for eSignature APIs belongs in NHI lifecycle controls, not ad hoc developer practice. This article is a reminder that API access design is a lifecycle issue: issue, store, use, renew, and retire. The identity model is service-to-service, so recertification, offboarding, and secret rotation should be designed around the integration itself. Practitioners should formalise ownership for every OAuth client used by an eSignature workflow.
OAuth 2.0 for eSignature is best understood as controlled delegation, not credential elimination. The protocol removes password sharing, but it replaces that with bearer-token trust and secret stewardship. That is a better model only when the delegated authority is scoped, the issuing secret is protected, and the renewal path is visible. Practitioners should align the integration to least privilege at issuance time, not assume the protocol alone enforces it.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Read next: API Key Management Guide
What this signals
Ephemeral bearer tokens shrink exposure, but the durable risk sits in the credential that can mint them. OAuth 2.0 adoption should push teams to govern client secrets as high-value NHI assets, with renewal visibility and environment scoping built into the programme. According to the State of Secrets in AppSec, only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
For identity teams, this is a reminder that protocol choice does not equal governance maturity. A token that expires in minutes still depends on a secret that can live much longer, and that mismatch is where control assumptions often fail.
For practitioners
- Inventory every OAuth client used for eSignature access Record the owning application, environment, client secret location, token lifetime, and the human team accountable for each OneSpan integration.
- Treat client secrets as privileged machine credentials Store them in approved secrets management, restrict retrieval to the runtime that mints tokens, and remove any shared or developer-owned copies.
- Make token renewal observable Log token minting, expiry-driven refresh, and abnormal regeneration patterns so the security team can see when a service is repeatedly reissuing bearer tokens.
- Separate environments for OAuth credentials Use distinct client IDs and secrets for sandbox, test, and production so a token or secret from one environment cannot be replayed in another.
Key takeaways
- OAuth 2.0 improves API delegation for eSignature workflows, but the governance burden shifts to the credentials that request and renew access.
- A short token lifetime limits abuse windows, yet the client secret and the SDK renewal path remain the controls that determine real blast radius.
- Teams that already manage NHI lifecycle and secrets governance are better placed to control OAuth-based API access without relying on developer discipline alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on OAuth client authentication for a non-human API integration. |
| NHI-07 — Long-Lived Secrets | The client secret outlives individual access tokens and remains the durable control point. | |
| Recommendation — Use NHI-04 to verify client authentication and token issuance paths for the eSignature API. Apply NHI-07 to shorten secret lifetime and remove stale OAuth client credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth client secrets and token renewal are authenticator lifecycle concerns. |
| Recommendation — Enforce IA-5 to govern issuance, rotation, and retirement of OAuth client credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling API authorisation scope and delegated access. |
| Recommendation — Apply PR.AA-05 to keep OAuth scopes and delegated access aligned to business need. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API calls rely on token-based authentication that must be validated and renewed safely. |
| Recommendation — Use API2 controls to validate bearer-token authentication and protect the token issuance path. | ||
Key terms
- OAuth 2.0 Client Credentials: OAuth 2.0 Client Credentials is a grant type for machine to machine authentication where an application proves its identity directly to a token endpoint. The client exchanges its own credentials for a short lived access token, with no end user consent or redirect flow. It fits service integration and provisioning workloads well.
- 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.
- Client Secret: A client secret is a credential used by an application to prove its identity to an identity provider during token exchange. In OIDC, it functions like a password for the workload, so exposure in code, logs, or build artifacts can enable impersonation and downstream access.
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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org