TL;DR: JWT signing choices shape trust boundaries, key exposure, and token-forgery risk: HS256 uses one shared secret for signing and verification, while RS256 separates private signing from public verification and supports cleaner rotation via JWKS, according to WorkOS. The practical question is not speed but how many services should ever hold material that can mint valid identity assertions.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: JWT signing algorithms create different trust boundaries, key exposure patterns, and token-forgery risks through HS256 and RS256.
Why it matters: IAM teams and platform architects need to understand that the signing model determines who can mint trusted tokens, how rotation works, and how far compromise can spread across services.
Context
JWT signing is not just a cryptography choice, it is a trust-boundary choice. In identity systems, the signing model determines which services can verify tokens and which services can also mint them, so the wrong algorithm can quietly turn many verifiers into potential issuers.
HS256 and RS256 solve the same integrity problem with different trust assumptions. HS256 keeps signing and verification inside one shared secret, while RS256 splits those duties across a private key and a public key, which matters most once tokens cross service, partner, or trust-domain boundaries.
Key questions
Q: How do you choose between HS256 and RS256 for JWTs?
A: Use HS256 only when signing and verification stay inside one tight trust boundary with a shared secret you can protect well. Use RS256 when tokens cross trust boundaries, multiple services verify them, or you need public-key distribution and JWKS-based rotation.
Q: Why does a shared JWT secret increase blast radius across services?
A: A shared secret gives every verifier the power to mint valid tokens, so compromise of any one verifier can become compromise of the whole token ecosystem. That is why HS256 is risky in distributed architectures: the service that only needed to validate identity assertions can also impersonate any subject that the token format allows.
Q: How should security teams prevent JWT algorithm confusion in verification code?
A: Security teams should hardcode the accepted algorithm in the verifier, reject any token that claims a different one, and ensure the key type matches the algorithm family. The safest pattern is simple: the application chooses RS256, ES256, or HS256 up front, and the token cannot override that policy at runtime.
Q: What is the difference between JWKS-based rotation and shared-secret rotation?
A: JWKS-based rotation lets RS256 verifiers fetch new public keys without ever handling signing material, so rotation can happen with overlap and minimal distribution risk. Shared-secret rotation requires every verifier to receive the new secret at nearly the same time, which makes operational mistakes more likely and extends the window of exposure.
Technical breakdown
How HS256 collapses signer and verifier trust
HS256 uses HMAC-SHA256, a symmetric construction where the same secret key signs and verifies the token. That means every verifier must also hold minting power, because possession of the secret is enough to create a valid JWT. In a single application that may be acceptable, but in distributed systems it turns broad verification access into broad issuance authority. The cryptographic property is sound, but the governance model is fragile when many services share the same secret.
Practical implication: treat any HS256 verifier as a token-issuing trust point and limit secret distribution accordingly.
Why RS256 separates identity issuance from verification
RS256 uses an asymmetric key pair, where the private key signs and the public key verifies. That separation changes the security model materially: downstream services can validate assertions without gaining the ability to mint them. Public keys can be distributed broadly, often through JWKS, without exposing signing authority. This is why RS256 fits microservices, partner integrations, and any architecture where independent systems must trust the token but should not inherit the power to create it.
Practical implication: use asymmetric signing when token verification must extend beyond the issuer’s own trust boundary.
Why algorithm pinning matters as much as key choice
JWT libraries can be vulnerable if they trust the algorithm declared in the token header instead of enforcing the expected algorithm at verification time. That creates algorithm confusion risk, where a system may accept a forged token because it treats the wrong key type as valid for the chosen algorithm. The danger is not theoretical: the boundary failure occurs when verification logic becomes attacker-influenced. Strong cryptography does not compensate for loose verification rules.
Practical implication: explicitly pin the expected algorithm in verification code and never let the token header choose it.
Threat narrative
Attacker objective: Forge valid identity tokens and use them to impersonate trusted users or services across the affected trust domain.
- Entry occurs when an application or gateway accepts a JWT without strictly binding verification to a known algorithm and trust boundary.
- Credential access happens when a shared HS256 secret, or an RS256 private key, is exposed in one service that should not have signing authority.
- Escalation follows when the compromised material is reused to mint new tokens that other services trust as authentic identity assertions.
- Impact is token forgery across the environment, which can expand a single key leak into broad unauthorized access.
Breaches seen in the wild
- Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shared-signature JWTs create identity minting sprawl: HS256 turns every verifier into a potential issuer because the same secret is required to verify and create tokens. That is an NHI governance problem as much as a cryptographic one, because the control plane now depends on secret distribution discipline across services. The practitioner conclusion is that shared verification authority must be treated as shared issuance authority.
Token trust boundaries should align with issuance authority: RS256 is not simply a stronger algorithm, it is a governance boundary that keeps validation broad while constraining token creation. This matters in microservice and partner ecosystems, where the ability to trust a token should not imply the ability to mint one. Practitioners should design issuance so that minting power is isolated from downstream validation.
Algorithm confusion is a verification governance failure: The trust assumption that a token header can tell the verifier how to validate it is structurally unsafe. That assumption was designed for cooperative parsing, not adversarial inputs. The implication is that verification policy must be external to the token itself, with algorithm choice pinned by the application.
JWKS enables asymmetric rotation but not careless revocation: RS256 and JWKS improve operational flexibility because public keys can be published and rotated without sharing secrets. That does not remove the need to track which keys are active, which tokens remain valid, and which services cache stale keys. Practitioners should treat key rotation as a governed lifecycle, not just a publishing exercise.
Signing algorithm choice is a trust architecture decision, not a performance question: The article correctly frames throughput as secondary to exposure radius and delegation model. In most enterprise systems, the real issue is how many components are allowed to hold material that can mint identity assertions. The practitioner conclusion is to choose the algorithm that matches the trust boundary, then enforce it consistently.
What this signals
Trust boundaries should drive token design: Once a JWT is expected to cross service or partner boundaries, the signing algorithm becomes a governance decision about who may mint identity assertions. HS256 is acceptable only where verifier and signer are the same trust domain.
Algorithm pinning is the real control: The most dangerous JWT failures are not cryptographic weakness but verification logic that trusts the token header to select the algorithm. Enforcing the expected algorithm outside the token restores the boundary the token itself cannot define.
For practitioners
- Pin the expected JWT algorithm Configure verification libraries to accept only the intended algorithm, such as RS256, and reject any token that proposes a different signing mode.
- Restrict shared-secret distribution If HS256 is unavoidable, keep the secret inside the smallest possible trust boundary and avoid giving it to services that only need to verify tokens.
- Use JWKS for asymmetric verification Publish public keys through JWKS so downstream services can verify tokens without ever receiving signing material.
- Rotate signing keys as a lifecycle process Track key creation, rollout, overlap, and retirement so old signing material is removed only after outstanding tokens expire.
Key takeaways
- HS256 and RS256 create different trust models, not just different performance profiles.
- Shared secrets expand compromise impact because every verifier can also become a signer.
- Explicit algorithm pinning and asymmetric key separation are the controls that keep JWT verification trustworthy.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | JWT algorithm choice directly affects whether token verification can be trusted. |
| NHI-07 — Long-Lived Secrets | HS256 depends on a shared secret whose exposure or overuse expands token-forgery risk. | |
| Recommendation — Enforce a fixed signing algorithm and reject tokens whose header tries to alter verification policy. Reduce reliance on shared JWT secrets and shorten their usable lifetime wherever HS256 remains in use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWT signing keys and shared secrets require lifecycle management, rotation, and revocation discipline. |
| Recommendation — Manage JWT signing material as authenticators with controlled rotation, storage, and retirement. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Leaked signing secrets or private keys enable token forgery after credential exposure. |
| Recommendation — Hunt for exposed JWT signing material and treat any leak as a credential-access incident. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Token trust determines which services can present valid identity assertions to other systems. |
| Recommendation — Limit which services can verify or issue tokens so token authority matches the intended trust boundary. | ||
Key terms
- JWT Signing Algorithm: The cryptographic method used to create and verify the signature on a JSON Web Token. In identity systems, the algorithm choice determines whether verification stays separate from issuance or collapses both into the same trust boundary.
- Shared Secret: Any credential or factor that can be known by more than one party and copied or reused, such as a password, OTP, or recovery code. Shared secrets are fragile because once exposed, they can often be replayed to bypass identity controls.
- JWKS: A JWKS, or JSON Web Key Set, is a machine-readable publishing format for public keys used by clients to verify signatures or encrypt tokens. It lets consumers fetch current key material automatically instead of relying on manual distribution, which is critical when keys rotate on a schedule.
- Algorithm Confusion: Algorithm confusion is a verification failure where a service accepts a token under the wrong signing algorithm or uses token-supplied metadata to decide how to verify it. The result is forgery or unauthorised acceptance. It is a classic example of trusting attacker-controlled header data in an identity flow.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org