.NETFoundations 29 / 37Reported by candidates

Signing keys: HMAC vs RSA

“How is a JWT signed, and what is the difference between HS256 and RS256?”

Why nobody can change a token without the API noticing, and who holds which key.

See it

Issuersigns tokens

JWTheader . claims . signature

1/7The issuer signs the header and claims with a key. The signature goes on the end of the token.

In plain words

A JWT (JSON Web Token), the token our APIs accept, is three parts joined by dots: a header, the claims, and a signature. The header and claims are only encoded: rewritten as text that anyone can turn back, no key needed. They are not encrypted, which would lock them with a key. So anyone who holds the token can read them. The signature stops changes, not reading. The issuer, the sign-in service that creates the token, computes the signature from the header and claims using a secret key. If one letter of the claims changed, say CreditOfficer became Admin, the signature no longer fits and the API rejects the token. There are two kinds of keys. HMAC (HS256) uses one shared secret: the same secret signs, and the API recomputes the signature and compares. So every service that can check a token could also make one. RSA (RS256) uses a key pair: a private key that only the issuer keeps, to sign, and a public key that anyone may have. The API can't recompute anything with a public key. Instead the public key works like a test the signature passes or fails: it verifies a signature but can't make a valid one. That is why uses RS256 and publishes its public keys for every API to download.

Say it in the interview

A JWT is signed, not encrypted: header and payload are Base64URL-encoded (letters and digits only, safe in a web address) JSON text that anyone can read, and the signature proves they weren't changed and who issued them.
HS256 is HMAC with SHA-256, where SHA-256 is the fingerprint function. It is symmetric, which means one secret both signs and verifies, so every verifier could also issue tokens. It fits when one service issues and checks its own tokens, and the secret must be at least 256 bits and live in Azure , where Azure keeps secrets.
RS256 is RSA with SHA-256: the issuer signs with its private key and APIs verify with the public key, so verifiers can't mint tokens. Identity providers like publish their public keys in a JWKS document, a JSON list of public keys; the kid header says which key signed the token.
In .NET I set , the address of the issuer, and the JWT handler downloads and refreshes the issuer's public keys itself, which also makes key rotation painless.

What they ask next

Interviewers check that you can explain every line. Tap a question to open it.

How does the API get 's public keys?
Set options.Authority to the tenant's address (tenantId is the company's Entra tenant id, read from configuration). The JWT handler reads the issuer's metadata, downloads the public keys (a JWKS document) and refreshes them now and then, so a key change on Entra's side needs no deploy. options.Audience says who the token must be meant for: this API. A token issued for another API is refused. In the code, turns on sign-in checking and options => is a short inline function that receives the settings.
```
builder.Services
  .AddAuthentication()
  .AddJwtBearer(options =>
  {
  // the tenant's sign-in address
  options.Authority =
    "https://login.microsoftonline.com/"
    + tenantId + "/v2.0";
  options.Audience = "api://loans";
  });
```
We issue our own tokens with HS256. What do we watch?
A long random secret (the .NET library refuses an HS256 key shorter than 256 bits), kept in , never in appsettings or git. Only the service that issues the tokens and the ones that check them get it. If it leaks, anyone can mint any token, so rotating it must be a practised step.
Is a signed token encrypted?
No. Paste one into a decoder and you read every claim. If claims must be hidden, encrypt the token (JWE, the encrypted form of a token) or keep the data on the server. Most APIs just keep the claims non-secret.

Traps

Don't say~~The token is safe to carry personal data because it's signed.~~SaySigned means tamper-proof, not secret. Anyone with the token reads its claims.
Don't say~~HS256 and RS256 are equally safe, it's just speed.~~SayWith HS256 every checker can also sign. RS256 keeps signing with the issuer alone.