OAuth 2.0, PKCE, JWT, JWK und JWKS: Rollen verstehen

OAuth 2.0, PKCE, JWT, JWK und JWKS tauchen häufig in derselben Architektur auf, sind aber nicht austauschbar. Einige Begriffe beschreiben Autorisierungsabläufe, andere ein Tokenformat oder die Darstellung kryptografischer Schlüssel.

OAuth 2.0 organisiert Autorisierung

OAuth 2.0 ist ein Framework für delegierte Autorisierung. Eine Anwendung kann damit begrenzten Zugriff erhalten, ohne dass der Nutzer ihr das Passwort eines anderen Dienstes geben muss.

OAuth verlangt nicht, dass jedes Access Token ein JWT ist. Das Tokenformat ist eine separate Designentscheidung.

PKCE schützt den Austausch des Autorisierungscodes

PKCE ergänzt den Authorization-Code-Flow um einen temporären Nachweis. Der Client erzeugt einen zufälligen code_verifier und sendet zuvor eine daraus abgeleitete Challenge. Beim Tausch des Codes muss der ursprüngliche Verifier vorgelegt werden.

Der PKCE-Generator zeigt Verifier, Challenge und S256-Transformation.

PKCE verschlüsselt kein JWT und ersetzt TLS nicht. Es schützt eine bestimmte Phase des Autorisierungsablaufs.

JWT ist ein Tokenformat

JWT definiert eine kompakte Struktur aus punktgetrennten Segmenten. Signierte JWTs können Claims und eine überprüfbare Signatur tragen.

Der JWT-Inspector, JWT-Decoder und JWT-Encoder helfen bei der Analyse.

Ein JWT zu dekodieren ist nicht dasselbe wie seine Signatur zu prüfen. Ein normaler JWT-Payload ist nicht automatisch vertraulich.

JWK und JWKS repräsentieren Schlüssel

JWK stellt einen kryptografischen Schlüssel als JSON dar. Ein JWKS enthält mehrere JWK-Objekte und wird häufig veröffentlicht, damit Clients die öffentlichen Schlüssel zur Signaturprüfung erhalten.

Der JWK/JWKS-Inspector zeigt Schlüsseltyp, Kennungen und Parameter.

Ein JWT-Header kann ein kid enthalten, mit dem der passende Schlüssel aus einem JWKS ausgewählt wird.

Zusammenspiel der Bausteine

1. ein Client startet OAuth und erzeugt PKCE-Werte;
2. der Autorisierungsserver authentifiziert den Nutzer und liefert einen Code;
3. der Client tauscht den Code zusammen mit dem PKCE-Verifier;
4. der Server liefert Tokens, möglicherweise JWTs;
5. der Empfänger liest den JWT-Header und wählt einen Schlüssel aus dem JWKS;
6. danach prüft er Signatur, Issuer, Audience, Ablaufzeit und weitere Regeln.

Häufige Verwechslungen vermeiden

• OAuth ist kein Tokenformat.
• PKCE ist keine Verschlüsselung.
• JWT-Payloads sind nicht automatisch vertraulich.
• Dekodieren ist keine Signaturprüfung.
• JWKS ist ein Schlüsselsatz, keine Liste von Nutzersitzungen.

Wichtig ist die Trennung von Protokoll, Container und Schlüsseln.