JWT-Glossar

JWS-Header-Parameter, der den Signatur-Algorithmus angibt.

Der alg-Parameter im JOSE-Header gibt den verwendeten Signatur- oder MAC-Algorithmus an. Zulässige Werte sind in RFC 7518 (JWA) standardisiert: HS256/384/512, RS256/384/512, ES256/384/512, PS256/384/512, EdDSA, none. Der Wert "none" steht für ein unsigniertes Token - Libraries müssen ihn aktiv ablehnen, sonst entsteht die alg=none-Schwachstelle.

Verwandt: JWS,kid,HS256

Standard-Claim, der die Zielgruppe eines JWT angibt.

Der aud-Claim (RFC 7519, Section 4.1.3) identifiziert die Empfänger, für die das Token bestimmt ist. Ein Verifier MUSS prüfen, ob der eigene Service-Identifier im aud-Claim steht - sonst kann ein Token, das für Service A ausgestellt wurde, gegen Service B verwendet werden. Wert kann ein String oder Array sein.

Verwandt: Claims,iss,JWT

HTTP-Header zum Übertragen von Credentials, typisch "Bearer <jwt>".

Standardmechanismus aus RFC 7235 zum Übermitteln von Authentifizierungs-Daten. Für JWT-basierte Auth wird das Schema "Bearer" verwendet (RFC 6750): Authorization: Bearer eyJhbGciOiJIUzI1NiI... - der Server liest das Token und validiert es. Alternative für Browser-Clients: httpOnly-Cookie.

Verwandt: Bearer,OAuth

URL-sichere Variante von Base64, die in JWT verwendet wird.

Base64url (RFC 4648, Section 5) ersetzt die Zeichen "+", "/" und "=" durch "-", "_" und Weglassen - damit das Encoding sicher in URLs und HTTP-Headern transportiert werden kann. JWT-Komponenten (Header, Payload, Signature) sind alle base64url-encoded und mit Punkten verbunden.

Verwandt: JWT,JWS

OAuth-2.0-Token-Schema: wer das Token hat, darf es nutzen.

Definiert in RFC 6750. Das Bearer-Schema bedeutet: jeder Inhaber des Tokens darf damit auf geschützte Ressourcen zugreifen - es gibt keine zusätzliche Cryptographic-Proof-of-Possession. Konsequenz: das Token muss nur über TLS übertragen werden und sollte kurze Lifetime haben.

Verwandt: Authorization-Header,OAuth

Die im JWT-Payload enthaltenen Aussagen über das Subject.

Claims sind die Aussagen, die der Issuer im Token kodiert. RFC 7519 unterscheidet drei Typen: Registered Claims (Standard wie iss, sub, exp), Public Claims (frei wählbar, aber kollisionssicher registriert) und Private Claims (custom-Felder zwischen Issuer und Consumer abgesprochen).

Verwandt: JWT,Payload,sub,iss

Edwards-Curve Digital Signature Algorithm (Ed25519, Ed448).

Moderne ECDSA-Variante, basierend auf Edwards-Kurven. In RFC 8037 für JWT/JWS standardisiert. Vorteile gegenüber ECDSA (P-256): deterministische Signaturen (kein Risiko durch schwachen RNG), schneller, kürzere Keys (32 Byte für Ed25519). Empfehlung für neue Systeme, sofern Bibliothek-Support gegeben.

Verwandt: ES256,JWA

ECDSA-Signatur über Curve P-256 mit SHA-256-Hash.

Asymmetrischer Algorithmus mit kleineren Keys (~256 bit) und kürzeren Signaturen (~64 byte) als RS256. Beliebt bei Mobile- und IoT-Setups. Achtung: Signatur-Format unterscheidet sich zwischen JOSE (raw R||S Konkatenation) und OpenSSL (ASN.1-DER) - viele Libraries machen hier Fehler.

Verwandt: RS256,EdDSA

Unix-Timestamp, bis zu dem das Token gültig ist.

Pflichtprüfung für jeden Verifier (RFC 7519 §4.1.4). Wert ist NumericDate (Sekunden seit Epoch). Ablauf wird streng geprüft: token gilt nur, wenn now < exp. Clock-Skew-Toleranz von ±30-60 Sekunden ist Standard, um Uhren-Drift zwischen Issuer und Verifier auszugleichen.

Verwandt: Claims,iat,nbf

Erster Teil eines JWT: enthält alg, typ und ggf. kid.

Der JOSE-Header (RFC 7515 §4) deklariert den Algorithmus (alg), Token-Typ (typ: "JWT") und ggf. den Schlüssel-Identifier (kid). Base64url-encoded als erster der drei Punkt-getrennten Teile. Vorsicht: der Header ist von außen veränderbar - alg-Whitelisting im Verifier ist Pflicht.

Verwandt: alg,kid,JWT

