OAuth-Debugger

Proof Key for Code Exchange (PKCE, RFC 7636) wurde ursprünglich für mobile und native Apps entwickelt, die kein Client-Secret sicher speichern können. Dabei generiert der Client einen zufälligen code_verifier, leitet daraus eine code_challenge ab (SHA-256 + base64url) und sendet die Challenge mit der Autorisierungsanfrage. Beim Austausch des Autorisierungscodes gegen Tokens sendet der Client den ursprünglichen code_verifier. Der Autorisierungsserver überprüft, ob er mit der früheren Challenge übereinstimmt — und beweist so, dass die Token-Anfrage vom selben Client stammt, der den Flow gestartet hat.

Selbst für vertrauliche Clients (serverseitige Apps mit einem Client-Secret) wird PKCE inzwischen von OAuth 2.1 als Schutz gegen Interception-Angriffe auf Autorisierungscodes empfohlen.

Der Implicit Flow (response_type=token) wurde als Abkürzung für Single-Page-Apps konzipiert und gibt das Access Token direkt im URL-Fragment zurück. Das verursacht ernste Probleme: Tokens in URLs erscheinen im Browserverlauf, in Server-Logs und in Referrer-Headern, und der Flow ist anfällig für Token-Injection-Angriffe. OAuth 2.0 Security Best Current Practice (RFC 9700) und OAuth 2.1 entfernen den Implicit Flow explizit zugunsten von Authorization Code + PKCE, das SPAs sicher ohne Client-Secret verwenden können.

• PKCE erforderlich für alle Authorization-Code-Flows, einschließlich vertraulicher Clients.
• Implicit Flow entfernt — verwenden Sie stattdessen Authorization Code + PKCE.
• Resource Owner Password Credentials (ROPC) entfernt — der password-Grant-Type ist veraltet.
• Refresh-Token-Rotation erforderlich für öffentliche Clients — bei jeder Verwendung muss ein neues Refresh-Token ausgestellt werden.
• Exakte Redirect-URI-Übereinstimmung erforderlich — kein Pattern-Matching oder Wildcards.

1. PKCE-Paar generieren: Erstellen Sie einen zufälligen code_verifier und berechnen Sie code_challenge = BASE64URL(SHA256(code_verifier)).
2. Weiterleitung zum Authorization-Endpunkt: Fügen Sie response_type=code, client_id, redirect_uri, scope, state, code_challenge und code_challenge_method=S256 hinzu.
3. Der Benutzer authentifiziert sich beim Autorisierungsserver und erteilt seine Zustimmung.
4. Empfang des Autorisierungscodes an Ihrer redirect_uri zusammen mit dem zurückgegebenen state — überprüfen Sie, ob state mit dem gesendeten Wert übereinstimmt.
5. Code gegen Tokens tauschen: POST an den Token-Endpunkt mit grant_type=authorization_code, code, redirect_uri, client_id und code_verifier.
6. Empfang des Access Tokens (und optional id_token und refresh_token) und Verwendung zum Aufrufen von APIs.