Unterschied JWK und PEM?

**PEM** ist das klassische OpenSSL-Format: ein base64-Blob zwischen `-----BEGIN-----`/`-----END-----`-Zeilen. Nativ in nginx, Apache, OpenSSL-CLI, den meisten Unix-Tools. **JWK (JSON Web Key)** ist das JSON-native Format aus RFC 7517, ueberall in OAuth 2.0 und OpenID Connect, inklusive JWKS-Endpoints. Gleiches Material, zwei Praesentationen. Die meisten modernen Auth-Libraries akzeptieren beide; manche Legacy-SDKs sind nur PEM. Wir geben dir beide, weil du meist PEM fuer den signierenden Server brauchst und JWK fuers JWKS-Dokument, das andere Services fetchen.

Was ist der "kid"-Header und warum wichtig?

Das **kid (Key-ID)** ist ein kurzes Label im JWT-Header, sagt dem Verifier, welchen Public Key zu nutzen, wenn der Issuer zwischen mehreren rotiert. Ein JWKS-Endpoint gibt typisch mehrere Keys (aktuellen plus kuerzlich zurueckgezogenen waehrend Rotation), jeder mit einzigartiger kid getaggt. Der Verifier liest `header.kid` aus dem eingehenden JWT, findet den passenden Public Key im JWKS, nutzt den. Ohne kid wird Rotation schmerzhaft: der Verifier muss jeden veroeffentlichten Key probieren. Wir generieren eine 12-Zeichen-base64url-kid pro Paar und packen sie in JWK und Sample-JWT-Header, damit alles sofort konsistent ist.

Warum ist RS256 die haeufigste Wahl?

**RS256 = RSA-SHA256**, RSA-PKCS#1 v1.5 Signaturen ueber SHA-256-Hash. Default fuer **Auth0, Okta, Keycloak, AWS Cognito, Azure AD, Google Identity Platform**, und so ziemlich jeden OAuth-Provider. Grund ist historisch (RSA ist seit zwei Jahrzehnten Default-Public-Key-Algorithmus) und praktisch (jede JWT-Library auf jeder Plattform unterstuetzt es gut, auch sehr alte). Nicht das kleinste, nicht das schnellste, und PKCS#1 v1.5 nicht mehr die kryptografisch sauberste Wahl, aber **sicherste Wahl fuer Kompatibilitaet**. Ohne Constraints: RS256.

Wann ES256 statt RS256?

**ES256 = ECDSA auf P-256 mit SHA-256**. Signaturen und Keys viel kleiner: ES256-Public-Key ca. **91 Byte** vs. RS256-2048-Bit-Key ca. **294 Byte**, ES256-Signatur **64 Byte** vs. RS256 **256 Byte**. Heisst: Tokens **hunderte Bytes kuerzer**, wichtig in Mobile-Netzen, IoT und Cookies. Verifikation auch schneller auf den meisten CPUs. Trade-off: ECDSA braucht einen **guten RNG** beim Signieren (kaputter RNG kann Private Key leaken, beruehmter Sony-PS3-Vorfall). Auf modernen Node-Servern kein echtes Risiko, aber Grund, warum vorsichtige Shops noch RSA bevorzugen.

Unterschied PS256 und RS256?

Beide nutzen RSA-Keys, beide 256-Bit-Sicherheit. Unterschied: Padding-Schema. **RS256** nutzt **PKCS#1 v1.5**, deterministisches Padding von 1998, gut verstanden, aber lange Historie von Implementierungs-Fallstricken (Bleichenbacher-Attacks gegen TLS, Signing-Oracles). **PS256** nutzt **RSA-PSS** (Probabilistic Signature Scheme), modernes Padding in PKCS#1 v2.1 standardisiert, mit **beweisbarer Sicherheitsreduktion** und Randomness beim Signieren, sodass zwei Signaturen derselben Nachricht unterschiedlich sind. **PS256 kryptografisch sauberer**, NIST empfiehlt es fuer neue RSA-Protokolle. Haken: manche aelteren Verifier implementieren PS256 nicht. Kontrollierst du beide Enden: PS256. Brauchst du Interop mit der breiten Welt: RS256.

Warum heisst EdDSA "moderne Wahl"?

