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.
Editorial analysis by NHI Mgmt Group, based on content published by OneSpan: “Développeurs OneSpan Sign : Comment sécuriser les appels API avec OAuth 2.0”.
By the numbers:
- Access tokens expire after 299 seconds in the OneSpan Sign API flow described in the article.
Key questions
Q: What breaks when OAuth 2.0 token expiry is the only control for API access?
A: Token expiry reduces exposure only if the credential that mints the token is protected.
Q: Why do machine-to-machine APIs still need secrets governance after moving to OAuth 2.0?
A: OAuth changes how access is delegated, but it does not remove the need to protect the secret that authenticates the client.
Q: How can security teams tell whether SDK-based token renewal is safe?
A: Look for clear ownership of the OAuth client, visible token refresh events, environment separation, and evidence that the SDK does not cache credentials outside the intended runtime.
Practitioner guidance
- Inventory every OAuth client used for eSignature access Record the owning application, environment, client secret location, token lifetime, and the human team accountable for each OneSpan integration.
- Treat client secrets as privileged machine credentials Store them in approved secrets management, restrict retrieval to the runtime that mints tokens, and remove any shared or developer-owned copies.
- Make token renewal observable Log token minting, expiry-driven refresh, and abnormal regeneration patterns so the security team can see when a service is repeatedly reissuing bearer tokens.
Bottom line: OAuth 2.0 improves API delegation for eSignature workflows, but the governance burden shifts to the credentials that request and renew access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:57 am
Short-lived tokens are not the same thing as governed machine identity. The article reduces token exposure, but the identity problem sits one layer deeper in the client secret, renewal path, and application cache. That means the programme is not securing an access token alone, it is governing the full credential issuance chain. Practitioners should treat the issuing secret, not the token, as the durable control point.
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.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: Should organisations manage OAuth client secrets as part of NHI governance?
A: Yes. OAuth client secrets are non-human credentials that control access to APIs, so they belong in the same governance lifecycle as other machine identities. That includes ownership, rotation, offboarding, and environment-specific segregation. If they are treated as ordinary application config, the organisation loses control of delegated API access.
👉 Read our full editorial: OAuth 2.0 for eSignature APIs: what OneSpan developers need to know