TL;DR: OAuth 2.0, JWT bearer tokens, and client credentials are used to secure API calls for eSignature workflows, including token expiry handling and SDK-based token reuse, according to OneSpan’s developer guide. The deeper issue is not token syntax but whether API integrations are governed as identities with scoped, revocable access rather than as convenience shortcuts.
At a glance
What this is: This is a developer-focused guide to securing OneSpan Sign API calls with OAuth 2.0, with the key finding that bearer token handling and expiry governance matter as much as token issuance.
Why it matters: It matters because IAM and NHI teams need to govern API credentials as identities with lifecycle, scope, and revocation controls, not just as implementation details inside application code.
Context
OAuth 2.0 is an authorisation framework for delegated API access, not a substitute for identity governance. In this article’s context, the control problem is how a backend service proves itself to an API, receives a bearer token, and then keeps using that token within the scope it was granted. That matters for eSignature workflows because the data and actions behind the API are operationally sensitive.
The governance gap appears when teams assume token issuance alone is enough. Once client credentials, JWT access tokens, and SDK caching are in play, the real questions become who can mint the token, how long the token remains usable, and whether the integration is managed like a workload identity with revocation and expiry discipline.
This is an NHI pattern even when the surface looks like application plumbing. A service calling an API with bearer tokens is still a non-human identity problem, because access lives in secrets, tokens, and lifecycle behaviour rather than in a human login session.
Key questions
Q: What breaks when OAuth bearer tokens are treated like convenience data instead of identities?
A: The integration loses revocation clarity, scope discipline, and ownership. A bearer token can be reused by anyone who possesses it, so weak storage or logging turns authorisation into portable access. The control failure is not OAuth itself but the assumption that issuance alone is sufficient without lifecycle governance.
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: How do security teams know whether OAuth token expiry is actually working?
A: Look for consistent token renewal, predictable failure when a token expires, and no hidden fallback that keeps stale credentials alive. If custom code and SDK-managed flows behave differently, expiry is not a reliable control. Effective expiry should be visible in operations, not only in code.
Q: How should IAM teams govern service-to-service OAuth clients?
A: Treat each client as a workload identity with an owner, scope, and revocation path. That means assigning accountability, constraining permissions to the exact API use case, and confirming that offboarding actually stops token minting and access use. Otherwise the client becomes a standing credential.
Technical breakdown
Client credentials flow and bearer token trust
The client credentials flow is designed for service-to-service access where the application authenticates itself to an authorisation server and receives an access token for a resource server. In practice, the bearer token becomes the proof of access, so possession equals authority until expiry or revocation. That is why JWT structure matters less than the controls around token issuance, audience, scope, and validation. If the token is copied from logs, memory, or traffic, the API cannot tell whether the original client or an attacker is presenting it. Practical implication: treat the token as a reusable credential with governance requirements, not as a transient implementation detail.
Practical implication: scope client credentials tightly and validate token audience, expiry, and issuer on every API call.
Token expiry, reuse, and SDK-managed renewal
The article’s most operational detail is that access tokens expire and, in the Java and .NET SDKs, token recreation is handled automatically when expiry is reached. That convenience reduces application code, but it also creates an assumption that token reuse is safe because renewal is abstracted away. The real design question is where renewal logic sits, how failures are surfaced, and whether stale tokens can persist in custom integrations outside the SDK path. Practical implication: standardise expiry handling across all integration paths, not only the happy-path SDKs.
Practical implication: verify every integration path handles token renewal and expiry failures consistently, including custom code outside SDK defaults.
Bearer token handling in sensitive API workflows
Bearer tokens are attractive because they avoid sharing user credentials with third-party applications, but that does not remove the need for access governance. In API integrations, the token itself becomes the portable authorisation artefact, so storage, transport, and logging controls matter. Sensitive workflows such as eSignature creation or package management can be abused if a token is over-scoped, retained too long, or exposed through insecure handling. The technical issue is not OAuth syntax. It is whether the integration boundary is protected as an identity boundary. Practical implication: align API token handling with workload identity controls and secret hygiene.
Practical implication: protect bearer tokens with the same controls used for other NHI secrets, including restricted storage, transport protection, and logging review.
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.
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
Bearer-token handling is an identity governance problem, not just an API implementation detail. The article shows that a backend service can obtain and reuse authority through OAuth 2.0 without any human password exchange. That means the security model now depends on how tightly the token is scoped, where it is stored, and how quickly it dies. For practitioners, the relevant unit of governance is the workload identity behind the call chain.
SDK convenience can hide lifecycle risk. Automatic token recreation removes code burden, but it can also conceal who is renewing authority, when renewal fails, and which integrations sit outside the standard path. That makes expiry handling part of access governance rather than a developer convenience feature. Teams should treat SDK-managed renewal as a control surface, not an excuse to ignore token lifecycle.
Long-lived bearer trust creates credential portability risk. A bearer token is usable by whoever possesses it, so transport, memory, and logging exposure turn into direct access risk. OAuth 2.0 narrows credential sharing, but it does not solve token theft or over-scoping. The practitioner conclusion is simple: identity security for APIs lives or dies on bearer-token containment and revocation discipline.
Workload identity should be governed with the same discipline as human access. The article’s server-to-server pattern is not a casual integration shortcut. It is a governed non-human identity with issuer trust, token expiry, and limited API scope. That is exactly where NHI programmes need to stop treating API auth as plumbing and start treating it as an identity lifecycle problem.
Access control shifts from login events to token governance. Traditional human IAM asks who signed in. This pattern asks which service can mint, present, and renew authority on demand. That changes the centre of gravity from authentication experience to lifecycle enforcement, which is why API integrations need inventory, ownership, and offboarding just like any other privileged identity.
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.
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams
What this signals
Bearer token governance will keep surfacing as an NHI issue. Once applications authenticate through OAuth clients, the practical control surface becomes secret handling, token scope, and expiry discipline. That pushes API integrations into the same governance model as other workload identities, because the access path is non-human even when the consumer is software.
API security and identity governance now overlap more tightly. Teams that manage secrets, OAuth clients, and workload identities separately will keep missing the operational link between token minting and revocation. The better model is to inventory API credentials as identities, then enforce ownership and lifecycle rules across every integration path.
For practitioners
- Define ownership for each API client Assign a named owner to every OAuth client, client secret, and token issuer path so expiry, revocation, and scope changes have an accountable team.
- Limit bearer-token scope and audience Restrict each token to the minimum API surface and validate issuer, audience, and expiry on every request, especially for eSignature operations.
- Standardise renewal handling across integrations Make token refresh and expiry failure behaviour consistent in SDK and non-SDK code paths so stale tokens do not survive outside the expected lifecycle.
- Review secret storage for OAuth credentials Keep client secrets out of logs, build output, and shared configuration, and treat them as NHI secrets that require secure storage and rotation.
- Test revocation and offboarding workflows Confirm that disabling a client actually stops token minting and invalidates access quickly enough for the business process that depends on it.
Key takeaways
- OAuth 2.0 secures API calls, but the real risk is whether bearer tokens are governed as revocable identities rather than as reusable implementation artefacts.
- Token expiry and SDK automation help reduce friction, yet they also hide lifecycle failure points if custom integrations do not follow the same renewal rules.
- IAM and NHI teams should treat API clients as workload identities with ownership, scope, storage, and offboarding controls.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | OAuth client handling governs non-human authentication for API access in this article. |
| NHI-07 — Long-Lived Secrets | Client secrets and bearer tokens both create lifecycle risk when they persist too long. | |
| Recommendation — Harden OAuth client authentication and validate token issuance paths for every API integration. Shorten secret and token lifetimes and revoke unused OAuth credentials immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth client secrets and bearer tokens are authenticators that need lifecycle control. |
| AC-6 — Least Privilege | The article stresses limited access scope for API calls and token-based delegation. | |
| Recommendation — Apply authenticator management controls to rotate, revoke, and inventory API credentials. Constrain each OAuth client to least privilege and verify that issued tokens cannot exceed scope. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Bearer token exposure or reuse maps directly to credential access abuse paths. |
| TA0008 — Lateral Movement | A stolen API token can move an attacker deeper into connected eSignature workflows. | |
| Recommendation — Hunt for bearer token exposure and token replay indicators in API authentication telemetry. Trace stolen token use across connected services to limit lateral movement through API trust chains. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | API tokens in this guide are entitlement mechanisms that must be scoped and reviewed. |
| Recommendation — Review API entitlements so every OAuth client has only the permissions it needs. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud control ownership for OAuth clients and service access sits squarely in IAM. |
| Recommendation — Manage OAuth clients and bearer-token access under cloud IAM governance and review their lifecycle. | ||
Key terms
- 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 Credentials Flow: An OAuth 2.0 grant type used for machine-to-machine authentication where an application authenticates directly using its own client ID and secret to obtain an access token. The standard pattern for service-to-service NHI authentication.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Token Expiration Window: A token expiration window is the time period during which a login link remains valid. Short windows reduce exposure if a message is forwarded, intercepted, or delayed, but they must be balanced against email deliverability and user experience. In practice, this is a major control for limiting authentication risk.
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 August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org