**EdDSA (Ed25519 im JWS-Kontext)** wurde von einem Team um Daniel Bernstein designt, um die ECDSA-Footguns zu fixen: **deterministisch** (kein RNG noetig beim Signieren, kein Sony-Style-Leak-Risiko), **kleinste Keys und Signaturen** aller gaengigen Algorithmen (32-Byte-Public-Key, 64-Byte-Signatur), **am schnellsten** bei Sign und Verify auf normaler Hardware, **konstant-Zeit per Konstruktion** (keine leichten Timing-Sidechannels). OpenSSH ging 2014 als Default drauf; TLS 1.3 adoptierte es; JWS-Spec brachte es mit RFC 8037. Einziger Grund, warum kein universeller Default: Library-Alter, viele aeltere JWT-Libraries unterstuetzen es nicht. Fuer neue Systeme mit modernen Dependencies (Node 14+, Go 1.13+, neueres Python, neueres .NET): EdDSA.

Welche RSA-Key-Groesse: 2048, 3072 oder 4096?

**2048 Bit ist die richtige Antwort fuer fast jeden**. NIST haelt 2048 RSA fuer aequivalent zu **~112 Bit Sicherheit**, der Boden fuer Keys, die Daten bis 2030 schuetzen. **3072 Bit** hebt das auf ~128 Bit, gleiches Level wie P-256/Ed25519. **4096 Bit** bietet ~152 Bit, **signiert aber ca. 3-4 mal langsamer** als 2048, kann echte CPU-Rechnung auf busy Auth-Servern werden, die Millionen Tokens/Tag ausstellen. 2048, ausser Compliance fordert 3072+. 4096 verzoegert nur den Tag, an dem du auf Elliptische Kurven migrierst, was die langfristige Antwort ist.

Wie rotiere ich JWT-Signing-Keys ohne aktive Sessions zu brechen?

Das saubere **Dual-Key-Rotations**-Pattern: (1) neues Paar mit neuer **kid** generieren; (2) **beide Keys im JWKS veroeffentlichen**; (3) **auf Cache-Propagation warten** (Verifier cachen JWKS meist 1-24h); (4) **Signer auf neuen Key umschalten**; (5) **warten bis das laengstlebige mit altem Key signierte Token ablaeuft** (typisch 1h fuer Access-Tokens, laenger fuer Refresh); (6) **alten Key aus JWKS entfernen**. Gesamte Sequenz dauert ein-zwei Tage fuer typische Access-Tokens, ein-zwei Wochen mit Long-lived Refresh-Tokens. Der kid-Header macht das sicher: jedes Token traegt die ID des signierenden Keys.

Warum Keys auf einem Server generieren, nicht im Browser?

Du **kannst** Schluesselpaare im Browser per Web Crypto API generieren, fuer einmalige Tests ok. Aber fuer Production-Keys laufen wir es server-seitig aus zwei praktischen Gruenden. Erstens: der **Entropy-Pool** auf einem Server ist meist gesuender als in einem zufaelligen Visitor-Browser, besonders auf Geraeten mit schwachem RNG (altes Android, manche Embedded-Clients). Zweitens: server-seitig gibt **einen einzigen auditierten Code-Pfad** fuer jeden Algorithmus inkl. EdDSA und P-521, wo Browser-Implementierungen historisch hinterherhinken. Die Keys verlassen unseren Speicher nach Antwort nie, wir loggen sie nicht, Antwort ist TLS-verschluesselt. Willst du staerkste Isolation: **`openssl` lokal** oder `ssh-keygen -t ed25519` und Web-Tools ueberspringen, dieses auch.

JWT-Schlüsselpaar-Generator - kostenlos

Was ein JWT-Schluesselpaar ist

Ein JWT ist ein Authentifizierungs-Token, das dein Server eingeloggten Usern gibt, damit sie sich bei jedem spaeteren Request ausweisen. Der Server signiert mit Private Key, der Client schickt es zurueck, jeder Service mit passendem Public Key kann pruefen, dass die Signatur echt war und der Payload unterwegs nicht veraendert wurde.

Damit das alles funktioniert, brauchst du ein Schluesselpaar: einen Private Key auf dem signierenden Server, und einen Public Key, den du teilst (oft als JWK in einem unter `/.well-known/jwks.json` veroeffentlichten Dokument), damit Verifier die Signatur pruefen koennen, ohne das Geheimnis je zu sehen.

Das Tool generiert das Schluesselpaar fuer jeden modernen Signing-Algorithmus: RS256/RS384/RS512 (klassisch RSA), PS256 (RSA-PSS, die sicherere RSA-Variante), ES256/ES384/ES512 (Elliptische Kurve), oder EdDSA (Ed25519, kleinste und schnellste). Du kriegst die Keys in PEM und JWK, plus ein signiertes Beispiel-JWT, das du im JWT-Decoder sofort dekodieren kannst. Server-seitig mit Nodes `crypto` generiert, nie gespeichert.

