Erklärung des Begriffs: Proof Key for Code Exchange (PKCE)

Begriff Proof Key for Code Exchange
Abkürzung PKCE
Eintrag zuletzt aktualisiert am 22.08.2026

Zur Stichwortliste unseres Lexikons

Was ist Proof Key for Code Exchange ?

Proof Key for Code Exchange (PKCE) ist eine Erweiterung von OAuth 2.0 Authorization Code Flow, die verhindert, dass ein abgefangener Authorization Code von einem Angreifer verwendet werden kann.

PKCE wird besonders bei Public Clients eingesetzt, also Anwendungen, die kein Client Secret sicher geheim halten können, etwa:
  • Desktop-Anwendungen
  • Mobile Apps
  • Single-Page Applications (SPA)
Heute wird PKCE generell für den Authorization Code Flow empfohlen.

Grundidee

Der Client erzeugt vor Beginn des Login-Vorgangs einen zufälligen geheimen Wert:

code_verifier

Beispielsweise:

dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Daraus berechnet er einen Hash:

codechallenge = BASE64URL(SHA256(codeverifier))

Der code_verifier bleibt zunächst nur beim Client.

Der Ablauf sieht dann vereinfacht so aus:

Client Authorization Server
| |

|--- Authorization Request

>|
| code_challenge |
| codechallengemethod=S256 |
| |

|<--- Authorization Code

|
| |

|--- Token Request

>|
| code
| code_verifier |
| |
| SHA256(code_verifier)
| == code_challenge ?
| |

|<--- Access Token

|

Schritt 1: code_verifier erzeugen

Der Client erzeugt eine kryptografisch zufällige Zeichenfolge:

code_verifier = zufälliger geheimer Wert

Wichtig ist: Dieser Wert wird nicht beim ersten Request an den Authorization Server übertragen.

Schritt 2: code_challenge berechnen

Üblicherweise wird die Methode S256 verwendet:

code_challenge =
BASE64URL(SHA256(ASCII(code_verifier)))

Der Client sendet dann beispielsweise:

GET /authorize?
response_type=code&
client_id=myclient&
redirect_uri=client.example/callback&
code_challenge=abc123...&
codechallengemethod=S256

Der Authorization Server merkt sich die code_challenge.

Schritt 3: Authorization Code erhalten

Nach erfolgreicher Anmeldung wird der Browser zurück zum Client geleitet:

client.example/callback?code=XYZ

Ein Angreifer könnte theoretisch diesen Code abfangen.

Genau dieses Problem adressiert PKCE.

Schritt 4: Code gegen Token tauschen

Der Client sendet anschließend:

POST /token

mit beispielsweise:

granttype=authorizationcode
code=XYZ
client_id=myclient
redirect_uri=client.example/callback
code_verifier=dBjftJeZ4CVP...

Der Authorization Server berechnet erneut:

BASE64URL(SHA256(code_verifier))

und vergleicht das Ergebnis mit der beim Authorization Request gespeicherten:

code_challenge

Nur wenn beide zusammenpassen, wird das Token ausgegeben.

Warum schützt das?

Angenommen, ein Angreifer bekommt den Authorization Code:

code=XYZ

Er kennt aber nicht:

code_verifier

Damit kann er beim Token Endpoint zwar Folgendes versuchen:

code=XYZ

aber er kann keinen passenden

code_verifier

mitsenden.

Der Authorization Server verweigert deshalb das Access Token.

PKCE bindet also vereinfacht gesagt den Authorization Code an genau den Client, der den OAuth-Vorgang begonnen hat.

Beratung & Support

Schulungen

Anfrage für eine individuelle Schulung zum Thema PROOF KEY FOR CODE EXCHANGE PKCE Gesamter Schulungsthemenkatalog