Bei HS256 vs RS256 frage ich nicht zuerst, welcher Algorithmus abstrakt „stärker“ ist. Ich frage: Wer darf Tokens signieren, wer soll nur verifizieren und wie viele Systeme müssen sensibles Key Material erhalten?
Mein Modell für HS256
HS256 ist HMAC mit SHA-256. Dasselbe Shared Secret signiert und verifiziert.
shared secret
├── sign
└── verify
Gebe ich einem Service das Secret zum Verifizieren, besitzt er technisch auch Signing Material.
In einer kleinen, bewusst gemeinsamen Trust Boundary kann das passen. Mit vielen Verifiern wird die Verteilung kritischer.
Mein Modell für RS256 und RSA
private key -> sign
public key -> verify
Verifier erhalten Public Keys, ohne Signing Authority zu bekommen. Deshalb passt RS256 oft besser zu einem zentralen IdP mit vielen Resource Servern.
Meine Kernfrage: Wer darf vertrauenswürdige Tokens erzeugen?
Ein einzelner Service, der selbst signiert und verifiziert, kann mit HS256 sehr gut arbeiten.
Bei einem zentralen Authorization Server und vielen APIs möchte ich häufig, dass APIs nur verify können. Das spricht für ein asymmetric model.
Ich sehe die Wahl daher als Verteilung von Autorität.
Wann HS256 für mich passt
- enge gemeinsame Trust Boundary;
- wenige Secret-Halter;
- kein Bedarf an Public-Key-Publishing;
- bewusst akzeptierte Signing-Fähigkeit jedes Secret-Halters;
- einfache Operations.
Das Secret muss stark und zufällig sein. RFC 8725 warnt vor schwachen, menschlich merkbaren HMAC Secrets und Offline Guessing.
Wann RS256 besser passt
- zentraler IdP signiert;
- viele APIs verifizieren;
- Verifier sollen nicht signieren können;
- Public Keys sollen breit verteilt werden;
- Rotation über JWK/JWKS.
Ein Public Key ist für Verification gedacht; die kritische Signing Credential bleibt der Private Key.
RS256 ist nicht automatisch immer sicherer
HS256 kann durch schwache Secrets, breite Secret-Verteilung oder Algorithm Confusion schlecht betrieben werden.
RS256 kann durch schlecht geschützte Private Keys, beliebig vertraute Public Keys, stale JWKS oder fehlende Issuer/Audience-Prüfung unsicher werden.
Algorithm Policy wird gepinnt
Wenn meine App RS256 erwartet:
allowed algorithms = [RS256]
Dann wechsle ich nicht auf HS256, nur weil der Token Header es behauptet. RFC 8725 empfiehlt eine explizite Algorithmusmenge.
HS256-Key-Verteilung
auth server -- secret --> API A
-- secret --> API B
-- secret --> API C
Alle Secret-Halter haben potenziell Signing Capability. Das ist kein HMAC-Fehler, sondern das Trust Model.
RS256-Key-Verteilung
auth server keeps private key
|
+--> API A public key
+--> API B public key
+--> API C public key
Das trennt Signer und Verifier sauber und passt zu JWKS-Rotation.
kid bei rotierenden Keys
{
"alg": "RS256",
"kid": "2026-key-03"
}
kid hilft mir, eine Candidate JWK aus einem trusted JWKS auszuwählen. Es beweist selbst kein Vertrauen. Dafür nutze ich die JWT-kid-Anleitung und JWKS Validator.
Beide lassen sich ohne Key dekodieren
HS256 und RS256 verschlüsseln den normalen Header/Payload nicht. Mit JWT Decoder kann ich beide lesen; Key Material brauche ich erst für Verification.
Meine HS256-Checkliste
- starkes, zufälliges Secret;
- wenige Empfänger;
- bewusst akzeptierte Signing Capability;
- identische Secret-Byte-Interpretation;
- Algorithm Allowlist;
- saubere Rotation.
Meine RS256-Checkliste
- Private Key geschützt;
- vertrauenswürdige Public-Key-Distribution;
kid-Auswahl bei Rotation;- Key Source an Issuer gebunden;
- unerwartete Algorithms abgelehnt;
- Issuer/Audience/Zeit nach Signature geprüft.
Bei Signature Failure folge ich der Invalid-Signature-Anleitung, statt Algorithms durchzuprobieren.
Meine Kurzregel: HS256 vs RS256 ist vor allem eine Frage von Key Ownership und Trust Distribution.
