Comment je choisis entre HS256 et RS256 pour signer des JWT

Quand je compare HS256 et RS256, je ne commence pas par demander lequel est « plus fort ». Je demande : qui doit pouvoir signer, qui doit uniquement vérifier et combien de systèmes doivent recevoir du matériel sensible ?

Cette question de trust boundary est généralement plus utile que le nom de l'algorithme.

Mon modèle mental pour HS256

HS256 est un HMAC avec SHA-256. Le même shared secret sert à signer et vérifier.

shared secret
   ├── signe JWT
   └── vérifie JWT

Si je donne le secret à une API pour vérifier, je lui donne aussi techniquement la capacité de produire des signatures que d'autres holders de ce secret pourraient accepter.

Dans une petite frontière de confiance contrôlée, cela peut être parfaitement adapté.

Mon modèle mental pour RS256 et RSA

private key  -> signe
public key   -> vérifie

Je peux distribuer la public key aux APIs sans distribuer la signing authority. C'est pourquoi RS256 convient souvent mieux à un IdP central avec de nombreux resource servers indépendants.

Ma première question : qui peut mint des tokens de confiance ?

Si un service signe et vérifie lui-même dans une frontière étroite, HS256 peut être simple.

Si un authorization server central signe pour de nombreuses APIs, je veux souvent que celles-ci vérifient sans pouvoir signer. Cela pousse vers un modèle asymmetric comme RS256.

Je vois donc ce choix comme une décision de distribution d'autorité.

Quand HS256 me paraît adapté

• signer et verifier dans le même trust boundary ;
• peu de systèmes reçoivent le secret ;
• pas besoin de publier une public key ;
• simplicité opérationnelle importante ;
• chaque holder du secret est consciemment autorisé à signer.

Le secret doit être fort et aléatoire. RFC 8725 avertit contre les secrets HMAC faibles et mémorisables, qui peuvent permettre du guessing offline.

Quand RS256 est plus naturel

• IdP central ;
• nombreux verifiers ;
• verifiers sans signing capability ;
• distribution large de public keys ;
• rotation via JWK/JWKS.

La public key n'est pas censée permettre de créer une signature RS256 valide. La credential critique reste la private key.

RS256 n'est pas « toujours plus sûr »

HS256 devient risqué avec secret faible, trop largement distribué ou algorithm policy permissive.

RS256 devient risqué avec private key mal protégée, public keys arbitraires, cache JWKS obsolète, issuer/audience ignorés ou algorithm choisi par le token.

Je choisis d'abord le modèle de clé adapté, puis je le sécurise correctement.

Je fixe l'algorithm depuis une configuration fiable

Si l'application attend RS256 :

allowed algorithms = [RS256]

Je ne passe pas dynamiquement à HS256 parce que le header le demande. RFC 8725 recommande une liste explicite.

Distribution HS256

auth server -- secret --> API A
            -- secret --> API B
            -- secret --> API C

Tous les holders peuvent potentiellement signer. Ce n'est pas un défaut du HMAC ; c'est la relation de confiance choisie.

Distribution RS256

auth server garde private key
         |
         +--> API A public key
         +--> API B public key
         +--> API C public key

Cela sépare mieux signer et verifier et s'intègre naturellement à JWKS.

Rôle de kid

{
  "alg": "RS256",
  "kid": "2026-key-03"
}

J'utilise kid comme indice pour sélectionner une candidate JWK dans un JWKS déjà fiable. kid ne prouve pas la confiance. La guide JWT kid et JWKS Validator couvrent ce flux.

Les deux peuvent être décodés sans clé

HS256 et RS256 ne chiffrent pas le header/payload normal. Je peux lire les deux avec JWT Decoder. La clé devient nécessaire pour passer de « que dit le token ? » à « qui l'a signé ? ».

Ma checklist HS256

• secret fort et aléatoire ;
• nombre de systèmes qui le reçoivent ;
• signing capability de chaque verifier ;
• encodage exact des bytes du secret ;
• algorithm allowlist ;
• rotation contrôlée.

Ma checklist RS256

• private key protégée ;
• public keys obtenues via un trust path ;
• sélection kid pendant rotation ;
• key source liée à l'issuer ;
• algorithms inattendus rejetés ;
• issuer/audience/temps validés après signature.

Si une signature échoue, je suis la guide invalid signature plutôt que d'essayer des algorithmes au hasard.

Ma règle finale : HS256 vs RS256 est surtout une question de key ownership et de distribution de confiance.