Symmetrischer JWT-Algorithmus: HMAC mit SHA-256.

HS256 nutzt einen Shared Secret zum Signieren UND Verifizieren. Wer signieren kann, kann auch verifizieren - und umgekehrt. Geeignet für interne Services, bei denen ein einziger Issuer und Verifier den Key teilen. Secret-Empfehlung: ≥ 32 Byte zufällige Daten (256 bit), via Vault/KMS gemanagt.

Verwandt: HS384,HS512,RS256

HMAC mit SHA-384 bzw. SHA-512.

Wie HS256, nur mit größerem Hash-Output (384 bzw. 512 bit Signaturlänge). Praktisch kein Sicherheitsgewinn gegenüber HS256 für aktuelle Anwendungen - SHA-256 ist nach NIST-Standards bis weit ins 21. Jahrhundert kollisionssicher. Hauptanwendung: Compliance-Vorgaben, die größere Hashes vorschreiben.

Verwandt: HS256

Unix-Timestamp, wann das Token ausgestellt wurde.

Optionaler Claim (RFC 7519 §4.1.6). Wird vor allem für Token-Reuse-Detection benutzt (Refresh-Token-Pattern: jüngeres Token erkennt älteres als kompromittiert). iat allein erzwingt keine Gültigkeit - exp und nbf sind die Gate-Keeper.

Verwandt: exp,nbf

Identifiziert die ausstellende Instanz des Tokens.

String (typisch URL) oder URI, der den Issuer eindeutig macht (RFC 7519 §4.1.1). In OpenID Connect ist iss der OAuth-Provider - z.B. "https://accounts.google.com". Verifier prüft iss gegen eine Whitelist erwarteter Issuer, kombiniert mit JWKS-Lookup.

Verwandt: Claims,aud,JWKS

IETF-Working-Group und Spec-Familie für JSON-basierte Crypto.

Sammelbegriff für die RFCs 7515 (JWS), 7516 (JWE), 7517 (JWK), 7518 (JWA), 7519 (JWT). Alle JWTs sind JOSE-Objekte. Die JOSE-Spec definiert das Header-Format und die kryptographischen Primitives.

Verwandt: JWS,JWE,JWK,JWT

Eindeutige ID eines JWT, ermöglicht Sperren einzelner Tokens.

String, der innerhalb des Issuer-Scopes eindeutig sein muss (RFC 7519 §4.1.7). Ermöglicht eine Token-Blacklist serverseitig (Replay-Schutz, manuelles Revoke). Lookup-Kosten beachten - bei hohem Volume meist über Bloom-Filter oder Redis.

Verwandt: Claims

RFC 7518, listet alle erlaubten Crypto-Algorithmen für JOSE.

Definiert welche Algorithmen für alg-Header zulässig sind: HMAC-SHA-Varianten, RSA-PKCS1, RSA-PSS, ECDSA, EdDSA (via RFC 8037), AES-GCM/CBC etc. Updates erfolgen über IANA-Registries.

Verwandt: JOSE,alg

Verschlüsseltes JOSE-Objekt mit fünf Komponenten.

JWE (RFC 7516) verschlüsselt den Payload - im Gegensatz zu JWS, das nur signiert. Format: Header.EncryptedKey.IV.Ciphertext.AuthTag, je base64url. Seltener im Einsatz als JWS, weil die meisten Use-Cases nur Integrität brauchen, keine Vertraulichkeit (TLS reicht).

Verwandt: JWS,JWT

JSON-Darstellung eines kryptographischen Schlüssels.

RFC 7517: ein Schlüssel als JSON-Objekt mit Feldern wie kty (Key Type), alg, kid, n, e (für RSA), x, y, crv (für EC). Wird in JWKS (Key Sets) gebündelt und über /.well-known/jwks.json verteilt.

Verwandt: JWKS,kid

Ein Set von JWKs, typisch über /.well-known/jwks.json verteilt.

Endpoint-Format, das OAuth-Provider verwenden, um ihre aktuellen Public Keys zu publizieren. Clients laden die JWKS und cachen sie (typisch 1-24 h). Bei Key-Rotation enthält das JWKS sowohl alten als auch neuen Key parallel, damit alle noch gültigen Tokens verifiziert werden können.

Verwandt: JWK,kid,iss

Signiertes JOSE-Objekt - Header.Payload.Signature.

RFC 7515 definiert das Compact Serialization Format: drei base64url-encoded Teile, mit Punkten verbunden. JWS ist die Grundlage jedes JWT. Compact ist die häufigste Form, JSON Serialization (Object-Form) wird seltener verwendet.

Verwandt: JWT,JOSE

Kompaktes Token-Format für Claims, signiert oder verschlüsselt.

RFC 7519. JWT ist ein Anwendungsfall von JWS (signed JWT) oder JWE (encrypted JWT). Im Alltag fast immer ein signed JWT. Verwendung: Auth-Tokens (OAuth, OIDC), API-Keys, ID-Tokens, Session-Replacement.

