OAuth 2.0 for eSignature APIs: what OneSpan developers need to know

At a glance

What this is: This is a developer-focused guide to securing OneSpan Sign API calls with OAuth 2.0, JWT bearer tokens, and client credentials.

Why it matters: It matters because API auth patterns shape how IAM, PAM, and NHI teams govern service credentials, token lifetimes, and delegated access across application integrations.

By the numbers:

• OneSpan notes that access tokens expire in 299 seconds, so a new token must be generated when the current token expires.

👉 Read OneSpan's guide to securing OneSpan Sign API calls with OAuth 2.0

Context

OAuth 2.0 is an authorization framework for limiting what an application can do with an API without sharing the user’s password. In this article, the primary identity problem is NHI governance: how a backend service proves itself, receives a token, and uses that token safely across OneSpan Sign API calls.

That matters because service credentials, bearer tokens, and SDK-managed token caching all create a trust boundary that is easy to describe but easy to misuse. For IAM and NHI teams, the question is not whether OAuth is modern enough, but whether the surrounding credential handling, token lifespan, and revocation assumptions are actually enforced.

The article is a practical implementation guide, not a threat report. It is typical of enterprise API integration work, where authentication details are often treated as plumbing even though they define the security model for the whole workflow.

Key questions

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

A: Treat client credentials as non-human identities with lifecycle ownership, rotation expectations, and scoped access. Store them in a secrets manager, restrict who can retrieve them, and review whether the connected application really needs the permissions it has. The main control objective is to prevent the credential from becoming a permanent, broadly reusable access path.

Q: Why do short-lived bearer tokens still need governance?

A: Short-lived bearer tokens reduce replay exposure, but they do not prevent misuse after issuance. If the client secret is exposed, if scopes are too broad, or if token handling is weak, the integration can still be abused within the valid window. Governance has to cover issuance, storage, use, and revocation, not just expiry.

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: Who is accountable when a service account used for API access is over-privileged?

A: The accountable owners are the application team, the identity governance function, and the platform team that issued the integration. Over-privilege in an API path is a governance failure, not just a developer issue, because it affects access scope, auditability, and revocation across the whole workflow.

Technical breakdown

Client credentials flow and bearer token issuance

The client credentials flow is a server-to-server OAuth pattern where an application authenticates with a client ID and client secret, then receives an access token from the authorization server. The token is presented to the resource server as a bearer credential, which means possession of the token is enough to access the API until expiry. In this model, the authorization server becomes the policy checkpoint, while the API depends on token validation rather than direct credential reuse. The security value comes from narrowing exposure, but the control only holds if client secrets are protected and token scope is tightly bounded.

Practical implication: treat client ID and client secret as governed NHI credentials, not developer conveniences.

JWT bearer tokens and token validation

JWT bearer tokens carry signed claims that the API can validate or forward to an authorization service for verification. The important distinction is between authentication of the client and authorization for the specific API action. A signed token can still be over-privileged, replayed within its lifetime, or cached in unsafe places. For eSignature workflows, that matters because the token often represents a backend service rather than a human. The design reduces password exposure, but it shifts the control problem to token handling, claim trust, and revocation boundaries.

Practical implication: validate token claims, scope, and audience before allowing signing or package operations.

SDK token caching and expiry handling

The Java and .NET SDK examples show client reuse and token caching, with the SDK checking expiry and regenerating tokens when needed. That is operationally convenient, but it also means the application now inherits responsibility for safe in-memory handling and for preventing tokens from outliving the intended trust context. A cached bearer token is still a credential, even if it is short-lived. In NHI terms, the control question is not only how to obtain the token, but where it persists, who can reuse it, and whether expiry is the only limiter the programme relies on.

Practical implication: inventory SDK caching behaviour and verify that token persistence is bounded to the application process.

NHI Mgmt Group analysis

Bearer-token security is a credential governance problem, not just an API pattern. OAuth 2.0 reduces password exposure, but it does not remove the need to govern service identities, secrets, and token handling as first-class NHI assets. The security boundary shifts from user authentication to client credential protection and token lifecycle control. Practitioners should read the pattern as workload identity governance in disguise, because the access path is only as safe as the service credential behind it.