So nutzt du das Tool

Algorithmus waehlen. RS256 ist Default fuer die meisten Setups (Auth0, Okta, Keycloak und AWS Cognito defaulten alle drauf). ES256 gibt viel kleinere Tokens. EdDSA ist der moderne Liebling: kleinste Keys, schnellstes Signieren, einfachste Implementierung.
Bei RSA (RS256, RS384, RS512, PS256): Key-Groesse waehlen. 2048 Bit sinnvoller Default. 3072 und 4096 werden exponentiell langsamer mit vernachlaessigbarem realen Sicherheitsgewinn.
Bei EC (ES256, ES384, ES512): Kurve wird automatisch gewaehlt (P-256, P-384, P-521 jeweils). Das sind die einzigen Kurven, die RFC 7518 fuer jeden Algorithmus erlaubt.
Bei EdDSA: immer Ed25519, die von RFC 8037 fuer JWS standardisierte Kurve. Hier nix einzustellen.
Klick Generieren. Wir geben: Private Key in PEM, Public Key in PEM, Private Key als JWK, Public Key als JWK, plus ein signiertes Beispiel-JWT mit kleinem Payload (`sub: user-123`, 1h gueltig), damit du Ende-zu-Ende pruefen kannst.
Speicher den Private Key jetzt. Wir speichern ihn nicht. Tab schliessen heisst weg fuer immer. Installier ihn auf deinem Auth-Server, API-Gateway oder wo du Tokens ausstellst.
Veroeffentliche den Public Key als JWKS-Dokument unter `https://deine-domain.de/.well-known/jwks.json`. Die meisten Libraries (jose, jsonwebtoken, PyJWT, Microsoft.IdentityModel) koennen diese URL automatisch fetchen und cachen.
Klick In Decoder oeffnen neben dem Beispiel-JWT, um Header, Payload und Signatur live im JWT-Decoder zu sehen. Pruef, dass die kid im Header zur veroeffentlichten JWK passt.

Wann das nuetzlich ist

Sechs typische Situationen, in denen ein frisches JWT-Signing-Schluesselpaar zahlt:

Neuen Auth-Service einrichten (Keycloak, Ory Hydra, Auth0 self-hosted, eigener OAuth-Server, internes API-Gateway). Du brauchst das Schluesselpaar, bevor du das erste Token ausstellen kannst.
Von HS256 zu RS256/ES256/EdDSA migrieren. HS256 nutzt ein Shared Secret, jeder Verifier haelt die Signing-Power. Asymmetrische Algorithmen lassen dich den Private Key auf dem Auth-Server halten und Public Keys frei verteilen. Standard-Upgrade-Pfad fuer Systeme, die ueber einen Service hinauswachsen.
Key-Rotation alle 3-12 Monate als Security-Hygiene. Neuen Key unter neuer kid generieren, beide im JWKS veroeffentlichen, Signer auf neuen Key umschalten, alten nach Karenzzeit zurueckziehen.
Vermuteter Key-Kompromiss. Server-Breach, versehentliches Commiten der PEM in oeffentliches Repo, Ex-Mitarbeiter mit Key-Zugriff. Neues Paar, rotieren, alte kid in JWKS revoken, aktive Sessions force-logouten.
Multi-Issuer-Architekturen. Jeder Service stellt eigene Tokens aus; jeder kriegt eigenes Paar, damit Kompromiss-Radien unabhaengig sind.
Tests und Demos. Funktionierendes JWT zum Testen einer Verifier-Library? Paar generieren, Sample signieren, du hast ein echtes Ende-zu-Ende-Beispiel in einem Klick.

Fragen und Antworten

Ein JWT (JSON Web Token) ist ein kompakter, URL-sicherer String aus drei base64-encoded Teilen mit Punkten verbunden: `header.payload.signature`. Der Header sagt, welcher Algorithmus signiert hat. Der Payload haelt die Claims (wer der User ist, wann das Token ablaeuft, welche Scopes). Die Signatur ist der Beweis, dass der Issuer wirklich diesen Header und Payload ausgestellt hat. Zum Signieren brauchst du einen Private Key. Damit andere ohne Signing-Power verifizieren koennen, brauchen sie den passenden Public Key. Symmetrische Algorithmen (HS256, HS384, HS512) nutzen ein geteiltes Geheimnis stattdessen, was fuer einen einzigen Service ok ist, aber bricht, sobald ein zweiter Service deine Tokens verifizieren muss.

