Notifications
Clear all
Topic starter
08/07/2026 6:52 pm
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.
NHIMG editorial — based on content published by Passbolt: So you want to play with the passbolt API? Let’s talk about JWTs
Questions worth separating out
Q: How should security teams govern API authentication that uses signed challenges and refresh tokens?
A: Treat the flow as machine identity governance, not just authentication plumbing.
Q: Why do refresh tokens create more risk than short-lived access tokens?
A: Refresh tokens extend the life of the identity beyond the original login, so a stolen or mismanaged refresh token can keep reissuing access without redoing the full authentication ceremony.
Q: What do teams get wrong about cryptographic API authentication?
A: They often assume that encryption and signing eliminate governance risk.
Practitioner guidance
- Separate initial authentication from renewal governance Track refresh tokens as distinct entitlements from access tokens, with explicit ownership, review, and revocation steps for each integration.
- Store private keys in controlled secret management paths Keep the user private key out of shared scripts, developer laptops, and ad hoc automation so the signing step remains tied to a governed identity.
- Bind API access to a named machine identity record Document which service, workflow, or operator owns the JWT flow, then review it during joiner-mover-leaver and offboarding processes.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step GPG challenge creation and signing commands for API authentication workflows
- Exact request and response payload examples for the JWT login and refresh flow
- How to retrieve the server public key and user identifier in the Passbolt interface
- A working end-to-end example script for implementing the sequence in code
👉 Read Passbolt's explanation of JWT authentication for API access →
Passbolt API JWT auth: what it means for secrets and IAM teams?
Explore further
08/07/2026 7:13 pm
JWT authentication for APIs is still an identity governance problem, not just an implementation detail. The article shows a machine identity exchanging signed challenges and encrypted responses to obtain bearer tokens, which means the real control point is lifecycle governance around keys and tokens. Once an integration can renew access programmatically, the organisation is governing non-human access, not merely securing a login flow. Practitioners should treat this as machine identity with explicit entitlements, not developer authentication convenience.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection without revocation leaves identity risk intact.
A question worth separating out:
Q: How can organisations tell whether an API login flow is outside its intended boundary?
A: Look for refresh tokens or private keys stored in code, shared automation, personal devices, or undocumented scripts. If the identity can continue operating after the original use case ends, the flow has escaped its intended boundary. Governance should require a named owner, a revocation process, and a periodic review of where the renewal material is used.
👉 Read our full editorial: Passbolt API JWT flow shows why secrets still need layered identity controls
