Symmetric vs Asymmetric Signing
HS256 shares one secret for signing and verification. RS256 uses two keys. The choice depends on one question: can the verifier be trusted with signing power?
Signing proves who created the token. It does not hide the token. Two signing families exist, each with a different trust model.
Symmetric (HS256): HMAC + SHA-256. One key. The signer and the verifier share it. If the key leaks, anyone can forge tokens.
Asymmetric (RS256): RSA + SHA-256. Two keys. The private key signs. The public key verifies. The public key is safe to share because it cannot sign.
| HS256 (symmetric) | RS256 (asymmetric) | |
|---|---|---|
| Keys | 1 shared secret | 2 (private + public) |
| Who can sign | Anyone with the secret | Only the private key holder |
| Who can verify | Anyone with the secret | Anyone with the public key |
| Use when | All services trust each other | Verifiers must not have signing power |
From the audit: The side project uses HS256. auth-service, lobby-service, and game-server share one
JWT_SECRET. This works. Lobby and game-server only verify, never sign. But if an external service ever needs to verify tokens, the project must switch to RS256.
“Symmetric or asymmetric? Answer one question: can the verifier be trusted with signing power?”
References:
Related: back to the Seven Blind Spots Behind a JWT Audit overview · What Is a JWT · Algorithm Confusion and the none Attack