Wie funktioniert die Implementierung von Proof Key for Code Exchange (PKCE) im OAuth 2.1 Flow für Public Clients?

Die Implementierung von PKCE (Proof Key for Code Exchange) erweitert den Authorization Code Flow, um das Abfangen des Authorization Codes bei Public Clients – wie Single-Page-Applications (SPAs) oder mobilen Apps – zu verhindern. Da diese Clients kein Client-Secret sicher speichern können, ersetzt PKCE das statische Secret durch ein dynamisches, pro Request generiertes Geheimnis.

Der Prozess basiert auf drei Komponenten:

1. Code Verifier: Ein kryptografisch zufälliger String.
2. Code Challenge: Der Hash des Verifiers (üblicherweise via SHA-256).
3. Code Challenge Method: Die Angabe des verwendeten Algorithmus (z. B. S256).

Wir setzen den Ablauf technisch wie folgt um:

Wenn der berechnete Hash des übermittelten code_verifier mit der zuvor gespeicherten code_challenge übereinstimmt, stellt der Server die Access- und Refresh-Tokens aus. Ein Angreifer, der lediglich den Authorization Code abfängt, kann diesen nicht nutzen, da ihm der originale code_verifier fehlt.

In der Architektur moderner Identitätsmanagement-Systeme integrieren wir diese Mechanismen oft im Rahmen unserer IT-Consulting & Digitale Strategie, um Sicherheitslücken in dezentralen Applikationen zu schließen. In OAuth 2.1 ist PKCE nicht mehr optional, sondern für alle Client-Typen vorgeschrieben, da es die Sicherheit gegenüber dem klassischen Authorization Code Flow signifikant erhöht.

Aus technischer Sicht ist die Nutzung des Implicit Flow aufgrund der Sicherheitsrisiken (Token-Exposition in der URL) obsolet. Wir empfehlen daher, konsequent auf den Authorization Code Flow mit PKCE zu setzen, unabhängig davon, ob es sich um Public oder Confidential Clients handelt. Jede Implementierung, die heute noch auf statische Secrets in Frontend-Code oder den Implicit Flow vertraut, stellt ein kritisches Sicherheitsrisiko dar und sollte unmittelbar refactored werden.