HS256 vs RS256: Welcher JWT-Algorithmus ist der richtige?

Die Wahl zwischen HS256 und RS256 läuft auf eine Frage hinaus: Wer muss Ihre Token verifizieren? HS256 verwendet ein einziges gemeinsames Geheimnis zum Signieren und Verifizieren, was einfach und schnell ist, aber bedeutet, dass jeder Verifizierer auch die Macht hat, Token zu erstellen. RS256 verwendet einen privaten Schlüssel zum Signieren und einen separaten öffentlichen Schlüssel zum Verifizieren, sodass Sie den öffentlichen Schlüssel an jeden weitergeben können, ohne ihm die Möglichkeit zur Fälschung zu geben. Wenn Sie diesen Unterschied verstanden haben, ergibt sich der Rest der Entscheidung von selbst.

Die meisten Vergleiche bleiben bei "symmetrisch versus asymmetrisch" stehen und überlassen es Ihnen, herauszufinden, welches System Ihre Anwendung tatsächlich benötigt. Dieser Leitfaden gibt Ihnen eine Entscheidungsregel, die an Ihre Architektur gebunden ist, echte Code-Unterschiede, den Leistungskompromiss, der selten eine Rolle spielt, und den einen Konfigurationsfehler, der jeden Algorithmus zu einem Fälschungsloch macht.

HS256 vs RS256 auf einen Blick#

Beide sind JSON-Web-Token-Signaturalgorithmen, die in der JWA-Spezifikation (RFC 7518) definiert sind. Sie schützen dasselbe: die Integrität eines Tokens, sodass ein Server darauf vertrauen kann, dass die darin enthaltenen Ansprüche (Benutzer-ID, Rolle, Ablaufdatum) nicht manipuliert wurden. Sie unterscheiden sich grundlegend in der Struktur des Signaturschlüssels.

Eigenschaft	HS256	RS256
Vollständiger Name	HMAC mit SHA-256	RSA-Signatur mit SHA-256
Schlüsseltyp	Ein gemeinsames Geheimnis (symmetrisch)	Privater/öffentlicher Schlüssel (asymmetrisch)
Wer kann signieren	Jeder mit dem Geheimnis	Nur der Inhaber des privaten Schlüssels
Wer kann verifizieren	Jeder mit dem Geheimnis	Jeder mit dem öffentlichen Schlüssel
Tokengröße	Kleinere Signatur	Größere Signatur
Geschwindigkeit	Sehr schnell	Langsamer beim Signieren, schnell beim Verifizieren
Am besten geeignet für	Einzelner vertrauenswürdiger Dienst	Viele Verifizierer, Dritte

Wichtiger Tipp: Bei HS256 verwenden Verifizierer und Signierer denselben Schlüssel, sodass Verifikationsfähigkeit und Fälschungsfähigkeit untrennbar sind. Bei RS256 sind sie getrennt. Diese Tatsache bestimmt fast jede Architekturentscheidung unten.

So funktioniert HS256 (symmetrisch, gemeinsamer Schlüssel)#

HS256 steht für HMAC mit SHA-256. HMAC ist ein schlüsselgebundener Hash: Sie übergeben den Token-Header plus Payload und einen geheimen String, und es wird eine feste Signatur erzeugt. Zur Überprüfung führt der empfangende Dienst exakt denselben HMAC mit demselben geheimen Schlüssel aus und prüft, ob die Signaturen übereinstimmen.

Da Signieren und Verifizieren ein identisches Geheimnis verwenden, gibt es kein Konzept einer "öffentlichen" Seite. Jeder, der einen Token verifizieren kann, kann auch einen gültigen erstellen. Das ist in Ordnung, wenn ein einzelner Dienst Token ausstellt und selbst verifiziert.

Ein typisches HS256-Setup in Node sieht so aus:

import jwt from "jsonwebtoken";

// Signieren
const token = jwt.sign({ sub: "user_123", role: "admin" }, SHARED_SECRET, {
  algorithm: "HS256",
  expiresIn: "15m",
});

// Verifizieren (gleicher Schlüssel)
const claims = jwt.verify(token, SHARED_SECRET, { algorithms: ["HS256"] });

Der geheime Schlüssel sollte ein langer, zufälliger String sein (mindestens 32 Bytes für SHA-256). Ein schwacher oder erratbarer Schlüssel ist der häufigste Grund, warum HS256-Implementierungen geknackt werden, denn ein Angreifer, der den Schlüssel erlangt, kann alles signieren.

