JWT signing algorithms and identity trust boundaries in modern apps

At a glance

What this is: This is a deep dive into JWT signing algorithms, showing that HS256 centralises trust in one shared secret while RS256 separates signing authority from verification.

Why it matters: It matters because token signing choices directly shape NHI governance, service-account blast radius, and how safely human, workload, and downstream service identities can be trusted.

👉 Read WorkOS's deep dive on JWT signing algorithms and trust boundaries

Context

JWT signing is not just a cryptography choice. It is an identity governance choice that defines who can mint trusted assertions, who can verify them, and how much damage follows if one service is compromised. In an NHI architecture, that boundary determines whether verification rights also become token-creation rights.

The article compares HS256 and RS256 because the two algorithms create very different operational models. HS256 is simpler inside one trust boundary, but it turns every verifier into a potential signer. RS256 keeps signing authority concentrated and is better suited to multi-service, partner, and federated token flows where identity assurance has to survive compromise in one part of the stack.

Key questions

Q: How should security teams choose between HS256 and RS256 for JWTs?

A: Choose HS256 only when token issuance and verification stay inside one tightly controlled trust boundary. Choose RS256 when multiple services, partners, or environments need to verify tokens without being able to mint them. The deciding factor is not speed. It is whether verification rights should also create forgery rights.

Q: Why do shared JWT secrets increase identity risk in microservices?

A: Shared secrets make every verifier a potential token issuer. If one service is compromised, the attacker can forge valid tokens for the whole estate because the same material is used to sign and verify. That turns a local service compromise into a systemwide identity compromise.

Q: How do you know if JWT verification is configured safely?

A: Safe verification pins the expected algorithm, rejects any header-driven change to that choice, and uses distinct key material for signing and verification where appropriate. If the verifier accepts algorithm selection from the token itself, the control is not safe enough for production identity traffic.

Q: What is the difference between HS256 and RS256 in token governance?

A: HS256 is symmetric, so the same secret both signs and verifies. RS256 is asymmetric, so the private key signs while the public key verifies. In governance terms, RS256 separates minting authority from validation authority, which reduces the blast radius when many systems need to trust the same token.

Technical breakdown

HS256 shared-secret signing and verifier trust

HS256 uses HMAC-SHA256, a symmetric construction in which the same secret key signs and verifies the token. That design is efficient, but it also means every verifier must possess material that can forge a valid JWT. In identity terms, verification authority and minting authority collapse into the same control plane. That is acceptable only when the trust boundary is narrow and tightly governed. Once the same secret spreads across multiple services, compromise of any one verifier can become compromise of the entire token issuer model.

Practical implication: Treat every HS256 verifier as a signing-capable identity and limit the number of systems that ever receive the shared secret.

RS256 public verification and private signing

RS256 uses an asymmetric pair, where the private key signs and the public key verifies. That separation is what makes JWKS-based distribution workable: downstream services can validate tokens without gaining the ability to create them. For identity teams, the value is blast-radius reduction. A compromised verifier can read and accept tokens, but it cannot impersonate the issuer unless the private key itself is exposed. That is why RS256 fits distributed systems, partner integrations, and environments where token validation must cross organisational or service boundaries.

Practical implication: Keep private signing keys isolated and distribute only verification material to systems that need to validate tokens.

JWKS rotation and algorithm-confusion failure mode

RS256 aligns naturally with JWKS because verifiers can fetch the current public key by key ID and continue validating tokens across rotation windows. The risk is not the rotation pattern itself but misconfiguration. Algorithm confusion happens when a verifier trusts the JWT header to choose the algorithm, allowing an attacker to submit a token that changes the verification logic. The core control is algorithm pinning: the verifier must know in advance whether it expects HS256, RS256, or another approved scheme, and it must reject anything else.

Practical implication: Pin the expected algorithm in verification code and rotate keys through a controlled JWKS process rather than header-driven logic.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HS256 creates shared-secret identity sprawl: A symmetric JWT model makes every verifier a potential signer because the same secret is used on both sides of the trust check. That assumption was designed for small, tightly bounded systems. It fails when the token must cross multiple services, because compromise in one verifier becomes token forgery everywhere else. The implication is that trust boundaries, not performance, should decide whether a shared-secret pattern is even acceptable.