Verwandt: JWS,Claims,OAuth

JOSE-Header, der angibt welcher Key für die Signatur verwendet wurde.

Ermöglicht Schlüssel-Rotation: der Issuer hat mehrere Keys aktiv und markiert jedes Token mit dem kid des verwendeten Keys. Der Verifier sucht im JWKS nach dem passenden kid. Achtung: kid ist user-controlled - Path-Traversal oder SQL-Injection-Versuche über kid-Lookup sind echte Angriffsvektoren.

Verwandt: JWKS,JWK

Unix-Timestamp, ab dem das Token gültig wird.

RFC 7519 §4.1.5. Gegenstück zu exp: Token darf erst ab nbf verwendet werden. Use-Case: Tokens mit zukünftiger Gültigkeit (z.B. Einladungs-Tokens). Wie bei exp ist Clock-Skew-Toleranz ±30-60 s üblich.

Verwandt: exp,iat

Authorization-Framework, oft via JWT als Bearer-Token implementiert.

RFC 6749. Authorization, nicht Authentication - OAuth gibt eigentlich nur Access-Tokens aus. Das Access-Token kann ein JWT sein (häufig) oder ein opaker String (RFC 6750). Für Identity-Use-Cases ergänzt OpenID Connect das Schema.

Verwandt: OIDC,Bearer,Refresh-Token

Identity-Schicht auf Basis von OAuth 2.0, nutzt JWT als ID-Token.

Erweitert OAuth 2.0 um eine standardisierte Identity-Schicht: nach erfolgreicher Auth liefert der Provider ein signiertes ID-Token (JWT) mit Nutzer-Claims (sub, email, name etc.). Plus standardisierte Discovery (/.well-known/openid-configuration), Userinfo-Endpoint und JWKS.

Verwandt: OAuth,JWT,JWKS

Mittlerer Teil eines JWT - enthält die Claims als JSON.

Base64url-encoded JSON-Objekt mit allen Claims. Wichtig: Payload ist NICHT verschlüsselt - jeder mit Token-Zugriff kann ihn lesen. Niemals Passwörter oder sensitive Daten im Payload speichern. Größe sollte unter ~1 KB bleiben (HTTP-Header-Limits).

Verwandt: Claims,Header,JWT

RSA Probabilistic Signature Scheme mit SHA-256.

Modernere RSA-Variante mit randomisierter Signatur (im Gegensatz zu RS256/PKCS1v1.5, das deterministisch ist). Sicherheitstechnisch von der Crypto-Community bevorzugt, aber Library-Support unterschiedlich. RS256 bleibt der De-Facto-Standard für JWT.

Verwandt: RS256

Langlebiger Token zum Erneuern abgelaufener Access-Tokens.

Nicht spezifisch JWT-bezogen, aber das Standard-Pattern bei JWT-basierten Auth-Setups: kurzlebiges Access-Token (5-15 min) + langlebiges Refresh-Token (7-30 Tage) im httpOnly-Cookie. Refresh-Token-Rotation und Reuse-Detection sind Pflicht für Production.

Verwandt: OAuth,JWT

Asymmetrischer RSA-Algorithmus mit SHA-256-Hash.

Der häufigste asymmetrische JWT-Algorithmus. Issuer signiert mit Private Key (≥ 2048 bit RSA-Key), Verifier prüft mit Public Key. Geeignet für Setups mit vielen Verifiern und einem Issuer (typisch OAuth-Provider). Public Keys werden via JWKS verteilt.

Verwandt: RS384,RS512,PS256

Dritter Teil des JWT: kryptographischer Beweis der Integrität.

Berechnet als sign(alg, key, base64url(header) + "." + base64url(payload)). Verifier muss IMMER prüfen, dass der alg-Wert im Header dem erwarteten entspricht (Algorithm-Whitelist) - sonst entstehen Schwachstellen wie alg=none oder RSA-zu-HMAC-Verwechslung.

Verwandt: alg,JWS,JWT

Identifier des Subjects (typisch User-ID) im JWT.

RFC 7519 §4.1.2. Muss innerhalb des Issuer-Scopes eindeutig sein. Typisch eine UUID oder Datenbank-ID. In OIDC ist sub die eindeutige User-ID des Auth-Providers. Application-Code sollte sub als Primary-Identifier verwenden, nicht email (email kann sich ändern).

Verwandt: Claims,iss

JOSE-Header, deklariert den Token-Typ.

Typischer Wert: "JWT". Bei nested Tokens (signed JWT enthält encrypted JWT etc.) wird "JWT" oder "at+jwt" (für Access-Token-Profile) gesetzt. Implizit: wenn typ fehlt, wird "JWT" angenommen. RFC 7519 macht das Feld optional.

Verwandt: Header,alg