Wann HS256 die richtige Wahl ist#

• Ein einzelner Monolith oder ein Backend-Dienst signiert und verifiziert seine eigenen Token.
• Eine interne Service-zu-Service-Verbindung, bei der Sie beide Enden vollständig kontrollieren und einen gemeinsamen Schlüssel sicher rotieren können.
• Sie möchten den kleinstmöglichen Token und die schnellstmögliche Signierung, ohne dass eine Verifizierung durch externe Parteien erforderlich ist.

Wie RS256 funktioniert (asymmetrisch, Schlüsselpaar)#

RS256 ist eine RSA-Signatur mit SHA-256. Sie generieren ein Schlüsselpaar: einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zum Verifizieren. Der private Schlüssel verlässt niemals Ihren Authentifizierungsserver. Der öffentliche Schlüssel kann offen veröffentlicht werden, da er es einer Partei ermöglicht, Token zu verifizieren, aber niemals zu erstellen.

Diese Trennung ist der entscheidende Punkt. Sie können den öffentlichen Schlüssel an ein Dutzend Microservices, eine mobile App oder einen externen Partner verteilen, und keiner von ihnen kann einen Token fälschen, selbst wenn seine Kopie des Schlüssels durchsickert.

import jwt from "jsonwebtoken";

// Mit dem privaten Schlüssel signieren (nur Authentifizierungsserver)
const token = jwt.sign({ sub: "user_123", role: "admin" }, PRIVATE_KEY, {
  algorithm: "RS256",
  expiresIn: "15m",
});

// Mit dem öffentlichen Schlüssel verifizieren (jeder Dienst)
const claims = jwt.verify(token, PUBLIC_KEY, { algorithms: ["RS256"] });

Die meisten großen Identitätsanbieter (Auth0, AWS Cognito, Okta, Google und andere, die OpenID Connect verwenden) geben RS256-Token aus und veröffentlichen ihre öffentlichen Schlüssel an einem JWKS-Endpunkt (einer .well-known/jwks.json-URL). Ihre Dienste rufen den öffentlichen Schlüssel von dort ab und verifizieren lokal, ohne den Authentifizierungsserver pro Anfrage kontaktieren zu müssen.

Warnung: RS256 schützt Sie nur, wenn Sie den privaten Schlüssel geheim halten und mit dem öffentlichen Schlüssel verifizieren. Eine überraschende Anzahl von Fehlern entsteht, wenn ein Dienst versehentlich so konfiguriert wird, dass er mit dem privaten Schlüssel "verifiziert", oder wenn Schlüsselformate falsch behandelt werden. Prüfen Sie im Zweifelsfall den Token-Header, um zu bestätigen, dass der alg Ihren Erwartungen entspricht.

Wann RS256 die richtige Wahl ist#

• Microservices: Viele Dienste müssen Token verifizieren, aber nur einer sollte sie ausstellen.
• Verifizierung durch Dritte: Ein Partner oder eine Client-App muss Ihre Token validieren können, ohne sie erstellen zu können.
• Sie verwenden einen externen Identitätsanbieter oder OpenID Connect, wo RS256 plus JWKS der Standard ist.
• Sie möchten Signaturschlüssel rotieren, ohne ein Geheimnis an jeden Verifizierer weitergeben zu müssen (einen neuen öffentlichen Schlüssel veröffentlichen, den alten zurückziehen).

ES256 und die erweiterte Algorithmusfamilie#

HS256 und RS256 sind die beiden, die Ihnen am häufigsten begegnen, aber sie sind nicht die einzigen Optionen. ES256 (ECDSA mit P-256 und SHA-256) ist ebenfalls asymmetrisch, wie RS256, verwendet aber Elliptische-Kurven-Kryptografie. Es bietet das gleiche Modell mit privatem Schlüssel zum Signieren und öffentlichem Schlüssel zum Verifizieren, jedoch mit viel kleineren Schlüsseln und Signaturen, was die Tokens kompakt hält.

Algorithmus	Typ	Hinweise
HS256	Symmetrisch (HMAC)	Gemeinsames Geheimnis, schnell, Einzelvertrauen
RS256	Asymmetrisch (RSA)	Weit verbreiteter Standard für OIDC, größere Signaturen
ES256	Asymmetrisch (ECDSA)	Kleinere Schlüssel/Signaturen, modern, etwas weniger universelle Bibliotheksunterstützung

