Notifications
Clear all
Topic starter
06/06/2026 11:07 am
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.
NHIMG editorial — based on content published by WorkOS: RS256 vs HS256: A deep dive into JWT signing algorithms
Questions worth separating out
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.
Q: Why do shared JWT secrets increase identity risk in microservices?
A: Shared secrets make every verifier a potential token issuer.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step HMAC and RSA signing mechanics for teams that need to understand the math behind token verification.
- Concrete JWKS rotation flow and key ID handling for services that must validate tokens during a transition period.
- Performance comparison detail for high-throughput systems deciding whether RS256 overhead is operationally acceptable.
- The algorithm-confusion attack pattern shown in code form, useful for developers reviewing existing JWT libraries.
👉 Read WorkOS's deep dive on JWT signing algorithms and trust boundaries →
RS256 vs HS256: what it means for IAM and token trust?
Explore further
06/06/2026 11:43 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: JWT signing algorithms and identity trust boundaries in modern apps
