Topic starter
01/08/2026 8:57 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by OneSpan: “OneSpan Sign developers: How to secure API calls with OAuth 2.0”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth 2.0 for API calls shows why bearer token handling matters