Notifications
Clear all
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.
NHIMG editorial — based on content published by OneSpan: OneSpan Sign developers, how to secure API calls with OAuth 2.0
Questions worth separating out
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.
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: What do teams get wrong about SDK-managed token renewal?
A: Teams often assume that automatic renewal means the identity problem is solved.
Practitioner guidance
- 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.
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
👉 Read OneSpan's developer guide on securing API calls with OAuth 2.0 →
OAuth 2.0 API calls and bearer tokens: are your controls enough?
Explore further
01/08/2026 9:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth 2.0 for API calls shows why bearer token handling matters
