JWT-Signaturalgorithmen: HMAC, RSA, ECDSA

Drei Algorithmen-Familien

JWT unterstützt drei Familien von Signatur-Algorithmen (RFC 7518 JWA): HMAC (symmetrisch), RSA (asymmetrisch), ECDSA (asymmetrisch, kürzere Keys). Plus EdDSA (RFC 8037), das eine modernere ECDSA-Variante ist.

HMAC: HS256, HS384, HS512

HMAC (Hash-based Message Authentication Code) nutzt einen einzigen Shared Secret zum Signieren UND Verifizieren. Wer signieren kann, kann auch verifizieren.

Algorithmus	Hash	Empfohlene Secret-Größe	Signatur-Länge
HS256	SHA-256	≥ 256 bit (32 byte)	32 byte
HS384	SHA-384	≥ 384 bit (48 byte)	48 byte
HS512	SHA-512	≥ 512 bit (64 byte)	64 byte

Wann HMAC sinnvoll ist: wenn ein einzelner Service Tokens ausstellt UND verifiziert - z.B. ein Monolith oder ein vertrauenswürdiger Microservice-Cluster mit gemeinsamem Vault-Zugang. Wann nicht: wenn mehrere unabhängige Services verifizieren müssen. Jeder Verifier mit dem Secret könnte selbst signieren - das ist meist nicht gewünscht.

Das Secret muss kryptographisch zufällig sein (z.B. openssl rand -base64 32), niemals ein Passwort oder Wörterbuch-String - sonst sind Brute-Force-Angriffe trivial.

RSA: RS256, RS384, RS512 (plus PS-Varianten)

RSA arbeitet mit Schlüsselpaaren: Private Key beim Issuer (signiert), Public Key bei den Verifiern (prüft). Niemand außer dem Issuer kann gültige Tokens erzeugen, aber jeder mit Public Key kann prüfen.

Algorithmus	Padding	Schlüsselgröße	Signatur-Länge (bei 2048-bit Key)
RS256	PKCS1v1.5	≥ 2048 bit (Pflicht), 3072 bit empfohlen	256 byte
RS384	PKCS1v1.5	≥ 2048 bit	256 byte
RS512	PKCS1v1.5	≥ 2048 bit	256 byte
PS256	PSS (probabilistisch)	≥ 2048 bit	256 byte

PS256 ist die kryptographisch modernere Variante (randomisierte Signaturen, von der Crypto-Community bevorzugt), aber Library-Support ist patchier. RS256 bleibt der De-Facto-Standard für JWT - Google, Auth0, Keycloak, Microsoft alle nutzen RS256 als Default.

Wann RSA sinnvoll ist: wenn ein zentraler Issuer für viele Verifier signiert, z.B. OAuth-Provider. Public Keys werden via JWKS-Endpoint verteilt.

ECDSA: ES256, ES384, ES512

Elliptic Curve DSA mit den NIST-Kurven P-256, P-384, P-521. Asymmetrisch wie RSA, aber mit deutlich kürzeren Keys und Signaturen.

Algorithmus	Kurve	Schlüsselgröße	Signatur-Länge
ES256	P-256 / secp256r1	256 bit	64 byte
ES384	P-384 / secp384r1	384 bit	96 byte
ES512	P-521 / secp521r1	521 bit	132 byte

Wann ECDSA sinnvoll ist: Mobile- und IoT-Setups mit Bandbreiten-Limits, oder High-Performance-APIs, wo Token-Verifikation hot ist. Server-side ist ECDSA-Verify schneller als RSA-Verify, aber langsamer als HMAC.

Achtung Signatur-Format: JOSE nutzt rohes R||S-Konkatenat (raw bytes), OpenSSL und viele Crypto-Libraries nutzen ASN.1-DER. Mismatch ist ein häufiger Bug-Quelle. Wer mit OpenSSL-CLI ein ES256-JWT verifiziert, muss die DER-Signatur erst zu raw R||S konvertieren.

EdDSA (RFC 8037)

Ed25519 und Ed448. Deterministische Signaturen (kein Risiko durch schwachen RNG), schneller als ECDSA, kürzere Keys (32 byte). Crypto-Community-Empfehlung für neue Systeme. Library-Support hat sich 2022-2024 stark verbessert, ist aber noch nicht universal - Auth0 und Google supporten EdDSA noch nicht in allen Tiers.

Welcher Algorithmus für welchen Use-Case?

Use-Case	Empfehlung
Interner Microservice-Cluster, ein Vault	HS256
OAuth-Provider mit vielen Resource-Servern	RS256 (interop), ES256 wenn alle Verifier supporten
Mobile-App mit On-Device-Verifikation	ES256 (kleinere Tokens)
Neues System, freie Wahl, alle Libraries modern	EdDSA (Ed25519)

Im JWT Decoder kannst du Tokens aller drei Familien verifizieren - Secret für HMAC, PEM-Public-Key für RSA und ECDSA.