PKCE: Öffentliche Clients absichern

Ohne PKCE sind mobile Anwendungen anfällig für Angriffe durch das Abfangen von Authorization Codes. Wenn der Authorization Server den Authorization Code an das registrierte benutzerdefinierte URI-Schema der Anwendung weiterleitet (z. B. myapp://callback), kann jede schädliche Anwendung auf demselben Gerät, die dasselbe URI-Schema registriert, die Weiterleitung abfangen und den Code stehlen.

Der Angriff läuft folgendermaßen ab: Eine schädliche Anwendung registriert dasselbe benutzerdefinierte URI-Schema wie die legitime Anwendung. Wenn der Authorization Server den Code an myapp://callback weiterleitet, kann das Betriebssystem beide Anwendungen als Handler anbieten. Wählt der Benutzer die schädliche Anwendung aus oder legt das Betriebssystem sie als Standard fest, erhält der Angreifer den Authorization Code und kann ihn gegen Tokens eintauschen, ohne das Client-Secret zu kennen.

PKCE (RFC 7636) fügt dem Authorization-Code-Flow ein dynamisch generiertes Geheimnis hinzu. Vor Beginn des Flows erzeugt der Client eine kryptografisch zufällige Zeichenfolge aus 43 bis 128 Zeichen, den sogenannten Code Verifier. Diese Zeichenfolge ist für jede Autorisierungsanfrage eindeutig und wird erst beim Token-Austausch übertragen.

Der Client berechnet aus dem Verifier eine Code-Challenge: code_challenge = BASE64URL(SHA256(code_verifier)). Die Verwendung von SHA256 ist die in RFC 7636 vorgeschriebene Methode (die Methode "plain", bei der der Verifier direkt übertragen wird, wird nicht empfohlen). Die Code-Challenge ist eine Einwegtransformation des Verifiers. Das bedeutet, dass die Kenntnis der Challenge den Verifier nicht preisgibt.

Die Autorisierungsanfrage enthält zwei zusätzliche Parameter: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Der Authorization Server speichert die Code-Challenge zusammen mit dem ausgestellten Authorization Code. In diesem Schritt wird kein Geheimnis an den Server übertragen, das abgefangen werden könnte.

Während des Token-Austauschs (POST an den Token-Endpunkt) übermittelt der Client zusammen mit dem Authorization Code auch "code_verifier=ORIGINAL_RANDOM_STRING". Der Authorization Server berechnet BASE64URL(SHA256(code_verifier)) und überprüft, ob das Ergebnis mit der gespeicherten code_challenge übereinstimmt. Nur der legitime Client, der den Verifier erzeugt hat, kann diese Prüfung bestehen.

Fängt ein Angreifer den Authorization Code ab, erhält er nur den Code und die Code-Challenge, die öffentlich ist. Um den Code gegen Tokens einzutauschen, muss er den Code-Verifier angeben. Da der Verifier vom legitimen Client erzeugt und erst beim Token-Austausch, der sicher erfolgt, übertragen wurde, kann der Angreifer den Verifier weder berechnen noch abrufen.

PKCE verhindert außerdem Angriffe durch die Injektion von Autorisierungscodes. Dabei ersetzt ein Angreifer im Redirect einen gültigen Code durch einen gestohlenen Code. Die Challenge des gestohlenen Codes stimmt nicht mit dem Verifier überein, den der Client des Opfers vorlegen wird, sodass der Token-Austausch fehlschlägt. PKCE bietet gleichzeitig eine zusätzliche Sicherheitsebene gegen mehrere Angriffsvektoren.

Obwohl RFC 7636 ursprünglich als Lösung für öffentliche Clients (also Clients ohne Client-Secret) beschrieben wurde, verlangen das OAuth Security BCP und OAuth 2.1 PKCE für alle Clients, einschließlich vertraulicher Clients mit Client-Secret. PKCE bietet unabhängig von der Client-Authentifizierung Schutz und ist daher universell vorteilhaft.

OAuth 2.1 (draft-ietf-oauth-v2-1) fasst die bewährten Sicherheitspraktiken aus dem OAuth 2.0 Security BCP in einem einzigen Dokument zusammen. Es schreibt PKCE für alle Authorization-Code-Flows vor, stuft den Implicit Flow als veraltet ein und verlangt eine Rotation von Refresh-Tokens. PKCE ist damit praktisch die erforderliche Grundlage für jede neue OAuth-2.0-Implementierung.

Eine korrekte Implementierung von PKCE erfordert: einen kryptografisch sicheren Zufallszahlengenerator für den Verifier zu verwenden (mindestens 32 zufällige Bytes, anschließend base64url-kodiert), den Verifier sicher im Client zu speichern (nicht in der URL oder in Logs), die S256-Methode zu verwenden (nicht plain) und sicherzustellen, dass der Verifier nach dem Token-Austausch verworfen wird. Die meisten modernen OAuth-Bibliotheken übernehmen PKCE automatisch.

Welche Beziehung besteht bei PKCE zwischen dem Code-Verifier und der Code-Challenge?

PKCE (RFC 7636) verhindert das Abfangen von Autorisierungscodes, indem jeder Code an einen dynamisch generierten Code-Verifier gebunden wird, der nur dem legitimen Client bekannt ist. Der Verifier wird gehasht, um die Code-Challenge zu erzeugen, die öffentlich übertragen wird. Für den Token-Austausch ist der ursprüngliche Verifier erforderlich. PKCE verhindert sowohl das Abfangen als auch die Injektion von Codes. OAuth 2.1 schreibt PKCE für alle Authorization-Code-Flows vor.