TL;DR: Scripts and integrations can authenticate to API access without passwords through a signed and encrypted challenge, server-issued tokens, and token refresh logic, according to PassBolt. The pattern reinforces that secrets and token lifecycle controls remain decisive even when authentication is cryptographically elegant.
Editorial analysis by NHI Mgmt Group, based on content published by PassBolt: “So you want to play with the passbolt API? Let’s talk about JWTs.”.
Key questions
Q: What breaks when JWT-based API authentication is treated as a one-time login problem?
A: The failure is usually in lifecycle governance, not in the authentication exchange itself.
Q: Why are refresh tokens riskier than access tokens after compromise?
A: Access tokens are usually short-lived, so their damage window is limited.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Define separate lifecycle rules for signing keys and tokens Track the private GPG key, access token, and refresh token as different assets with different rotation and revocation triggers.
- Review refresh-token exposure paths Map where refresh tokens are stored, logged, cached, or forwarded in scripts and automation pipelines.
- Tie API authentication to account offboarding When a user or integration is retired, revoke the linked private key, invalidate refresh tokens, and confirm that automated jobs cannot reauthenticate through stale identity material.
Bottom line: Passbolt’s JWT flow shows that API authentication can be passwordless without being governance-free.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
API JWT flows are only as strong as the lifecycle controls around the keys and tokens they depend on. Passbolt’s handshake is cryptographically careful, but the real governance problem sits outside the crypto primitive: who can mint, store, renew, and retire the credentials that make the flow work. The implication is that identity teams must evaluate API authentication as a lifecycle, not a login event.
A question worth separating out:
Q: What should teams do when an integration that uses JWT authentication is retired?
A: They should revoke the linked private key, invalidate any outstanding refresh tokens, and confirm that the integration cannot reauthenticate through cached secrets or stale automation. Retirement is only complete when the identity can no longer renew itself or reach the API through old trust material.
👉 Read our full editorial: Passbolt API JWT flow shows why secrets still need layered identity controls