In a JWT, how does alg HS256 differ from RS256 in who can mint a valid token?
answer
- Count the keys, then count the parties
- Who can also create what they check
- Verification key can be published safely
- Blast radius of one leaked secret
- Trust the configured algorithm, not the header
basics
~20 sHS256 is a shared-secret MAC, so every party that can verify a token can also create one. RS256 is asymmetric: the issuer signs with a private key and verifiers hold only the public key, so verification never confers the ability to issue.
solid answer
~50 s`HS256` is HMAC with SHA-256: one symmetric secret both produces and checks the signature. That means any service configured to verify tokens holds everything needed to mint them, so the trust boundary is only as strong as the least protected copy of that secret. `RS256` is RSASSA-PKCS1-v1_5 with SHA-256: the authorization server signs with a private key it never distributes, and every resource server verifies with the corresponding public key, which is safe to publish — typically through a JWKS. Practically, `HS256` is defensible only when the same component issues and verifies, such as a single application signing its own session token. The moment a second party verifies, asymmetric signing is the correct default, because it makes "can verify" and "can issue" different capabilities. Verifiers must also pin which algorithms they accept rather than trusting the token's header.
code
json · 1 line{"alg":"HS256","typ":"JWT"}go deeper
Recall that HS256 uses one shared secret while RS256 uses a private key to sign and a public key to verify, and that only the public half is safe to distribute.
Explain the consequence rather than the label: with a symmetric algorithm every verifier can forge tokens, so verification and issuance stop being separate capabilities.
Demonstrate the design rule and its operational tail — blast radius, lack of attribution, and rotation as a flag day versus a publish-then-switch procedure.
Own key custody and policy: where the private key lives, which parties may ever hold signing capability, and how the algorithm choice reflects trust boundaries across the organisation.
## What the two identifiers actually name The `alg` header parameter carries an identifier from the JWA registry (RFC 7518). `HS256` means HMAC using SHA-256 — a keyed message authentication code over the signing input, producing a tag that anyone holding the same key can recompute. `RS256` means RSASSA-PKCS1-v1_5 using SHA-256 — a digital signature produced with an RSA private key and checked with the matching public key. The related identifiers follow the same pattern: `HS384`, `HS512`, `RS384`, `RS512`. The distinction that matters for token design is not the underlying mathematics; it is the **key topology**. ## Symmetric: verification implies issuance With `HS256` there is exactly one key. To check a token, a service must possess the same bytes used to create it. So every verifier is, by construction, a potential issuer. The consequences compound: - **Blast radius.** The secret exists in every verifier's configuration, in the deployment system, in CI, in whatever secret store fronts them, and often in a developer's local environment file. Compromise of the weakest of those yields the power to forge tokens for the entire system. - **No attribution.** If a forged token appears, nothing in it identifies which holder of the secret produced it. Neither the issuer nor any verifier can prove which party minted a given token, so there is no non-repudiation. - **Rotation is a flag day.** Changing the secret means every issuer and every verifier must switch, more or less together, unless you build multi-key support with a key identifier — which is the machinery asymmetric setups get for free from a published key set. ## Asymmetric: verification is a strictly weaker capability With `RS256` the authorization server holds the private key — ideally in a KMS or HSM so it is never exported — and publishes the public key. Verifiers need only the public half. Publishing it to the internet is not a compromise; that is what a JWKS endpoint is for. This separates two capabilities that symmetric signing fuses. A resource server can be fully compromised and the attacker still cannot mint tokens, only replay the ones that passed through. Adding a new verifier requires no secret provisioning at all — it fetches the key set. And key rotation becomes a publish-then-switch procedure rather than a synchronised deployment. ## When HS256 is still a reasonable choice The honest answer is: when issuer and verifier are the same trust domain and the same deployment. A monolith that signs its own stateless session cookie and checks it on the next request has one copy of the secret, no distribution problem, and gains nothing from asymmetry. HMAC is also fast and the resulting tokens are shorter than RSA-signed ones. Some internal service-to-service designs use per-pair symmetric keys deliberately. What is not defensible is one shared HMAC secret distributed to many independent verifiers, which is the pattern this question is usually probing for. ## Cost, briefly and honestly HMAC verification is cheap. RSA verification with the common public exponent is also fast — fast enough that it is rarely the bottleneck next to a network round trip — while RSA *signing* is markedly more expensive, which is a load consideration for the token issuer rather than for resource servers. If token size or signing throughput matters, `ES256` is the usual alternative, with far smaller signatures. ## The algorithm the verifier expects, not the one the token claims One rule belongs in every answer here: the header's `alg` is attacker-controlled input. A verifier must decide, from its own configuration, which algorithms and which key it will accept, and reject anything else — for example, configuring "RS256 with the key from this issuer's key set" rather than "whatever the token says". Binding the algorithm to the key type at configuration time is what makes the symmetric-versus-asymmetric decision hold at runtime. ## How to answer crisply Lead with the topology: with HS256, verify and issue are the same capability; with RS256, they are different. Then give the design rule that follows — the number of parties that need to verify decides the algorithm family, and any count above one points to asymmetric.
- Why should a verifier pin the accepted algorithm instead of reading it from the token?The header travels with the token and is fully attacker-controlled until the signature has been checked. A verifier that dispatches on it lets the attacker choose the verification path. The safe configuration states the expected algorithm and key source up front — "RS256 with keys from this issuer's key set" — and rejects anything that does not match.
- Does choosing RS256 over HS256 make a stolen token less dangerous?No. The algorithm governs who can create tokens, not who can use one that already exists. A stolen bearer token is equally usable under either. What asymmetric signing changes is that compromising a verifier no longer yields forging power, which limits how far an intrusion spreads.
- Where should the private signing key live in a production system?Inside a key management service or HSM, so the issuer requests signatures rather than holding exportable key material. That gives you audit records of every signing operation, makes exfiltration far harder than reading a file or an environment variable, and lets rotation happen by creating a new key version rather than redistributing bytes.
saying these in an interview costs you the question
- Shares one HMAC secret with every resource server
- Says HS256 and RS256 differ only in strength
- Believes an HMAC secret is safe to distribute widely
- Lets the token's header choose the verification algorithm
- Thinks RS256 verification requires the private key