Notifications
Clear all
Topic starter
25/06/2026 12:53 am
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.
NHIMG editorial — based on content published by OneSpan: Développeurs OneSpan Sign: Comment sécuriser les appels API avec OAuth 2.0
By the numbers:
- OneSpan notes that access tokens expire in 299 seconds, so a new token must be generated when the current token expires.
Questions worth separating out
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.
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.
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
- 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.
What's in the full article
OneSpan's full article covers the operational detail this post intentionally leaves for the source:
- Copy-paste cURL examples for obtaining and using OAuth tokens against the OneSpan Sign sandbox API
- Java and .NET SDK configuration snippets showing how token refresh and client caching are implemented
- Parameter-by-parameter request and response examples for client credentials flow and bearer token handling
- Console navigation steps for generating client ID and client secret in the OneSpan Sign admin interface
👉 Read OneSpan's guide to securing OneSpan Sign API calls with OAuth 2.0 →
OAuth 2.0 for OneSpan Sign APIs: are your token controls ready?
Explore further
25/06/2026 9:57 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth 2.0 for eSignature APIs: what OneSpan developers need to know
