Kernkonzepte

Die drei Segmente im Detail

Ein JWT in JWS-Form besteht aus drei Base64URL-codierten Segmenten, die mit . verbunden sind: header.payload.signature.

Header

Beschreibt die Metainformationen des Tokens selbst; am wichtigsten ist der Signaturalgorithmus:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "2024-key-01"
}

Payload (Claims)

Eine Menge von Aussagen. Drei Kategorien:

• Registrierte Claims (Registered Claims): von RFC 7519 vordefinierte Standardfelder wie iss, sub, aud, exp, nbf, iat, jti.
• Öffentliche Claims (Public Claims): bei IANA registriert oder mit kollisionssicherer Benennung (z. B. email, name aus OIDC).
• Private Claims (Private Claims): benutzerdefinierte Felder, die Aussteller und Konsument privat vereinbaren.

{
  "iss": "https://op.example.com",
  "sub": "1234567890",
  "aud": "s6BhdRkqt3",
  "exp": 1767226800,
  "iat": 1767223200,
  "roles": ["admin", "editor"]
}

Vollständige Feldbedeutungen siehe Parameter & Claims – Referenz.

Signature

Signatur über die ersten beiden Segmente (base64url(header) + "." + base64url(payload)) mit dem in alg des Headers angegebenen Algorithmus. Jede Änderung an Header/Payload macht die Signatur ungültig.

Signaturalgorithmen: symmetrisch vs. asymmetrisch

Ablauf der Signaturprüfung

Nach Erhalt eines JWT sollte der Konsument (z. B. RP oder Ressourcenserver) der Reihe nach:

1. In drei Segmente zerlegen, den Header Base64URL-decodieren und alg sowie kid auslesen.
2. Schlüssel bestimmen: bei HMAC den vereinbarten gemeinsamen Schlüssel; bei asymmetrischen Verfahren nach kid den passenden öffentlichen Schlüssel aus JWKS holen.
3. Signatur verifizieren: das dritte Segment mit dem in alg angegebenen Algorithmus prüfen.
4. Claims validieren: exp nicht abgelaufen, nbf/iat plausibel (geringe Zeitabweichung tolerieren, üblicherweise ≤ 5 Minuten); iss, aud gleich den erwarteten Werten.
5. Erst wenn alles erfolgreich war, ist der Payload vertrauenswürdig.

Die drei OIDC-Tokens: Wer ist ein JWT und wer nicht

Ein OIDC-Autorisierungscode-Flow liefert bis zu drei Tokens, deren Spezifikationsvorgaben völlig unterschiedlich sind —— dies ist das Schlüsselszenario, um die Zugehörigkeit von JWT zu verstehen.

ID Token —— muss ein JWT sein

Die OIDC-Spezifikation legt eindeutig fest, dass das ID Token ein signiertes JWT ist; sein Zweck ist es, "die Identität des Benutzers zu belegen". Der RP muss die Signatur prüfen und iss/aud/exp/nonce einzeln validieren. Details siehe OIDC Kernkonzepte · Validierungsprüfliste für RP.

Access Token —— die Spezifikation verlangt kein JWT

Für den RP sollte das access token opak (undurchsichtig) sein; der RP reicht es nur an den Ressourcenserver weiter und sollte es nicht parsen. Das tatsächliche Format hängt vom Autorisierungsserver ab:

• opak (zufälliger String): Der Ressourcenserver validiert online über den Token-Introspection-Endpunkt (RFC 7662).
• JWT: Viele moderne AS (Entra ID, Keycloak, Auth0) formen das access token nach RFC 9068 als JWT (typ: at+jwt), damit der Ressourcenserver die Signatur lokal prüfen kann und sich jede Netzwerkanfrage spart.

Refresh Token —— fast nie ein sinnvolles JWT

Für den Client völlig opak; sein einziger Zweck ist es, beim Autorisierungsserver ein neues access token einzutauschen. Für das Format gibt es keine Vorgabe der Spezifikation; üblicherweise ein hochentropischer Zufallsstring (der AS speichert dazu einen Datensatz) oder ein verschlüsselter String, den nur der AS selbst entschlüsseln kann. Der Client darf es niemals parsen.

Wie man erkennt, ob ein Refresh Token ungültig ist

Da das Refresh Token für den Client opak ist, können Sie kein exp herauslesen und daher nicht aktiv und zuverlässig vorhersagen, ob es abgelaufen ist —— Sie erfahren es erst beim Verwenden.

Weg 1: beim Verwenden auf den Fehler achten (am gängigsten, am zuverlässigsten)

Tauschen Sie das Refresh Token am token endpoint gegen neue Tokens; ist es bereits ungültig, antwortet der Autorisierungsserver:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "invalid_grant",
  "error_description": "Token is expired or revoked"
}

invalid_grant (RFC 6749 §5.2) ist das Standardsignal für "dieses Refresh Token ist nicht mehr verwendbar"; es unterscheidet nicht, ob das Token abgelaufen, widerrufen oder durch Rotation entwertet wurde —— für den Client ist das Ergebnis dasselbe: lokale Sitzung löschen und zur erneuten Anmeldung weiterleiten. Die Standardlogik lautet "optimistisch annehmen, dass es gültig ist, und erst reagieren, wenn man eines Besseren belehrt wird":

access token abgelaufen
  → mit dem refresh token ein neues eintauschen
     → Erfolg: neue Tokens speichern (Achtung Rotation, siehe unten), fortfahren
     → invalid_grant: auch das refresh token ist weg → erneut anmelden

Weg 2: bei der Ausstellung expires_in festhalten (nur schätzbar, unzuverlässig)

Manche AS geben ein nicht standardisiertes Feld zurück (je Anbieter unterschiedlich), das auf die Lebensdauer des Refresh Tokens hinweist:

{
  "access_token": "...",
  "expires_in": 3600,
  "refresh_token": "...",
  "refresh_token_expires_in": 2592000
}

Nur als Anhaltspunkt: Die meisten AS geben es nicht zurück; selbst wenn doch, kann das Refresh Token durch Widerruf, Passwortänderung, Nebenläufigkeitsgrenzen, Rotation usw. vorzeitig ungültig werden.

Wichtiger Fallstrick: Refresh Token Rotation

Moderne AS (besonders für SPA / Mobile) aktivieren meist die Rotation: Bei jedem Eintausch eines Refresh Tokens wird das alte sofort entwertet und gleichzeitig ein neues Refresh Token ausgegeben. Folgen:

1. Sie müssen jedes zurückgegebene neue Refresh Token persistieren, sonst verwenden Sie beim nächsten Mal ein bereits entwertetes.
2. Wird ein bereits benutztes altes Refresh Token erneut verwendet (Verdacht auf Kompromittierung), entwertet der AS die gesamte Token-Kette —— dann erhalten Sie selbst bei "nicht abgelaufen" ein invalid_grant.

Weiterführende Lektüre

• Parameter & Claims – Referenz —— registrierte Claims, alg-Werte, RFC-Index
• OIDC Kernkonzepte —— ID-Token-Validierungsprüfliste, JWKS und Key Rotation
• OAuth 2.0-Dokumentation —— Position von access token und refresh token im Autorisierungsablauf