RS256 is a blast-radius control, not just an algorithm choice: Asymmetric signing separates minting authority from validation authority, which is the governance property that matters most in distributed identity systems. The public key can spread widely without creating forgery rights, so downstream services do not become de facto token issuers. This is the cleaner fit for NHI governance when multiple workloads, APIs, or partners must trust the same assertions.

Algorithm confusion is a verification-policy failure, not a cryptography failure: The weakness appears when token headers are allowed to steer verification logic. That is a control-plane error because the verifier has abdicated the decision about which signing scheme is acceptable. The named concept here is header-driven verification drift, where runtime policy follows attacker-controlled metadata instead of fixed trust rules. Practitioners should treat that as an identity validation defect, not a library quirk.

Key rotation maturity exposes the real operational difference between HS256 and RS256: HS256 rotation demands simultaneous secret replacement across every service that verifies tokens, which increases coordination risk and extends exposure if one service lags. RS256 rotation can be staged through JWKS, allowing older public keys to remain available only for active tokens. The practitioner takeaway is that lifecycle governance, not pure cryptography, determines the safer default in larger identity estates.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 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.
• For rotation and offboarding depth, see Guide to the Secret Sprawl Challenge for how leaked credentials persist across real environments.

What this signals

Header-driven verification drift: JWT programmes are increasingly exposed to policy mistakes rather than purely cryptographic ones. Once a verifier lets the token choose the algorithm, the identity control plane has already failed, because trust decisions are no longer fixed at design time. Teams should treat verification logic as part of IAM policy, not as a coding detail.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, secret handling is still failing at the point where identity material is created and copied, not just where it is stored. That matters for JWT signing keys because token trust depends on the same lifecycle discipline as any other secret.

The next governance step is to align JWT signing with broader NHI lifecycle controls, including rotation, storage, and revocation. When a token key leaks, the difference between a short-lived incident and a durable compromise is whether the organisation can remove trust before the compromised credential remains valid in production.

For practitioners

• Pin the JWT algorithm in verification code Configure every verifier to accept only the expected signing algorithm and reject any token that attempts to change that choice through the header.
• Reduce shared-secret distribution points Use HS256 only where signing and verification stay inside one tightly controlled trust boundary, and avoid giving the secret to services that do not need to mint tokens.
• Publish public keys through JWKS For distributed or partner-facing token flows, keep the private key isolated and expose only the public verification key through a JWKS endpoint.
• Review key rotation as a lifecycle control Test whether your rotation process can replace a compromised secret or private key without breaking active services, and document the rollback path before a rotation event occurs.

Key takeaways

• HS256 concentrates signing and verification into one shared secret, so a single verifier compromise can become a systemwide token-forgery event.
• RS256 separates minting from validation, which is the governance property that makes multi-service and partner token flows safer to operate.
• Safe JWT governance depends on algorithm pinning, isolated signing keys, and lifecycle-controlled rotation, not on cryptography alone.

Key terms

• Symmetric JWT Signing: A JWT signing model where the same secret key creates and verifies the token signature. This is simple and efficient, but it also means any system that can verify tokens can potentially mint them if the secret is exposed. In distributed estates, that creates a wide trust surface.
• Asymmetric JWT Signing: A JWT signing model where a private key signs tokens and a public key verifies them. This separates minting authority from validation authority, which is the main governance advantage in multi-service or partner-facing architectures. It reduces the chance that a verifier compromise becomes a forgery capability.
• JWKS: A JSON Web Key Set is a published collection of public keys used to verify JWT signatures, usually paired with key IDs in the token header. It lets verifiers fetch current keys dynamically and supports cleaner rotation, provided the verification policy does not trust attacker-controlled algorithm hints.
• Algorithm Confusion: A JWT failure mode where verification code accepts the algorithm declared by the token instead of enforcing a server-side expectation. That opens the door to attackers switching verification logic, such as treating a public RSA key as an HMAC secret. It is a policy failure at the identity boundary.

Deepen your knowledge

JWT signing algorithms and token trust boundaries are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are deciding how to govern service-to-service identity in a distributed environment, it is a strong fit.

This post draws on content published by WorkOS: RS256 vs HS256: A deep dive into JWT signing algorithms. Read the original.