OAuth 2.0 PCKE – Proof Key for Code-Exchange
Neben den je nach Anwendungsfall unterschiedlichen OAuth 2.0 Grant-Typen wie authorization code, implicit oder auch password credential können auch eigene Erweiterungen in das Protokoll integriert werden. Ein Beispiel hierfür ist die Sicherheits-Erweiterung PKCE (Proof Key for Code Exchange). Sie ermöglicht eine spezielle Technik, mit der sich vor allem „öffentliche“ Clients wie eine mobile App dahingehend absichern können, dass ein zu übertragender Autorisierungscode nicht ohne weiteres abgefangen und missbraucht werden kann.
Die Kernfunktion von PKCE besteht darin, dass der Client zuerst einen geheimen Schlüssel (secret = Geheimnis) erstellt und diesen dann bei der Anwendung auf ein Zugriffstoken erneut verwendet. Damit kann sichergestellt werden, dass selbst bei einem Angriff und einem Abfangen des Tokens dieses nicht verwendet werden kann, da die Tokenanfrage auf dem Geheimnis beruht.
Wann sollte die PKCE-Erweiterung eingesetzt werden?
Nach dieser kurzen Erklärung und Einführung stellt sich die Frage, in welchen Szenarien die PKCE-Erweiterung optimalerweise eingesetzt werden sollte. Zwei Beispiele sollen den Einsatzbereich darstellen und im Folgenden näher beschreiben:
-
Wann immer Sie einen nativen OAuth 2.0 Client verwenden, sollten Sie auf die OAuth2-Erweiterung PKCE zurückgreifen. Der Client kann dabei als normale Anwendung auf einem gewöhnlichen PC-System liegen oder in Form einer App für ein mobiles Endgerät.
-
Sobald der OAuth 2.0 Client „öffentlich“ ist und daher nicht über gesicherte Anmeldeinformationen für eine Authentifizierung am Token-Endpunkt verfügt, sollten Sie über die Anwendung der PKCE-Erweiterung nachdenken und diese, wenn möglich auch installieren.
Der normale Autorisierungsflow von OAuth 2.0 im Detail
Mit OAuth 2.0 ist es sehr einfach möglich, eine beispielsweise mobile App für den Zugriff auf die API-Endpunkte zu autorisieren. Der folgende Autorisierungsflow bezeichnet dabei einen beispielhaften Kontext mit seinen grundlegenden Funktionen:
-
Wenn Sie eine neue mobile App auf dem Endgerät installieren, registriert sich diese Anwendung beim mobilen Betriebssystem als Handler für spezielle URL-Schemas. Diese könnten beispielsweise nach dem Schema „com.example-mobileapp://“ registriert werden.
-
Nach dem ersten Aufruf der mobilen App wird der Benutzer in der Regel aufgefordert, sich für die weitere Verwendung der App und im Rahmen des Datenaustausches zu authentifizieren.
-
In der Regel startet die mobile App hierfür automatisch den systemeigenen Browser und ruft eine Seite auf dem dafür vorgesehenen AS (Autorisierungs-Server) auf.
-
Auf dem AS wird der Benutzer nun mit einem entsprechenden Dialog empfangen und zur Eingabe seiner Benutzerdaten aufgefordert. Zudem werden in der Regel an dieser Stelle auch spezielle Berechtigungen der App aufgezeigt und der Benutzer zur Freigabe dieser Zugriffe aufgefordert. Die Autorisierung selbst verwendet aufgrund des Einsatzes in einem Browser entweder SSO oder eine 2-Faktoren Autorisierung.
-
Sobald der Benutzer die Autorisierung beendet, wird der AS eine entsprechende URL nach einem zur nativen Anwendung passenden Schema wie beispielsweise „com.example-mobileapp://…oauth?code=a5P3s7z15FF9a558“ erstellen. Danach erfolgt die Anweisung an die mobile App, sich auf dieser gesendeten URL erneut einzuloggen.
-
Der mobile Browser fragt beim Betriebssystem nun die weitere Vorgehensweise zu dieser URL ab und übergibt diese dann an die entsprechende Anwendung.
-
Die native App analysiert nun die übergebene URL und extrahiert den codierten Autorisierungscode für die Authentifizierung.
-
Im nächsten Schritt ruft die native App den AS und übergibt den Autorisierungscode zur Überprüfung weiter.
-
Der AS wiederum validiert nun den Autorisierungscode und erstellt daraus ein (oder mehrere) gültig(e)s Zugriffstoken. Diese werden an die native App zurückgesendet.
-
Die native App am PC oder mobilen Endgerät empfängt dieses validierte Token und legt es im gesicherten Speicher für weitere Zugriffe und Autorisierungen ab.
Die Integration von OAuth 2.0 PKCE im Autorisierungsflow
Derzeit besteht jedoch ein hohes Risiko, dass im oben gezeigten Autorisierungsflow bei den Schritten 6 bis 8 manipulierend eingegriffen werden kann. Dies eröffnet eine Sicherheitslücke und ermöglicht fremden Zugriff auf die Autorisierung. Sofern ein Fremdzugriff stattgefunden hat, wird die Manipulation im Schritt 8 an den AS weitergegeben und damit unerkannt bleiben. Mit der Integration von OAuth 2.0 PKCE wird es einer nativen Anwendung oder App jedoch ermöglicht, ein kurzlebiges Geheimnis (secret) zu erstellen und dem Autorisierungscode hinzuzufügen. Der Autorisierungsflow sieht dann wie folgt aus:
-
Es werden zuerst die Schritte 1 bis 3 im normalen Autorisierungsflow aus dem obigen Beispiel ausgeführt.
-
Wenn die native App die AS-Seite im Browser lädt, wird eine „code_verifier“-Zeichenfolge erstellt und als Parameter an die URL übergeben. Der AS speichert diese Zeichenfolge.
-
Sobald nun die native App den Code für das Zugriffstoken austauscht (siehe Schritt 8 im normalen Autorisierungsflow), enthält dieser erneut die Zeichenfolge. Fehlt nun diese Zeichenfolge oder wurde sie durch einen entsprechenden Fremdzugriff ausgetauscht, so wird der AS das angeforderte Zugriffstoken nicht erstellen und nicht senden.
-
Selbst wenn der Fremdzugriff es schafft, einen Code ohne den „code-verifier“ zu erhalten, kann sie diesen nicht in ein gültiges Zugriffstoken umwandeln.
Zusätzliche Sicherheit mit PKCE
Die OAuth 2.0 Erweiterung PKCE verspricht vor allem für native und mobile Anwendungen eine umfangreiche Sicherheitsverbesserung. Durch den geänderten Autorisierungsflow und das zusätzliche Client-Geheimnis wird das Risiko für manipulierte Zugriffe auf wichtige Privat- oder Geschäftsdaten aktiv verhindert. Die Möglichkeit von PKCE, transiente Clientgeheimnisse in die Tokengenerierung zu integrieren, schützt hoch wirksam gegen Fremdzugriffe und gehackte API-Aufrufe. Der komplette OAuth-PKCE-Flow und dessen detaillierte Anwendung ist in RFC 7636 ausführlich definiert.