Was ein JWT-Schluesselpaar ist

So nutzt du das Tool

Algorithmus waehlen. RS256 ist Default fuer die meisten Setups (Auth0, Okta, Keycloak und AWS Cognito defaulten alle drauf). ES256 gibt viel kleinere Tokens. EdDSA ist der moderne Liebling: kleinste Keys, schnellstes Signieren, einfachste Implementierung.

Bei RSA (RS256, RS384, RS512, PS256): Key-Groesse waehlen. 2048 Bit sinnvoller Default. 3072 und 4096 werden exponentiell langsamer mit vernachlaessigbarem realen Sicherheitsgewinn.

Bei EC (ES256, ES384, ES512): Kurve wird automatisch gewaehlt (P-256, P-384, P-521 jeweils). Das sind die einzigen Kurven, die RFC 7518 fuer jeden Algorithmus erlaubt.

Bei EdDSA: immer Ed25519, die von RFC 8037 fuer JWS standardisierte Kurve. Hier nix einzustellen.

Klick Generieren. Wir geben: Private Key in PEM, Public Key in PEM, Private Key als JWK, Public Key als JWK, plus ein signiertes Beispiel-JWT mit kleinem Payload (`sub: user-123`, 1h gueltig), damit du Ende-zu-Ende pruefen kannst.

Speicher den Private Key jetzt. Wir speichern ihn nicht. Tab schliessen heisst weg fuer immer. Installier ihn auf deinem Auth-Server, API-Gateway oder wo du Tokens ausstellst.

Veroeffentliche den Public Key als JWKS-Dokument unter `https://deine-domain.de/.well-known/jwks.json`. Die meisten Libraries (jose, jsonwebtoken, PyJWT, Microsoft.IdentityModel) koennen diese URL automatisch fetchen und cachen.

Klick In Decoder oeffnen neben dem Beispiel-JWT, um Header, Payload und Signatur live im JWT-Decoder zu sehen. Pruef, dass die kid im Header zur veroeffentlichten JWK passt.

Wann das nuetzlich ist

Sechs typische Situationen, in denen ein frisches JWT-Signing-Schluesselpaar zahlt:

Neuen Auth-Service einrichten (Keycloak, Ory Hydra, Auth0 self-hosted, eigener OAuth-Server, internes API-Gateway). Du brauchst das Schluesselpaar, bevor du das erste Token ausstellen kannst.
Von HS256 zu RS256/ES256/EdDSA migrieren. HS256 nutzt ein Shared Secret, jeder Verifier haelt die Signing-Power. Asymmetrische Algorithmen lassen dich den Private Key auf dem Auth-Server halten und Public Keys frei verteilen. Standard-Upgrade-Pfad fuer Systeme, die ueber einen Service hinauswachsen.
Key-Rotation alle 3-12 Monate als Security-Hygiene. Neuen Key unter neuer kid generieren, beide im JWKS veroeffentlichen, Signer auf neuen Key umschalten, alten nach Karenzzeit zurueckziehen.
Vermuteter Key-Kompromiss. Server-Breach, versehentliches Commiten der PEM in oeffentliches Repo, Ex-Mitarbeiter mit Key-Zugriff. Neues Paar, rotieren, alte kid in JWKS revoken, aktive Sessions force-logouten.
Multi-Issuer-Architekturen. Jeder Service stellt eigene Tokens aus; jeder kriegt eigenes Paar, damit Kompromiss-Radien unabhaengig sind.
Tests und Demos. Funktionierendes JWT zum Testen einer Verifier-Library? Paar generieren, Sample signieren, du hast ein echtes Ende-zu-Ende-Beispiel in einem Klick.

Fragen und Antworten

JWT-Schlüsselpaar-Generator

Was ein JWT-Schluesselpaar ist

So nutzt du das Tool

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

JWT Decoder

DKIM-Schlüsselpaar-Generator

bcrypt prüfen

Passwort-Hashes: MD5, SHA, bcrypt

UUID-Generator

JWT-Schlüsselpaar-Generator

Was ein JWT-Schluesselpaar ist

So nutzt du das Tool

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

JWT Decoder

DKIM-Schlüsselpaar-Generator

bcrypt prüfen

Passwort-Hashes: MD5, SHA, bcrypt

UUID-Generator