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.
At a glance
What this is: PassBolt describes a JWT-based API login flow that uses an encrypted challenge, signed request, and token refresh path to authenticate integrations without passwords.
Why it matters: It matters because IAM and NHI teams still have to govern private keys, access tokens, refresh tokens, and API authentication assumptions even when the login path is cryptographically strong.
Context
JWT authentication in this context is not a simple password exchange. For Passbolt API access, the client first builds a challenge, then encrypts and signs it so the server can verify both confidentiality and authenticity before issuing tokens.
That means the governing problem is not whether the login flow uses strong cryptography, but how the surrounding identity lifecycle is controlled. The API path still depends on private keys, token handling, expiry, and refresh logic, which are all part of NHI governance.
For teams automating onboarding, secrets sync, or other integrations, this is a familiar pattern: the authentication ceremony is secure only if the credential lifecycle behind it stays disciplined. The subject is therefore API identity control, not just transport security.
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. If private keys, access tokens, and refresh tokens are not managed separately, the authenticated path can outlive the intended session, survive account changes, and become difficult to revoke cleanly when an integration is retired or compromised.
Q: Why are refresh tokens riskier than access tokens after compromise?
A: Access tokens are usually short-lived, so their damage window is limited. Refresh tokens can mint new access tokens repeatedly, which means possession can preserve access for months or longer. That makes the refresh token the persistence mechanism and the access token only the temporary execution credential.
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. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.
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.
Technical breakdown
How the Passbolt JWT handshake works
The flow starts with a challenge payload that includes an API version, the instance domain, a random verification token, and an expiry timestamp. The client encrypts that payload with the server’s public key and signs it with the user’s private GPG key. The server then decrypts the message, verifies the signature, and returns an encrypted response containing access and refresh tokens. This is closer to mutual proof than simple bearer-token issuance, because both sides must demonstrate possession of the correct keys before any API session begins.
Practical implication: Treat the challenge exchange as an identity boundary and protect the private key used to sign it.
Why access tokens and refresh tokens create separate control points
A JWT access token authorises API calls for a limited period, while a refresh token extends the session when the access token expires. That split reduces password exposure, but it also creates two distinct assets with different blast radii. If the access token leaks, the immediate window is bounded; if the refresh token leaks, an attacker may regain access repeatedly until revocation or expiry policy intervenes. In practice, token renewal logic becomes part of access governance, not just application plumbing.
Practical implication: Manage access tokens and refresh tokens as separate secrets with separate storage, rotation, and revocation expectations.
Why API authentication still depends on key and secret lifecycle governance
Cryptographic authentication does not eliminate identity risk. The flow relies on a private key linked to the user account, a server public key, and token material that must stay valid only for the intended session. If the private key is exposed, reused improperly, or not retired when the account lifecycle changes, the security model breaks at the identity layer even if the cryptography remains sound. The underlying control issue is lifecycle governance for non-human credentials, not weakness in the algorithm.
Practical implication: Align key custody, token revocation, and account offboarding so the authentication chain cannot outlive the identity behind it.
Threat narrative
Attacker objective: The attacker wants durable authenticated API access that can be renewed without redoing the original key exchange.
- Entry occurs when a script, integration, or automation component obtains the materials needed to start the JWT challenge flow, including the private key or token-handling context.
- Credential access occurs when the access token or refresh token is issued and becomes the active authorisation artifact for API calls.
- Escalation occurs if the refresh token or signing key is reused outside the intended lifecycle, allowing repeated authentication beyond the original session boundary.
- Impact is unauthorised API access to resources, secrets workflows, or management actions that were meant to be reachable only by the legitimate integration.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
Long-lived refresh logic creates a durable identity bridge that attackers will target. An access token may be short-lived, but the refresh token extends the trust relationship and therefore extends the attack window if it is exposed. That makes refresh-token governance a first-class control plane for NHI security, not an implementation detail.
Layered identity controls remain necessary because strong authentication does not remove privilege design. Even when the server verifies possession of the correct private key, the question becomes what that authenticated subject can do, for how long, and under what offboarding conditions. The practitioner takeaway is that authentication strength and authorisation scope are separate governance problems.
Key custody is the hidden dependency in supposedly passwordless API access. The article shows that OpenPGP signing shifts trust away from passwords and into the operational discipline of private-key custody, token storage, and revocation. Teams that treat that as a developer convenience instead of an identity-control boundary will underestimate the blast radius.
Passbolt’s model is a useful reminder that cryptographic elegance does not replace identity architecture. The flow improves assurance, but it still requires explicit ownership, renewal policy, and revocation handling for the non-human identity using it. Practitioners should read the design as evidence that secure automation still needs governed credentials.
What this signals
Layered API identity control is the real lesson here: cryptographic authentication reduces password dependence, but it does not eliminate the need to govern key custody, token renewal, and offboarding. For IAM teams, the control objective shifts from proving that a login succeeded to proving that the identity cannot persist beyond its intended lifecycle.
Refresh-token governance is where many API programmes quietly accumulate risk: renewal credentials often outlive the session they were meant to extend. When that happens, the programme no longer controls authentication state at issuance time; it is relying on later cleanup to contain access that should never have remained valid.
For practitioners
- 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. Do not let application teams manage them through a single generic secret policy.
- Review refresh-token exposure paths Map where refresh tokens are stored, logged, cached, or forwarded in scripts and automation pipelines. The goal is to identify where a long-lived renewal credential could survive beyond the intended session boundary.
- 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.
- Separate authorisation scope from authentication method Treat successful JWT login as only the start of the control question. Limit which resources the authenticated integration can reach and review those permissions independently of how the token was obtained.
Key takeaways
- Passbolt’s JWT flow shows that API authentication can be passwordless without being governance-free.
- The security boundary moves to private-key custody, token renewal, and revocation discipline.
- Teams that do not separate access-token and refresh-token controls will struggle to contain reuse and offboarding risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on API authentication using signed challenges and token issuance for a non-human integration. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and private keys become durable credentials if lifecycle controls are weak. | |
| Recommendation — Review whether JWT login paths rely on strong identity proof and not just token possession. Limit secret lifetime and revoke renewal credentials when the integration or user lifecycle changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The flow depends on managing authenticators, keys, and token material across issuance and retirement. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and retire API credentials on schedule. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about how a workload identity proves itself and gets authorised in cloud-adjacent access. |
| Recommendation — Govern API identities as managed entities with defined ownership, lifecycle, and revocation. | ||
| MITRE ATT&CK | TA0006 — Credential Access | If the signing key or refresh token is exposed, the attacker gains reusable credential material. |
| Recommendation — Map token theft scenarios to credential-access detection and prioritise renewal-token abuse. | ||
Key terms
- JWT Authentication: JWT authentication uses a signed token to represent identity and claims on each request. The server validates the token without storing session state, which simplifies scaling but makes expiry, refresh, and revocation design decisions part of the security model.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Private Signing Key: A private signing key is the secret material that creates a trusted software signature. If it is exposed or copied, an attacker can sign malicious code as if it were legitimate, which is why key storage, access control, and hardware-backed protection are central governance requirements.
- Token Lifecycle: Token lifecycle is the full sequence of issuing, refreshing, expiring, revoking, and reauthorizing a credential. For delegated access, lifecycle state is the real indicator of whether a connection is still legitimate, because a valid-looking token can still be stale, disconnected, or out of scope.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org