Short-lived tokens narrow exposure, but they do not solve trust at the point of issuance. The article’s 299-second expiry shows that one control can reduce replay window without addressing who can obtain the token in the first place. That is the classic NHI mistake: assuming token lifetime is equivalent to access governance. The real issue is whether the client secret, the authorization server, and the API all enforce the same entitlement boundary.

SDK-managed caching creates a hidden identity persistence layer. When libraries automatically regenerate tokens, the application team may stop thinking about credential state even though the credential still exists in memory and operational logs can still become sensitive. This is the kind of control abstraction that makes NHI governance uneven across platforms. The practical conclusion is that developers, IAM, and platform teams must align on where token state lives and how it is monitored.

Least privilege for APIs must be expressed at the service identity level, not only at the endpoint level. OAuth scopes and bearer tokens can limit access, but if the service account behind the integration is broadly privileged, the API pattern simply wraps excessive access in a cleaner protocol. That matters for eSignature because the workflow is business-critical and often integrated into broader document or CRM processes. Practitioners should treat the service account as the real policy object, not the token alone.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, 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, according to The State of Secrets in AppSec.
• For a broader identity lens, see Ultimate Guide to NHIs, 2025 Outlook and Predictions for how secret handling and workload identity are converging.

What this signals

Bearer-token governance is becoming a workload identity issue, not a pure API concern. As more integrations rely on short-lived tokens, the control plane shifts toward secret inventory, service ownership, and runtime visibility. Teams that still manage these links as developer convenience cases will miss the point that the service account is the policy object, not the token itself.

Ephemeral access reduces blast radius only if the surrounding secret lifecycle is real. The security model still depends on who can mint credentials, where they are cached, and whether they are discoverable in logs or memory. NHI programmes should track those hidden persistence points as part of normal identity governance, not as an exception path.

Secret handling failures continue to outlast the technical controls designed to prevent them. The 27-day remediation figure in The State of Secrets in AppSec shows why short-lived tokens cannot compensate for slow operational response. For practitioners, the next step is to align secrets management, API ownership, and runtime monitoring around the same identity record.

For practitioners

• Classify API credentials as governed NHI assets Register the client ID, client secret, token endpoint, and SDK owner in your identity inventory so the integration has a clear lifecycle owner and review cadence.
• Bound bearer token handling to the application runtime Confirm where access tokens are stored, how long they remain in memory, and whether logs, crash dumps, or debug traces can expose them.
• Scope service access to the minimum signing workflow Limit the integration to the specific OneSpan Sign actions it needs, then test whether package creation, signer updates, or document retrieval can be blocked independently.
• Review SDK cache behaviour before production release Validate how the Java and .NET clients regenerate tokens, what happens on expiry, and whether proxy or header settings introduce wider exposure than expected.

Key takeaways

• OAuth 2.0 improves API security, but the real control surface remains the service identity behind the integration.
• Short token lifetimes reduce replay risk, yet broad scopes, weak secret handling, and hidden SDK caching can still expose the workflow.
• Identity, IAM, and platform teams should treat API credentials as governed NHI assets with explicit ownership, expiry, and monitoring.

Key terms

• Client Credentials Flow: A server-to-server OAuth pattern where an application authenticates with its own credentials and receives an access token to call an API. In identity governance terms, the application is the subject, so the credential must be managed like a non-human identity with ownership, scope, and expiry.
• Bearer Token: A bearer token is an access token that grants access to an API to whoever presents it while it remains valid. Because possession is enough, the token must be protected like a credential, with careful handling in memory, logs, and transport paths.
• SDK Token Caching: SDK token caching is the practice of storing an access token in client memory so repeated API calls do not need to fetch a new one each time. It improves efficiency, but it also creates a hidden persistence layer that must be governed as part of the identity lifecycle.
• Workload Identity: Workload identity is the identity assigned to an application, service, or integration rather than to a person. It is governed through secrets, tokens, certificates, and lifecycle controls, and it becomes the real security subject whenever machine-to-machine access is in use.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by OneSpan: Développeurs OneSpan Sign: Comment sécuriser les appels API avec OAuth 2.0. Read the original.