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