Wenn Sie asymmetrisches Signieren benötigen und Wert auf Tokengröße oder Leistung im großen Maßstab legen, ist ES256 einen Blick wert. Wenn Sie maximale Kompatibilität mit bestehenden Tools und Identitätsanbietern benötigen, bleibt RS256 der sicherste Standard. Die Entscheidungslogik für ES256 gegenüber RS256 ist dieselbe wie für RS256 gegenüber HS256, plus einer Kompatibilitätsprüfung Ihrer Bibliotheken.

Die Entscheidungsregel: Wer verifiziert Ihre Tokens?#

Dies ist der Teil, den die meisten Artikel auslassen. Vergessen Sie für einen Moment Geschwindigkeit und Schlüssellänge und beantworten Sie eine Frage: Wie viele verschiedene Parteien verifizieren Ihre Tokens und vertrauen Sie allen, dass sie auch signieren können?

Verwenden Sie HS256, wenn jeder Verifizierer auch ein vertrauenswürdiger Signierer ist#

Wenn das Einzige, das Ihre Tokens verifiziert, derselbe Dienst (oder eine kleine Gruppe vollständig vertrauenswürdiger interner Dienste) ist, der sie ausstellt, ist das Shared-Secret-Modell einfacher und schneller. Es gibt kein Schlüsselverteilungsproblem, da es ein Geheimnis gibt und Sie kontrollieren, wo es überall lebt. Ein klassischer Monolith mit einem einzigen Backend ist der Lehrbuchfall für HS256.

Verwenden Sie RS256 (oder ES256), sobald die Verifizierung verteilt ist#

Sobald ein Token von etwas verifiziert werden muss, dem Sie nicht erlauben möchten, zu signieren, benötigen Sie asymmetrische Schlüssel. Beispiele:

• Ein Frontend oder mobiler Client, der die Gültigkeit eines Tokens prüft.
• Eine Flotte von Microservices, bei der die Kompromittierung eines Verifizierers es einem Angreifer nicht ermöglichen sollte, Tokens für das gesamte System zu fälschen.
• Ein externer API-Consumer oder Partner, der von Ihnen ausgestellten Tokens vertrauen muss.
• Jeder OpenID Connect / OAuth-Flow mit einem externen Identitätsanbieter.

Die Regel in einem Satz: Wenn die Menge der Verifizierer größer ist als die Menge der Parteien, denen Sie das Signieren zutrauen, verwenden Sie RS256. Bei einem gemeinsamen Geheimnis ist jeder Verifizierer ein potenzieller Fälscher, und dieses Risiko wächst mit jedem Dienst, der das Geheimnis hält.

Leistung: Real, aber meist nicht entscheidend#

HMAC (HS256) ist beim Signieren deutlich schneller als RSA (RS256), oft um eine Größenordnung in rohen Benchmarks. RSA-Verifikation ist recht schnell, aber RSA-Signieren ist der teure Vorgang. Wenn Sie also große Mengen an Token auf einem Rechner signieren, gewinnt HS256 in Bezug auf die CPU.

Für die meisten Anwendungen ist dieser Unterschied vernachlässigbar. Sie signieren einen Token normalerweise einmal beim Login und verifizieren ihn viele Male während seiner kurzen Lebensdauer. Die Verifikation mit RS256 ist schnell genug, dass die Kosten pro Anfrage neben einem Datenbankzugriff oder Netzwerk-Hop unbedeutend sind. Wählen Sie Ihren Algorithmus zuerst nach dem Vertrauensmodell und lassen Sie die Leistung nur dann den Ausschlag geben, wenn Sie in extremem Maßstab signieren.

Tipp: Die Tokengröße ist ein praktischeres Anliegen als die CPU. RS256-Signaturen sind größer, was jede Anfrage aufbläht, die den Token in einem Header trägt. Wenn Sie bandbreitenempfindlich sind und asymmetrische Schlüssel benötigen, erzeugt ES256 deutlich kleinere Token als RS256.

Der Fehler, der beide bricht: Dem alg-Header vertrauen#

