Dekodieren erklärt den Inhalt, validieren begründet Vertrauen
JWT ist ein Format für strukturierte Claims. Die häufig sichtbare kompakte signierte Form besteht aus Header, Nutzdaten und Signatur. Das gesamte JWT-Format kennt weitere Formen, darunter verschlüsselte Token. Deshalb gilt „JWT hat immer drei Teile“ nicht allgemein. Eine gewöhnliche signierte Nutzlast ist lesbar; Base64url ist keine Verschlüsselung. RFC 7519, Abschnitte 3 und 5 beschreibt das Format.
Dekodieren ist beim Debuggen hilfreich, aber der Inhalt stammt zunächst vom Absender. Kopieren Sie echte Token nicht in öffentliche Decoder, Tickets oder Chats. Verwenden Sie für Anschauungen synthetische Claims und für einen konkreten Vorfall einen kontrollierten internen Diagnoseweg.
Den angenommenen Tokenvertrag schriftlich festlegen
Für eine fiktive Dokumenten-API könnte der Vertrag so aussehen:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Eigenschaft | Festgelegte Erwartung im Beispiel |
|---|---|
| Zweck | Access-Token für die Dokumenten-API, kein ID-Token |
| Aussteller | Eine ausdrücklich konfigurierte Ausstellerkennung |
| Audience | Die ausdrücklich konfigurierte Kennung der Dokumenten-API |
| Schlüsselquelle | Vertrauenswürdige Konfiguration beziehungsweise Metadaten dieses Ausstellers |
| Algorithmen | Kleine ausdrücklich zugelassene Menge passend zu den Schlüsseln |
| Zeit | Ablauf erforderlich; gegebenenfalls nbf; begrenzte dokumentierte Uhrentoleranz |
| Weitere Claims | Vom gewählten Profil und von der Anwendung geforderte Angaben |
Ein Standard kann diese Regeln konkretisieren. RFC 9068 ist ein bestimmtes Profil für OAuth-JWT-Access-Token, nicht die universelle Definition aller JWTs. Dort gehören unter anderem Signatur, typ als at+jwt beziehungsweise application/at+jwt sowie bestimmte Pflichtclaims zum Vertrag. Ein anders vereinbartes Access-Token darf nicht stillschweigend als konform zu diesem Profil beschrieben werden. Siehe RFC 9068, Abschnitte 2 und 4.
Die Bibliothek mit vertrauenswürdigen Vorgaben aufrufen
Nutzen Sie eine gepflegte Bibliothek mit einem Verifikationsaufruf. Ein Aufruf namens decode oder das eigene Parsen der Punkte und JSON-Daten erfüllt diese Aufgabe nicht. Die konkrete API unterscheidet sich zwischen Bibliotheken; wichtig ist die nachprüfbare Wirkung:
- Format und Größen begrenzen. Fehlerhafte oder unverhältnismäßig große Eingaben werden zurückgewiesen, bevor sie teure Verarbeitung auslösen.
- Algorithmus und Schlüssel vorgeben. Die Anwendung erlaubt nur passende Verfahren. Das unbestätigte
algim Token wählt nicht eigenständig eine neue Vertrauensregel. - Kryptografische Gültigkeit prüfen. Bei signierten Access-Token muss die Signatur mit einem für den Aussteller vertrauenswürdigen Schlüssel stimmen. Fehlgeschlagene Prüfungen führen zur Ablehnung.
- Zweck, Aussteller und Empfänger prüfen. Akzeptieren Sie nur die vereinbarte Tokenart, den erwarteten
issund die für diese API vorgeseheneaud. - Zeit und Pflichtclaims prüfen. Ablauf, gegebenenfalls früheste Gültigkeit und profilabhängige Angaben werden tatsächlich durchgesetzt, nicht nur ausgelesen.
- Fachliche Berechtigung entscheiden. Scope, Identität, Mandant, Objekt und Aktion werden in der Anwendung zusammengeführt.
Die JWT-Sicherheits-BCP RFC 8725, Abschnitt 3 fordert unter anderem Algorithmusprüfung, Schlüsselbindung an den Aussteller und die Trennung verschiedener Tokenarten. Für das hier beschriebene signierte API-Zugriffstoken ist alg: none keine zulässige Abkürzung. Die Regeln einer OIDC-Anmeldung dürfen nicht als Ersatz für die Ressourcenprüfung eingesetzt werden.
Ablauf und Uhrzeit ohne unbegrenzte Kulanz prüfen
exp bezeichnet die Ablaufzeit: Am Ablaufzeitpunkt und danach ist das Token nicht mehr zu akzeptieren. nbf begrenzt den frühesten Nutzungszeitpunkt; iat nennt die Ausgabezeit und ist allein kein Ablaufdatum. Die Werte sind NumericDate-Zeitangaben, keine Millisekunden aus jeder beliebigen Programmierschnittstelle. RFC 7519, Abschnitte 4.1.4 bis 4.1.6 legt ihre Bedeutung fest.
Eine kleine explizite Uhrentoleranz kann nötig sein. Bestimmen Sie sie anhand synchronisierter Systeme und tatsächlicher Anforderungen. Große Kulanz als Reparatur eines Zeitfehlers verlängert die Nutzbarkeit unerwünscht. Prüfen Sie außerdem, ob die Bibliothek einen fehlenden Claim lediglich überspringt: Was Ihr Vertrag verlangt, muss auch bei Abwesenheit abgewiesen werden.
Die JWT-Basisspezifikation macht nicht jeden registrierten Claim für jede Anwendung verpflichtend. Ihr Profil darf und muss strenger sein. Daher ist „exp optional in JWT“ keine Begründung, in einem Vertrag mit vorgeschriebenem Ablauf ein unbegrenzt gültiges Token anzunehmen.
Schlüsselwechsel und JWKS kontrolliert behandeln
Eine JWKS ist eine Sammlung veröffentlichter Schlüssel. Bei asymmetrischen Signaturen veröffentlicht der Aussteller die zur Prüfung vorgesehenen öffentlichen Schlüssel; der private Signierschlüssel bleibt geschützt. OIDC Discovery beschreibt dafür unter anderem issuer und jwks_uri. Die Metadaten müssen zum erwarteten Aussteller passen. Siehe OpenID Connect Discovery, Abschnitte 3 und 4.3.
Ein kid hilft, innerhalb der vertrauenswürdigen Schlüsselmenge auszuwählen. Es erteilt keine Erlaubnis, einen beliebigen vom Token genannten Server abzurufen. Begrenzen Sie Nachladen, Netzwerkziele und Fehlerbehandlung. Unbekannte Schlüssel dürfen keine unbegrenzten Abrufschleifen auslösen; ein Netzfehler darf die Signaturprüfung nicht abschalten.
Planen Sie einen normalen Schlüsselwechsel mit dem Aussteller: neue Prüfschlüssel bereitstellen, neue Token ausgeben und alte Schlüssel nur so lange berücksichtigen, wie der vereinbarte Übergang es verlangt. Bei einem kompromittierten Signierschlüssel kann dagegen eine sofortige Vertrauensrücknahme nötig sein. Caches und alle prüfenden Instanzen gehören zum Nachweis. Eine universelle Cachezeit lässt sich dafür nicht aus dem Tokenformat ableiten.
Mit gezielten Gegenfällen prüfen
Erstellen Sie die folgenden Varianten ausschließlich mit eigener Testinfrastruktur und synthetischen Identitäten. Die Tabelle ist eine Prüfvorlage, kein Bericht über bereits ausgeführte Tests:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Eigener Fall | Erwartetes Ergebnis |
|---|---|
| Vollständig passendes, gültiges Access-Token | Nur die fachlich erlaubte Operation funktioniert |
| Passende Signatur, andere Audience | Ablehnung vor Datenfreigabe |
| Passende Audience, nicht vertrauter Aussteller | Ablehnung |
| ID-Token statt Access-Token | Ablehnung nach dem Tokenvertrag |
| Abgelaufenes Token oder fehlender vorgeschriebener Ablauf | Ablehnung |
Zukünftiges nbf außerhalb der Toleranz | Ablehnung |
| Unbekannter Schlüssel oder nicht erlaubter Algorithmus | Ablehnung; keine Ausweichprüfung ohne Signatur |
| Gültiges Token, fremdes Dokument | Ablehnung durch Objektberechtigung |
Ergänzen Sie einen legitimen Schlüsselwechsel und einen Ausfall der Schlüsselquelle. So sehen Sie, ob Verfügbarkeit und Sicherheitsgrenze gleichzeitig wie geplant funktionieren. Halten Sie Grund und Zeitpunkt der Ablehnung fest, ohne ganze Token zu protokollieren.
Signaturprüfung löst den Widerruf nicht automatisch
Ein lokal validierbares Token kann trotz gesperrter Benutzersitzung noch kryptografisch gültig sein. Falls Ihr Produkt sofortigen Entzug verspricht, muss dieser durch geeignete Zustandsprüfung, Tokenauskunft oder einen anderen überprüften Mechanismus wirksam werden. Kurze Laufzeiten begrenzen das Zeitfenster, ersetzen aber keine beliebige Sofortsperrzusage. RFC 7662 beschreibt Tokenintrospektion als einen möglichen Baustein.
Führen Sie strengere Validierung zuerst mit eigenen Clients und dokumentierten Tokenprofilen ein. Eine Rücknahme stellt die vorherige sichere Konfiguration wieder her; sie setzt weder Signatur- noch Audienceprüfung außer Kraft. Der API Security Check validiert keine Zugangstoken. Nutzen Sie dafür Ihre Integrationstests und anschließend die Berechtigungsprüfung. Quellenstand: 27. September 2026.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.