OAuth-2.0-Authorization-Code-Flow mit PKCE für öffentliche Clients

Worum es geht

Beim Authorization-Code-Grant wird der Browser an den Autorisierungsserver umgeleitet, die nutzende Person stimmt zu, und der Server leitet mit einem kurzlebigen code zurück, den der Client am Token-Endpunkt gegen Tokens eintauscht. Ein vertraulicher Client authentifiziert diesen Austausch mit seinem Client-Secret; ein öffentlicher Client hat keines, sodass ein gestohlener Code von jeder Seite eingelöst werden könnte. RFC 7636 (zitiert) schliesst diese Lücke: Der Client erzeugt einen code_verifier, eine zufällige Zeichenkette aus 43 bis 128 nicht reservierten Zeichen, sendet code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) mit code_challenge_method=S256 in der Autorisierungsanfrage und sendet den code_verifier im Klartext zusammen mit dem Code am Token-Endpunkt. Der Server berechnet den Hash erneut und verweigert die Anfrage bei einer Abweichung. Die RFC hält fest, dass ein zu S256 fähiger Client dieses verwenden muss; die Methode plain existiert nur für eingeschränkte Clients.

Warum es wichtig ist

RFC 8252 (zitiert) verlangt von öffentlichen nativen App-Clients, PKCE zu implementieren, und von Autorisierungsservern, es zu unterstützen, und fordert native Apps auf, den System-Browser statt einer eingebetteten Web-View zu verwenden. RFC 9700 (zitiert), die aktuelle Best-Practice-Empfehlung für OAuth-Sicherheit, erweitert die Anforderung: Öffentliche Clients müssen PKCE verwenden, vertraulichen Clients wird es empfohlen, Clients sollten die Implicit-Grant-Variante nicht verwenden (Tokens im URL-Fragment lecken über Verlauf und Referrer), Refresh-Tokens für öffentliche Clients müssen sender-gebunden oder rotiert werden, und Redirect-URIs müssen durch exakten String-Vergleich verglichen werden (Ausnahme beim Port für Localhost bei nativen Apps). PKCE schützt zudem vor Authorization-Code-Injection, bei der Angreifende einen anderswo erlangten Code in die Sitzung der geschädigten Person einschleusen.

So wird es angewendet

• Den Verifier bei jeder Autorisierungsanfrage mit einer kryptografisch sicheren Zufallsquelle erzeugen; ihn zusammen mit dem state-Wert an einem an den User Agent gebundenen Ort speichern (Session Storage bei einer Browser-App, Prozessspeicher bei einer CLI).
• Exakte Redirect-URIs registrieren. Für eine native, CLI- oder Desktop-App beschreibt RFC 8252 drei Wege, die Antwort zu empfangen: ein URI-Schema für den privaten Gebrauch, eine beanspruchte https-URI oder eine Loopback-Weiterleitung (http://127.0.0.1:<port>/).
• state bei der Rückkehr prüfen, den Code genau einmal eintauschen und den Verifier verwerfen.
• Nur den minimal nötigen scope anfragen, Access-Tokens kurzlebig halten und Refresh-Token-Rotation verwenden, damit ein durchgesickertes Refresh-Token bei erneuter Verwendung erkannt wird.
• Eine gepflegte Client-Bibliothek verwenden; der Ablauf hat mehr Randfälle (Mix-up, Downgrade der code_challenge_method), als in handgeschriebenem Code Platz finden.

Stolpersteine

code_challenge zu senden, aber dem Server zu erlauben, Token-Anfragen auch ohne Verifier zu akzeptieren (ein Downgrade, das der BCP beschreibt). Einen Verifier über mehrere Anfragen hinweg wiederzuverwenden. Refresh-Tokens im localStorage einer Seite zu speichern, die auch Drittanbieter-Skripte ausführt. Ein Access-Token als Identitätsnachweis zu behandeln; dafür sind OpenID-Connect-ID-Tokens da.

Single-Page-Anwendungen: ein Backend for Frontend vorziehen

Eine Browser-Anwendung mit einem eigenen Server muss kein öffentlicher Client sein. RFC 10017 (BCP 212, 'OAuth 2.0 for Browser-Based Applications') beschreibt die Backend-for-Frontend-Architektur, bei der ein kleines Backend den Authorization-Code-Flow als vertraulicher Client durchführt (weiterhin mit PKCE), Access- und Refresh-Tokens serverseitig hält und dem Browser nur ein Same-Site-Session-Cookie gibt; der BCP empfiehlt dies nachdrücklich für Geschäftsanwendungen, sensible Anwendungen und Anwendungen, die Personendaten verarbeiten, weil in die Seite eingeschleuster Code andernfalls jedes Token, das der Browser hält, verwenden oder exfiltrieren kann. Den oben beschriebenen browserinternen Ablauf nur dann verwenden, wenn kein Backend zur Verfügung steht, das die Tokens hält, und sie dann im Speicher halten statt im Web Storage.