Egal für welchen Algorithmus Sie sich entscheiden, der gefährlichste Konfigurationsfehler ist, dem Token selbst zu überlassen, wie es verifiziert wird. Ein JWT trägt ein alg-Feld in seinem Header, und naive Verifikationscodes lesen dieses Feld und verifizieren entsprechend. Angreifer nutzen dies auf zwei bekannte Arten aus.

Erstens der alg: none-Trick: Ein Angreifer setzt den Algorithmus auf none, entfernt die Signatur, und einige Bibliotheken akzeptieren das unsignierte Token fälschlicherweise als gültig. Zweitens der RS256-zu-HS256-Verwechslungsangriff: Ein Server, der für RS256 eingerichtet ist, veröffentlicht seinen öffentlichen Schlüssel, ein Angreifer ändert den Header auf HS256 und signiert ein gefälschtes Token mit diesem öffentlichen Schlüssel als HMAC-Geheimnis. Wenn der Server dann HS256 mit dem ihm bekannten öffentlichen Schlüssel verifiziert, besteht das gefälschte Token.

Die Lösung ist in beiden Fällen dieselbe und besteht aus einer einzigen Absicht: den akzeptierten Algorithmus auf dem Verifizierer festlegen. Lassen Sie niemals das Token wählen.

// Gut: Der Server bestimmt den Algorithmus, nicht das Token
jwt.verify(token, PUBLIC_KEY, { algorithms: ["RS256"] });

Übergeben Sie immer eine explizite Whitelist von Algorithmen an Ihren Verify-Aufruf und stellen Sie sicher, dass none nicht enthalten ist. Mischen Sie HS256 und RS256 nicht im selben Verifikationspfad, denn genau diese Mehrdeutigkeit braucht der Verwechslungsangriff. Wenn Sie verstehen möchten, warum das bloße Dekodieren eines Tokens nichts über seine Echtheit aussagt, führt unser Leitfaden zum Dekodieren versus Verifizieren eines JWT durch den Unterschied, der viele Entwickler überrascht.

Wenn Sie ein Token in einem der beiden Algorithmen debuggen, fügen Sie es in unseren kostenlosen JWT-Decoder ein, um den Header zu lesen und den alg-Wert, das Ablaufdatum und die Claims zu bestätigen, bevor Sie ihm vertrauen. Den tatsächlichen Header zu sehen, ist der schnellste Weg, einen nicht übereinstimmenden oder manipulierten Algorithmus zu erkennen.

Schlüsselverwaltung: Der praktische Unterschied im Alltag#

Die Wahl des Algorithmus entscheidet leise darüber, wie viel Aufwand Sie bei der Schlüsselverwaltung betreiben müssen.

Mit HS256 haben Sie ein einziges Geheimnis. Das ist einfach zu speichern, aber die Rotation bedeutet, dass Sie es überall gleichzeitig aktualisieren müssen, und ein Leck an einer Stelle führt zu einer vollständigen Kompromittierung. Bewahren Sie es in einem Secrets Manager auf, niemals im Quellcode, und behandeln Sie jeden Dienst, der es speichert, als Teil Ihres vertrauenswürdigen Kerns.

Mit RS256 verwalten Sie ein Schlüsselpaar. Die Rotation ist sanfter: Veröffentlichen Sie einen neuen öffentlichen Schlüssel (oft über einen JWKS-Endpunkt mit einer Schlüssel-ID), beginnen Sie mit dem neuen privaten Schlüssel zu signieren und ziehen Sie den alten Schlüssel zurück, sobald ausstehende Token ablaufen. Verifizierer übernehmen den neuen öffentlichen Schlüssel automatisch. Der Nachteil sind mehr bewegliche Teile zu Beginn, weshalb ein einzelner kleiner Dienst dies selten benötigt.

Für eine breitere Übersicht über die sichere Token-Behandlung, einschließlich Speicherung, Ablauf und was bei jeder Verifizierung zu prüfen ist, lesen Sie unseren Leitfaden zum JWT-Decoder und Token-Sicherheit.

HS256 vs RS256: Das Wichtigste auf einen Blick#

Die Entscheidung zwischen HS256 und RS256 ist weniger eine Frage der kryptografischen Stärke, da beide bei korrekter Konfiguration sicher sind. Es geht vielmehr um Vertrauensgrenzen. Verwenden Sie HS256, wenn ein vertrauenswürdiger Dienst seine eigenen Token signiert und verifiziert und Sie Einfachheit und Geschwindigkeit wünschen. Greifen Sie zu RS256 (oder ES256 für kleinere Token), sobald mehr Parteien die Token verifizieren müssen, als Sie zum Signieren berechtigen möchten, das beschreibt nahezu jedes Microservice-, Mobil-, Drittanbieter- und OpenID-Connect-Setup.

