HS256 vs. RS256: symmetrische und asymmetrische JWTs

Bei der JWT-Signierung werden entweder symmetrische (HMAC) oder asymmetrische (RSA, ECDSA) Algorithmen verwendet. HS256 = HMAC-SHA256. RS256 = RSA-PKCS1v1.5-SHA256. ES256 = ECDSA-P256-SHA256. Die Wahl wirkt sich auf die Schlüsselverteilung und das Vertrauensmodell aus.

HS256 verwendet einen einzigen gemeinsam genutzten geheimen Schlüssel zum Signieren und Verifizieren. Sowohl der Aussteller als auch jeder Verifizierer müssen denselben geheimen Schlüssel besitzen. Die Implementierung ist einfach, erfordert aber eine sichere Schlüsselverteilung an alle Verifizierer.

HS256 eignet sich, wenn Aussteller und Verifizierer derselbe Dienst sind, zum Beispiel eine monolithische API, die ihre eigenen Tokens signiert und verifiziert. Verwenden Sie HS256 niemals, wenn mehrere unabhängige Dienste Tokens verifizieren müssen – sie alle benötigen dann das Geheimnis.

RS256 verwendet einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zum Verifizieren. Nur der Authentifizierungsserver besitzt den privaten Schlüssel. Alle Ressourcenserver rufen den öffentlichen Schlüssel über den JWKS-Endpunkt ab und verifizieren lokal – eine gemeinsame Nutzung von Geheimnissen ist nicht erforderlich.

RS256 eignet sich ideal für Microservice-Architekturen: Der Identity Provider signiert Tokens, und jeder nachgelagerte Dienst verifiziert sie mit dem öffentlichen Schlüssel, ohne den IDP für jede Anfrage zu kontaktieren. Die Architektur lässt sich horizontal skalieren, ohne dass ein Risiko durch Schlüsselverteilung entsteht.

ES256 verwendet ECDSA über P-256. Die Signaturgröße beträgt 64 Bytes gegenüber 256 Bytes bei RS256 mit einem 2048-Bit-Schlüssel. Die Verifizierung ist etwa zehnmal schneller als bei RS256. ES256 wird bevorzugt, wenn Bandbreite oder Verifizierungsgeschwindigkeit entscheidend sind, etwa bei mobilen APIs oder IoT.

Für RS256/ES256: Rotieren Sie die Schlüssel, indem Sie einen neuen Schlüssel (neue kid) in JWKS veröffentlichen, neue Token mit dem neuen Schlüssel signieren, eine Übergangsfrist abwarten, in der alte Token ablaufen können, und anschließend den alten Schlüssel entfernen. Bei der HMAC-Rotation muss das neue Geheimnis erneut verteilt werden.

HS256-Verifizierung: ca. 1 µs. RS256-Verifizierung: ca. 100 µs (2048 Bit). ES256-Verifizierung: ca. 50 µs (P-256). HS256 ist am schnellsten, erfordert aber die gemeinsame Nutzung eines Geheimnisses. ES256 bietet für verteilte Systeme das beste Gleichgewicht zwischen Sicherheit und Leistung.

Eine kritische Schwachstelle: Wenn der Verifizierer dem alg-Header blind vertraut, kann ein Angreifer alg von RS256 in HS256 ändern und das Token mit dem öffentlichen Schlüssel des Servers signieren, der öffentlich ist, und ihn als HMAC-Geheimnis verwenden. Lösung: Vertrauen Sie niemals dem alg-Header.

Entscheidung: einzelner Dienst → HS256. Mehrere Dienste/Microservices → RS256 oder ES256. Mobile Anwendungen mit hohem Durchsatz → ES256. Im Zweifel verwenden Sie ES256 (P-256) oder RS256 mit Schlüsseln von mindestens 2048 Bit. Verwenden Sie RS512 niemals in leistungskritischen Pfaden.

Verwenden Sie PyJWT (Python), jose (Node.js) oder auth0/java-jwt. Legen Sie den erwarteten Algorithmus im Verifizierungsaufruf immer fest: jwt.decode(token, secret, algorithms=["HS256"]). Übergeben Sie niemals algorithms=None und lassen Sie den Parameter niemals weg.

Warum wird RS256 in Microservices-Architekturen gegenüber HS256 bevorzugt?

HS256 ist symmetrisch (gemeinsames Geheimnis); RS256/ES256 sind asymmetrisch (privater Schlüssel zum Signieren, öffentlicher Schlüssel zum Verifizieren). Verwenden Sie asymmetrische Algorithmen für Systeme mit mehreren Parteien. Als Nächstes: das Ausnutzen von JWT-Schwachstellen.