JWT-Signaturprüfer (RS256/ES256, Verifizierung mit öffentlichem Schlüssel)
Ein Entwickler-Tool, das mit RS256 oder ES256 signierte JWTs (JSON Web Tokens) direkt im Browser mithilfe eines öffentlichen Schlüssels im PEM-Format (SPKI) verifiziert. Es dekodiert außerdem Header/Payload und prüft den Ablaufzeitpunkt. Nichts von dem, was Sie eingeben, wird an einen Server gesendet; alles läuft im Browser.
Unterstützte Signaturalgorithmen
| Algorithmus | Schlüsseltyp | Hash-Funktion | Beschreibung |
|---|---|---|---|
| RS256 | RSA (RSASSA-PKCS1-v1_5) | SHA-256 | Signatur mit RSA-Public-Key-Kryptografie. Der Standardalgorithmus für ID-Tokens großer OAuth-2.0-/OpenID-Connect-Anbieter wie Google, Auth0 und Okta. |
| ES256 | ECDSA (Kurve P-256) | SHA-256 | Signatur mit Kryptografie auf Basis elliptischer Kurven, die bei kürzeren Schlüsseln und Signaturen ein zu RSA gleichwertiges Sicherheitsniveau bietet – zunehmend beliebt bei mobilen Apps und IoT-Geräten. |
Tipps
- Der öffentliche Schlüssel muss im PEM-Format (SPKI, beginnend mit „-----BEGIN PUBLIC KEY-----") vorliegen. Das direkte Einfügen einer privaten Schlüsseldatei oder eines Zertifikats (.crt) funktioniert nicht.
- Der Prüfalgorithmus wird automatisch anhand des
alg-Feldes im JWT-Header (RS256 oder ES256) gewählt – eine manuelle Auswahl ist nicht nötig. - Zusammen mit der Signaturprüfung wird auch der
exp-Claim im Payload geprüft und bei Ablauf gewarnt. Eine gültige Signatur bedeutet nicht, dass das Token weiterhin akzeptiert werden sollte. - Dieses Tool unterstützt nur RS256 und ES256. Um ein mit HS256 signiertes JWT zu prüfen, verwenden Sie das begleitende Tool JWT-Encoder, um mit demselben gemeinsamen Geheimnis erneut zu signieren und das Ergebnis zu vergleichen.
- Der zur Verifizierung verwendete öffentliche Schlüssel ist nicht geheim, daher können Sie bedenkenlos einen Schlüssel einfügen, der vom öffentlichen Endpunkt eines Identity-Providers (etwa einem JWKS) stammt.
Häufig gestellte Fragen
Übrigens – HMAC versus Signaturen mit öffentlichem Schlüssel: Was ist der Unterschied?
JWT-Signaturverfahren lassen sich grob in zwei Familien einteilen: solche mit gemeinsamem Geheimnis (HMAC, z. B. HS256) und solche mit öffentlichem Schlüssel (RSA/ECDSA, z. B. RS256 und ES256). Bei einem gemeinsamen Geheimnis müssen sowohl Signierer als auch Prüfer dieselbe geheime Zeichenkette besitzen; bei Public-Key-Kryptografie besitzt nur der Signierer einen privaten Schlüssel, während jeder mit dem öffentlich verfügbaren Schlüssel prüfen kann. Dieser Unterschied prägt das API-Design maßgeblich. Das begleitende Tool JWT-Encoder (HS256) eignet sich, wenn derselbe Server Tokens ausstellt und prüft, während RS256/ES256 – der Schwerpunkt dieses Tools – sich eignen, wenn Aussteller und Prüfer zu völlig unterschiedlichen Organisationen oder Servern gehören.
In der Praxis werden ID-Tokens großer Identity-Provider wie Google OAuth 2.0, OpenID Connect, Auth0 und Okta fast ausnahmslos mit RS256 signiert (wobei ES256 oft als Alternative verfügbar ist). Dadurch besitzt nur der Identity-Provider den privaten Schlüssel, während beliebig viele Client-Anwendungen Tokens allein mit dem öffentlichen Schlüssel prüfen können – ein Geheimnis muss nicht an jeden Client verteilt werden, und das Risiko eines Schlüsselverlusts wird auf einen einzigen Punkt beim Signierer beschränkt.
RS256 und ES256 verwenden beide SHA-256 zum Hashen, unterscheiden sich aber in der zugrunde liegenden Kryptografie. RS256 nutzt RSA (typischerweise Schlüssel mit 2048 Bit oder mehr), was tendenziell größere Signaturen erzeugt, profitiert aber von ausgereiften, weitverbreiteten Bibliotheken. ES256 nutzt Kryptografie auf Basis elliptischer Kurven (P-256) und erreicht mit deutlich kürzeren Schlüsseln und Signaturen ein vergleichbares Sicherheitsniveau – eine zunehmend beliebte Wahl für mobile Umgebungen und APIs, bei denen die Payload-Größe eine Rolle spielt.