Was auch immer Sie wählen: Sperren Sie den Algorithmus auf dem Verifizierer mit einer expliziten Positivliste, akzeptieren Sie niemals none und verifizieren Sie niemals Token eines Algorithmus mit dem Schlüssel eines anderen. Wenn etwas verdächtig erscheint, dekodieren Sie den Token und lesen Sie seinen Header, damit Sie genau wissen, womit Sie es zu tun haben.

Häufig gestellte Fragen#

Ist RS256 sicherer als HS256? Nicht grundsätzlich. Beide sind bei korrekter Konfiguration kryptografisch solide. RS256 ist sicherer für verteilte Systeme, da der öffentliche Verifikationsschlüssel nicht zum Fälschen von Tokens verwendet werden kann und ein Leck an viele Prüfer geringes Risiko birgt. HS256 bündelt die gesamte Macht in einem gemeinsamen Geheimnis, was für einen einzelnen vertrauenswürdigen Dienst in Ordnung ist, aber riskanter wird, je mehr Stellen das Geheimnis besitzen.

Kann ich später von HS256 auf RS256 umstellen? Ja, aber planen Sie eine Übergangsphase ein. Sie generieren ein Schlüsselpaar, signieren neue Tokens mit dem RS256-Privatschlüssel und aktualisieren die Prüfer, um RS256 zu akzeptieren. Vermeiden Sie es, einen Dienst so zu konfigurieren, dass er beide Algorithmen gleichzeitig akzeptiert, da diese Mehrdeutigkeit den Algorithmen-Verwechslungsangriff ermöglicht. Migrieren Sie sauber und stellen Sie die HS256-Überprüfung ein, sobald alte Tokens abgelaufen sind.

Welchen Algorithmus verwenden Identitätsanbieter wie Auth0 und Cognito? Die meisten großen Identitätsanbieter verwenden standardmäßig RS256 und veröffentlichen ihre öffentlichen Schlüssel an einem JWKS-Endpunkt (eine .well-known/jwks.json-URL). Ihre Dienste rufen den öffentlichen Schlüssel ab und verifizieren Tokens lokal. Deshalb ist RS256 der praktische Standard für jede OpenID Connect- oder OAuth-Integration mit einem externen Anbieter.

Warum ist RS256 langsamer als HS256? RSA-Signierung ist mathematisch aufwändiger als die HMAC-Operation von HS256, daher ist die Signierung spürbar langsamer, oft um eine Größenordnung in rohen Benchmarks. Die Verifikation ist bei beiden schnell. Für die meisten Anwendungen spielt dieser Unterschied keine Rolle, da Sie viel häufiger verifizieren als signieren und die Verifikationskosten im Vergleich zu Netzwerk- und Datenbankzeit gering sind.

Was ist der Algorithmen-Verwechslungsangriff? Dabei wird ein Server, der RS256 erwartet, dazu gebracht, ein HS256-Token mit seinem eigenen öffentlichen Schlüssel als HMAC-Geheimnis zu verifizieren. Da der öffentliche Schlüssel bekanntermaßen Angreifern bekannt ist, können sie ein gültiges Token fälschen. Die Lösung besteht darin, den akzeptierten Algorithmus auf dem Prüfer mit einer Whitelist festzulegen und niemals den alg-Header des Tokens entscheiden zu lassen. Sie können den deklarierten Algorithmus eines Tokens mit einem kostenlosen JWT-Decoder beim Debuggen überprüfen.

Sollte ich jemals ES256 anstelle von RS256 verwenden? Ziehen Sie ES256 in Betracht, wenn Sie asymmetrische Signierung benötigen, aber kleinere Tokens und Schlüssel wünschen, was Bandbreite und mobile Clients entlastet. Es verwendet dasselbe Modell (privat signieren, öffentlich verifizieren) wie RS256. Der Hauptnachteil ist eine etwas geringere universelle Unterstützung durch Bibliotheken und Anbieter. Überprüfen Sie daher, ob Ihr Stack ES256 verarbeitet, bevor Sie sich festlegen.