![\"Symbol-Bild:](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/12\/202112_OAuth_1-600x400.jpg\")
<\/figure>\n\n\n\nNachteile der klassischen Login-Formulare<\/strong><\/h2>\n\n\n\nDie eingangs beschriebene, klassische Variante der User-Authentifizierung hat einige Nachteile:<\/p>\n\n\n\n
<\/div>\n\n\n\nSecurity<\/strong><\/h3>\n\n\n\nSicherheitskritische Funktionen selbst zu bauen, ist immer mit einem gewissen Risiko verbunden. Bei Passw\u00f6rtern reicht es beispielsweise nicht aus, einfach nur Hash-Werte abzuspeichern. Denn die Passw\u00f6rter m\u00fcssen selbst dann sicher sein, wenn der ung\u00fcnstigste Fall eintritt und die Datenbank in die H\u00e4nde von Hackern gelangt. Daf\u00fcr stehen spezielle Verfahren zur Verf\u00fcgung, jedoch m\u00fcssen diese eben auch richtig implementiert sein. Im Zweifel bietet es sich daher in aller Regel an, lieber auf etablierte und durch Expertinnen und Experten begutachtete freie Produkte zu setzen, als diese selbst nachzubauen. <\/p>\n\n\n\n
<\/div>\n\n\n\nAufwand<\/strong><\/h3>\n\n\n\nMit einer einfachen Login-Maske ist es nicht getan. Auch weitere Prozesse wie Registrierung, Passwort \u00e4ndern, Passwort vergessen usw. m\u00fcssen bedacht und implementiert werden. Und nat\u00fcrlich gibt es auch hier Best Practices, beispielsweise hinsichtlich Usability, die beachtet werden sollten. Der Aufwand, um alle diese Aspekte in hoher Qualit\u00e4t umzusetzen, sollte nicht untersch\u00e4tzt werden. <\/p>\n\n\n\n
<\/div>\n\n\n\nZwei-Faktor-Authentifizierung<\/strong><\/h3>\n\n\n\nUm die Sicherheit weiter zu erh\u00f6hen, sollte den Usern die M\u00f6glichkeit gegeben werden, f\u00fcr den Login einen zweiten Faktor zu benutzen. Das kann z. B. ein Einmal-Code sein, der per SMS versandt oder durch eine Authenticator App generiert wird. Aber auch Hardware Token werden gern benutzt. Die Sicherheit wird dadurch enorm gesteigert, da es nun nicht mehr ausreicht, das Passwort zu erraten. Angreiferinnen und Angreifer m\u00fcssen stattdessen zus\u00e4tzlich im Besitz des Smartphones oder Hardware Token sein. Diese zus\u00e4tzlichen Sicherheitsfeatures selbst zu implementieren, ist aber nicht nur fehleranf\u00e4llig, sondern, siehe vorherigen Punkt, auch aufw\u00e4ndig. <\/p>\n\n\n\n
<\/div>\n\n\n\nZentrale Account-Verwaltung<\/strong><\/h3>\n\n\n\nInsbesondere im Firmenkontext ist es h\u00e4ufig eine wichtige Anforderung, dass die Account-Informationen aus einer zentralen Verwaltung (z. B. LDAP, Active-Directory) genutzt werden k\u00f6nnen. Wenn Mitarbeiterinnen und Mitarbeiter sowieso einen Firmen-Account haben, warum sollten sie dann f\u00fcr jede firmeninterne Anwendung einen zus\u00e4tzlichen Account mit (hoffentlich) individuellen Passwort anlegen? Die M\u00f6glichkeit f\u00fcr Single-Sign-On erh\u00f6ht zus\u00e4tzlich den Nutzerkomfort. Und auch au\u00dferhalb des Firmenkontexts m\u00f6chten viele eben nicht f\u00fcr jede App und jede Webseite einen eigenen Account anlegen und sich die Zugangsdaten merken, sondern nutzen lieber einen zentralen Identit\u00e4ts-Provider.<\/p>\n\n\n\n
<\/div>\n\n\n\n„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\n![\"Schematische](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/09\/202109_OAuth_1-e1632220461477.png\")
Abbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\n![\"Schematische](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/09\/202109_OAuth_2-e1632220499290.png\")
Abbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\n![\"Schematische](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/09\/202109_OAuth_3-e1632220439762.png\")
Abbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Security<\/strong><\/h3>\n\n\n\nSicherheitskritische Funktionen selbst zu bauen, ist immer mit einem gewissen Risiko verbunden. Bei Passw\u00f6rtern reicht es beispielsweise nicht aus, einfach nur Hash-Werte abzuspeichern. Denn die Passw\u00f6rter m\u00fcssen selbst dann sicher sein, wenn der ung\u00fcnstigste Fall eintritt und die Datenbank in die H\u00e4nde von Hackern gelangt. Daf\u00fcr stehen spezielle Verfahren zur Verf\u00fcgung, jedoch m\u00fcssen diese eben auch richtig implementiert sein. Im Zweifel bietet es sich daher in aller Regel an, lieber auf etablierte und durch Expertinnen und Experten begutachtete freie Produkte zu setzen, als diese selbst nachzubauen. <\/p>\n\n\n\n
<\/div>\n\n\n\nAufwand<\/strong><\/h3>\n\n\n\nMit einer einfachen Login-Maske ist es nicht getan. Auch weitere Prozesse wie Registrierung, Passwort \u00e4ndern, Passwort vergessen usw. m\u00fcssen bedacht und implementiert werden. Und nat\u00fcrlich gibt es auch hier Best Practices, beispielsweise hinsichtlich Usability, die beachtet werden sollten. Der Aufwand, um alle diese Aspekte in hoher Qualit\u00e4t umzusetzen, sollte nicht untersch\u00e4tzt werden. <\/p>\n\n\n\n
<\/div>\n\n\n\nZwei-Faktor-Authentifizierung<\/strong><\/h3>\n\n\n\nUm die Sicherheit weiter zu erh\u00f6hen, sollte den Usern die M\u00f6glichkeit gegeben werden, f\u00fcr den Login einen zweiten Faktor zu benutzen. Das kann z. B. ein Einmal-Code sein, der per SMS versandt oder durch eine Authenticator App generiert wird. Aber auch Hardware Token werden gern benutzt. Die Sicherheit wird dadurch enorm gesteigert, da es nun nicht mehr ausreicht, das Passwort zu erraten. Angreiferinnen und Angreifer m\u00fcssen stattdessen zus\u00e4tzlich im Besitz des Smartphones oder Hardware Token sein. Diese zus\u00e4tzlichen Sicherheitsfeatures selbst zu implementieren, ist aber nicht nur fehleranf\u00e4llig, sondern, siehe vorherigen Punkt, auch aufw\u00e4ndig. <\/p>\n\n\n\n
<\/div>\n\n\n\nZentrale Account-Verwaltung<\/strong><\/h3>\n\n\n\nInsbesondere im Firmenkontext ist es h\u00e4ufig eine wichtige Anforderung, dass die Account-Informationen aus einer zentralen Verwaltung (z. B. LDAP, Active-Directory) genutzt werden k\u00f6nnen. Wenn Mitarbeiterinnen und Mitarbeiter sowieso einen Firmen-Account haben, warum sollten sie dann f\u00fcr jede firmeninterne Anwendung einen zus\u00e4tzlichen Account mit (hoffentlich) individuellen Passwort anlegen? Die M\u00f6glichkeit f\u00fcr Single-Sign-On erh\u00f6ht zus\u00e4tzlich den Nutzerkomfort. Und auch au\u00dferhalb des Firmenkontexts m\u00f6chten viele eben nicht f\u00fcr jede App und jede Webseite einen eigenen Account anlegen und sich die Zugangsdaten merken, sondern nutzen lieber einen zentralen Identit\u00e4ts-Provider.<\/p>\n\n\n\n
<\/div>\n\n\n\n„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\nAbbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\nAbbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\nAbbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Aufwand<\/strong><\/h3>\n\n\n\nMit einer einfachen Login-Maske ist es nicht getan. Auch weitere Prozesse wie Registrierung, Passwort \u00e4ndern, Passwort vergessen usw. m\u00fcssen bedacht und implementiert werden. Und nat\u00fcrlich gibt es auch hier Best Practices, beispielsweise hinsichtlich Usability, die beachtet werden sollten. Der Aufwand, um alle diese Aspekte in hoher Qualit\u00e4t umzusetzen, sollte nicht untersch\u00e4tzt werden. <\/p>\n\n\n\n
<\/div>\n\n\n\nZwei-Faktor-Authentifizierung<\/strong><\/h3>\n\n\n\nUm die Sicherheit weiter zu erh\u00f6hen, sollte den Usern die M\u00f6glichkeit gegeben werden, f\u00fcr den Login einen zweiten Faktor zu benutzen. Das kann z. B. ein Einmal-Code sein, der per SMS versandt oder durch eine Authenticator App generiert wird. Aber auch Hardware Token werden gern benutzt. Die Sicherheit wird dadurch enorm gesteigert, da es nun nicht mehr ausreicht, das Passwort zu erraten. Angreiferinnen und Angreifer m\u00fcssen stattdessen zus\u00e4tzlich im Besitz des Smartphones oder Hardware Token sein. Diese zus\u00e4tzlichen Sicherheitsfeatures selbst zu implementieren, ist aber nicht nur fehleranf\u00e4llig, sondern, siehe vorherigen Punkt, auch aufw\u00e4ndig. <\/p>\n\n\n\n
<\/div>\n\n\n\nZentrale Account-Verwaltung<\/strong><\/h3>\n\n\n\nInsbesondere im Firmenkontext ist es h\u00e4ufig eine wichtige Anforderung, dass die Account-Informationen aus einer zentralen Verwaltung (z. B. LDAP, Active-Directory) genutzt werden k\u00f6nnen. Wenn Mitarbeiterinnen und Mitarbeiter sowieso einen Firmen-Account haben, warum sollten sie dann f\u00fcr jede firmeninterne Anwendung einen zus\u00e4tzlichen Account mit (hoffentlich) individuellen Passwort anlegen? Die M\u00f6glichkeit f\u00fcr Single-Sign-On erh\u00f6ht zus\u00e4tzlich den Nutzerkomfort. Und auch au\u00dferhalb des Firmenkontexts m\u00f6chten viele eben nicht f\u00fcr jede App und jede Webseite einen eigenen Account anlegen und sich die Zugangsdaten merken, sondern nutzen lieber einen zentralen Identit\u00e4ts-Provider.<\/p>\n\n\n\n
<\/div>\n\n\n\n„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\nAbbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\nAbbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\nAbbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Zwei-Faktor-Authentifizierung<\/strong><\/h3>\n\n\n\nUm die Sicherheit weiter zu erh\u00f6hen, sollte den Usern die M\u00f6glichkeit gegeben werden, f\u00fcr den Login einen zweiten Faktor zu benutzen. Das kann z. B. ein Einmal-Code sein, der per SMS versandt oder durch eine Authenticator App generiert wird. Aber auch Hardware Token werden gern benutzt. Die Sicherheit wird dadurch enorm gesteigert, da es nun nicht mehr ausreicht, das Passwort zu erraten. Angreiferinnen und Angreifer m\u00fcssen stattdessen zus\u00e4tzlich im Besitz des Smartphones oder Hardware Token sein. Diese zus\u00e4tzlichen Sicherheitsfeatures selbst zu implementieren, ist aber nicht nur fehleranf\u00e4llig, sondern, siehe vorherigen Punkt, auch aufw\u00e4ndig. <\/p>\n\n\n\n
<\/div>\n\n\n\nZentrale Account-Verwaltung<\/strong><\/h3>\n\n\n\nInsbesondere im Firmenkontext ist es h\u00e4ufig eine wichtige Anforderung, dass die Account-Informationen aus einer zentralen Verwaltung (z. B. LDAP, Active-Directory) genutzt werden k\u00f6nnen. Wenn Mitarbeiterinnen und Mitarbeiter sowieso einen Firmen-Account haben, warum sollten sie dann f\u00fcr jede firmeninterne Anwendung einen zus\u00e4tzlichen Account mit (hoffentlich) individuellen Passwort anlegen? Die M\u00f6glichkeit f\u00fcr Single-Sign-On erh\u00f6ht zus\u00e4tzlich den Nutzerkomfort. Und auch au\u00dferhalb des Firmenkontexts m\u00f6chten viele eben nicht f\u00fcr jede App und jede Webseite einen eigenen Account anlegen und sich die Zugangsdaten merken, sondern nutzen lieber einen zentralen Identit\u00e4ts-Provider.<\/p>\n\n\n\n
<\/div>\n\n\n\n„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\nAbbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\nAbbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\nAbbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Zentrale Account-Verwaltung<\/strong><\/h3>\n\n\n\nInsbesondere im Firmenkontext ist es h\u00e4ufig eine wichtige Anforderung, dass die Account-Informationen aus einer zentralen Verwaltung (z. B. LDAP, Active-Directory) genutzt werden k\u00f6nnen. Wenn Mitarbeiterinnen und Mitarbeiter sowieso einen Firmen-Account haben, warum sollten sie dann f\u00fcr jede firmeninterne Anwendung einen zus\u00e4tzlichen Account mit (hoffentlich) individuellen Passwort anlegen? Die M\u00f6glichkeit f\u00fcr Single-Sign-On erh\u00f6ht zus\u00e4tzlich den Nutzerkomfort. Und auch au\u00dferhalb des Firmenkontexts m\u00f6chten viele eben nicht f\u00fcr jede App und jede Webseite einen eigenen Account anlegen und sich die Zugangsdaten merken, sondern nutzen lieber einen zentralen Identit\u00e4ts-Provider.<\/p>\n\n\n\n
<\/div>\n\n\n\n„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\nAbbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\nAbbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\nAbbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
„OAuth“ und „OpenID Connect“ als L\u00f6sungsansatz<\/strong><\/strong><\/h2>\n\n\n\nMit den Protokollen „OAuth“<\/strong> und „OpenID Connect“<\/strong> stehen zwei Protokolle bereit, die genau f\u00fcr diesen Zweck entwickelt wurden.<\/p>\n\n\n\nDie tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\nStattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein.
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\n
Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
<\/div>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\nDie OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n
Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\nAbbildung 1: Implicit Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDer Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n
Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\nDas Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\nAbbildung 2: Authorization Code Flow<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nDas Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\nEigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n
<\/div>\n\n\n\nAuthorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\nPKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n
Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n
Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\nAbbildung 3: Authorization Code Flow mit PKCE<\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nBeim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n
Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n
Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n
<\/div>\n\n\n\nPKCE im Detail <\/h2>\n\n\n\n
Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Code Verifier und Code Challenge <\/li><\/ol>\n\n\n\n
Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n<\/div>\n\n\n\nIn diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n
Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n- Request Token <\/li><\/ol>\n\n\n\n
Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n<\/div>\n\n\n\nDem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n
Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n- Login und Redirect <\/li><\/ol>\n\n\n\n
Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n
Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n<\/div>\n\n\n\nDer Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n
Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n<\/div>\n\n\n\n- Exchange Code for Access Token <\/li><\/ol>\n\n\n\n
Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n<\/div>\n\n\n\nAls Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n<\/div>\n\n\n\nWir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Die tats\u00e4chliche Implementierung dieser Standards stellt in der Praxis dann aber meist doch eine gewisse H\u00fcrde dar, insbesondere wenn man das erste Mal mit diesen Verfahren in Ber\u00fchrung kommt. Dies liegt einerseits daran, dass die Abl\u00e4ufe eben doch etwas komplexer sind als ein simpler Abgleich mit einem gespeicherten Passwort-Hash. Ein anderer Grund d\u00fcrfte sein, dass die Standards mehrere Varianten (sogenannte Flows) vorsehen, die in unterschiedlichen Situationen zum Einsatz kommen. Als Neuling steht man schnell vor der Frage, welche Variante f\u00fcr die eigene Anwendung die beste ist und wie es dann ganz konkret umzusetzen ist. Die Antwort auf diese Frage ist insbesondere von der Art der Anwendung abh\u00e4ngig, d. h. ob es sich z. B. um eine native Mobile-App, eine klassische serverseitig gerenderte Web-Anwendung oder eine Single-Page-App handelt.<\/p>\n\n\n\n
In diesem Artikel wollen wir nicht zu sehr in die Tiefe der beiden Protokolle gehen (wer mehr \u00fcber OAuth und OpenID Connect lernen m\u00f6chte, dem sei dieser sehr gute Vortrag auf Youtube empfohlen: https:\/\/www.youtube.com\/watch?v=996OiexHze0<\/a>).<\/p>\n\n\n\n Stattdessen wollen wir einen konkreten Anwendungsfall herausgreifen, der bei uns in Projekten relativ h\u00e4ufig vorkommt: Wir bauen eine Single-Page-App (SPA), die statisch ausgeliefert wird. Das hei\u00dft, dass sich auf dem Server keine Frontend-Logik befindet, sondern lediglich JavaScript- und HTML-Dateien bereitgestellt werden. Stattdessen stellt der Server lediglich eine API zur Benutzung durch die SPA (und andere Clients) bereit, mit der sich Daten holen und Operationen ausf\u00fchren lassen. Diese API k\u00f6nnte mittels REST oder GraphQL implementiert sein. Das spannende an dieser Konstellation ist, dass anders als bei einem serverseitig verarbeiteten Web-Frontend, die Authentifizierung zun\u00e4chst au\u00dferhalb der Einflusssph\u00e4re des Servers stattfindet (n\u00e4mlich rein clientseitig in der SPA bzw. im Browser des Nutzers). Die SPA muss anschlie\u00dfend aber Requests gegen die Server-API absenden, wobei der Server der Glaubw\u00fcrdigkeit der Requests zun\u00e4chst mal misstrauen und die Authentifizierung nochmal selbstst\u00e4ndig \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n Die OAuth-Spezifikation gibt mehrere Flows vor, f\u00fcr unseren Zweck wollen wir uns aber nur zwei genauer anschauen: Den sogenannten „Implicit Flow“ und den „Authorization Code Flow“. Letztlich geht es bei beiden Varianten darum, dass der Auth Provider der Anwendung einen sogenannten „Access Token“ ausstellt, den die Anwendung anschlie\u00dfend bei allen Requests an den API-Server mitschickt. Der API-Server wiederum kann anhand des Access Token die Authentizit\u00e4t des Requests feststellen. Die Flows unterscheiden sich lediglich darin, wie genau die Ausstellung des Access Token vonstattengeht. <\/p>\n\n\n\n Der Implicit Flow<\/strong> war jahrelang die Empfehlung f\u00fcr den Einsatz in JavaScript-Anwendungen im Browser. Zun\u00e4chst leitet die Anwendung den User auf eine Login-Seite des Auth-Providers weiter. Nach erfolgtem Login leitet der Auth-Provider den Browser wieder auf die urspr\u00fcngliche Seite zur\u00fcck und \u00fcbergibt der Anwendung den Access Token als Teil der Response. Genau hier liegen aber auch die Probleme bei dieser Variante. \u00dcber verschiedene Wege ist es f\u00fcr einen Angreifer oder eine Angreiferin m\u00f6glich, an den Access Token zu gelangen, beispielsweise indem die Redirects manipuliert werden und damit der Access Token nicht mehr an die eigentliche App, sondern an den Angreifer oder die Angreiferin geschickt wird. <\/p>\n\n\n\n Der Implicit Flow war von Anfang an eine Notl\u00f6sung f\u00fcr JavaScript-Anwendungen im Browser. Zum Zeitpunkt der Standardisierung gab es f\u00fcr Browser-Scripts keine M\u00f6glichkeit, Requests auf andere Server als den eigenen auszuf\u00fchren (sogenannte Same-Origin-Policy). Damit war die Ausf\u00fchrung des eigentlich besseren Authorization Code Flow nicht m\u00f6glich. In der Zwischenzeit wurde mit dem sogenannten CORS-Mechanismus (f\u00fcr Cross-Origin Resource Sharing) ein System eingef\u00fchrt, welches genau diese L\u00fccke schlie\u00dft und Requests auch auf andere Server erm\u00f6glicht, sofern diese den Zugriff erlauben.<\/p>\n\n\n\n Beim Authorization Code Flow<\/strong> findet ebenfalls ein Redirect auf die Login-Seite des Auth Providers statt. Anstelle eines Access Token schickt der Auth Provider aber lediglich einen sogenannten „Authorization Code“ an den Client. In einem separaten Request muss dieser Authorization Code zusammen mit der „Client ID“ und dem „Client Secret“ an den Auth Provider geschickt und gegen das Access Token eingetauscht werden. Die Client-ID kennzeichnet den Client (in unserem Fall die Single-Page-App) und erm\u00f6glicht dem Auth-Server, f\u00fcr verschiedene Clients verschiedene Regeln anzuwenden. Die Client-ID ist im Prinzip \u00f6ffentlich bekannt und taucht bei einigen Apps\/Diensten als Teil der URL auf.<\/p>\n\n\n\n Das Client Secret dagegen ist ein geheimer Code, den nur dieser eine Client verwenden darf, um sich gegen\u00fcber dem Auth Server auszuweisen (wir kommen gleich noch einmal darauf zur\u00fcck). Der entscheidende Punkt ist hier, dass dieser zweite Request nicht als GET-Request sondern als POST-Request implementiert wird. Damit sind die \u00fcbermittelten Informationen nicht Teil der URL und sind mittels HTTPS (welches selbstverst\u00e4ndlich verwendet werden muss) vor den Blicken von Hackern gesch\u00fctzt.<\/p>\n\n\n\n Eigentlich ist dieser Flow aber vor allem f\u00fcr serverseitig gerenderte Web-Anwendungen gedacht, so dass der Austausch des Authorization Codes gegen den Access Token auf dem Server stattfindet. In dem Fall kann insbesondere das Client Secret auf der Serverseite verbleiben und muss nicht an den Browser \u00fcbermittelt werden. Bei Single-Page-Apps muss aber der gesamte Prozess im Browser stattfinden und daher ben\u00f6tigt die App auch das Client Secret. Die Schwierigkeit ist somit, das Client Secret „geheim“ zu halten. In der Praxis stellt sich dies als praktisch unm\u00f6glich heraus, denn letztlich muss das Client Secret als Teil des Anwendungscodes gebundelt und an den Browser ausgeliefert werden. Das Bundling bei modernen SPA-Frameworks produziert zwar unlesbaren JavaScript-Code, aber es bleibt eben JavaScript und ein Angreifer oder eine Angreiferin k\u00f6nnte sich diesen Code anschauen, das Client Secret extrahieren und damit die Anwendung kompromittieren. Die L\u00f6sung hierf\u00fcr lautet „PKCE“. <\/p>\n\n\n\n PKCE steht f\u00fcr „Proof Key for Code Exchange“ und ist eine Erweiterung des Authorization Code Flows. Hierbei wird auf das statische Client Secret verzichtet und stattdessen im Prinzip bei jedem Authentifizierungsvorgang ein neues Secret dynamisch generiert.<\/p>\n\n\n\n Dazu wird ganz am Anfang ein sogenannter „Code Verifier“ generiert. Dabei handelt es sich um eine Zeichenkette aus Zufallszahlen. Aus dem Code Verifier wird die „Code Challenge“ berechnet, in dem der Code Verifier mit dem Hash-Verfahren SHA256 gehasht wird.<\/p>\n\n\n\n Beim initialen Login-Vorgang zum Anfragen des Authorization Codes schickt die Anwendung die Code Challenge mit zum Auth Provider. Der Auth Provider merkt sich die Code Challenge und antwortet wie bisher mit dem Authorization Code.<\/p>\n\n\n\n Beim anschlie\u00dfenden Request f\u00fcr den Austausch des Authorization Codes gegen den Access Token schickt der Client nun den Code Verifier mit. Der Auth Provider kann nun pr\u00fcfen, ob der Code Verifier und die Code Challenge zusammenpassen, indem er seinerseits das Hashing mit SHA256 durchf\u00fchrt.<\/p>\n\n\n\n Ein Angreifer kann bei diesem Verfahren nicht mehr das Client Secret extrahieren, da kein solches Client Secret mehr existiert. Von au\u00dfen k\u00f6nnte ein Angreifer oder eine Angreiferin h\u00f6chstens die Code Challenge abgreifen, da diese beim initialen Request \u00fcber einen Browser Redirect an den Auth Provider \u00fcbermittelt wird. Der Angreifer oder die Angreiferin hat aber keine Kenntnis vom Code Verifier und kann diesen auch nicht anhand der Code Challenge ableiten. Ohne den Code Verifier stellt der Auth Provider aber kein Access Token aus, womit ein Angreifer oder eine Angreiferin erfolgreich ausgesperrt ist.<\/p>\n\n\n\n Urspr\u00fcnglich wurde das PKCE-Verfahren vor allem f\u00fcr native Mobile-Apps entwickelt, es lassen sich damit aber auch im Quellcode \u00f6ffentlich einsehbare Single-Page-Apps sicher umsetzen. Und nicht nur das: Mittlerweile wird das Verfahren sogar f\u00fcr weitere Anwendungsarten wie serverseitige Anwendungen empfohlen, f\u00fcr die bisher der normale Authorization Code Flow mit Client Secret vorgesehen war.<\/p>\n\n\n\n Da der Authorization Code Flow mit PKCE das Mittel der Wahl f\u00fcr Single-Page-Apps ist, wollen wir die einzelnen Schritte etwas genauer anschauen.<\/p>\n\n\n\n Zun\u00e4chst wird der Code Verifier und die Code Challenge berechnet: <\/p>\n\n\n\n In diesem und den folgenden Beispielen verwende ich verk\u00fcrzte Zufallswerte, um die einzelnen Schritte und Parameter besser darstellen zu k\u00f6nnen. In einer realen Anwendung m\u00fcssen hier nat\u00fcrlich echte Zufallswerte generiert werden.<\/p>\n\n\n\n Zufallswerte im Security-Kontext sind aber ein eigenes Thema f\u00fcr sich und daher wollen wir an dieser Stelle nicht im Detail darauf eingehen, wie genau der Code Verifier generiert wird. Als Stichwort sei aber die relativ neue Web-Crypto-API<\/a> genannt, die unter anderem Funktionen zur Generierung von sicheren Zufallszahlen bereitstellt. Auch f\u00fcr das Hashing mittels SHA256 stellt die Web-Crypto-API die richtigen Hilfsmittel<\/a> bereit. <\/p>\n\n\n\n Nun wird ein Redirect bzw. GET-Request ausgef\u00fchrt, um den Authorization Code zu erhalten: <\/p>\n\n\n\n Dem Request werden die Code Challenge und die Methode, die zum Berechnen der Code Challenge benutzt wurde (in unserem Fall also SHA256), mitgegeben. <\/p>\n\n\n\n Zus\u00e4tzlich wird noch ein sogenannter „State“-Parameter mitgegeben, der ebenfalls aus einem Zufallswert besteht. Auf diesen werden wir gleich noch genauer eingehen.<\/p>\n\n\n\n Der Browser wird zur Login-Seite beim Auth Provider weitergeleitet, auf der sich die User einloggen und die App autorisieren k\u00f6nnen. Anschlie\u00dfend leitet der Auth Provider wieder zur App zur\u00fcck und nutzt daf\u00fcr den beim ersten Request \u00fcbergebenen „request_uri“-Parameter. In der Regel konfiguriert man im Auth Provider eine oder mehrere g\u00fcltige Redirect-URIs, um zu verhindern, dass ein Angreifer oder eine Angreiferin den Request manipuliert und eine gef\u00e4lschte Redirect-URI unterschieben will.<\/p>\n\n\n\n Die Redirect-URI muss nat\u00fcrlich im Router der Single-Page-App konfiguriert sein und dort die Parameter entgegennehmen, die der Auth Provider dem Client mitteilen m\u00f6chte. Der Request dazu sieht in etwa so aus: <\/p>\n\n\n\n Der Authorization Code ist ein Token, den wir im n\u00e4chsten Schritt gegen den eigentlichen Access Token eintauschen wollen (auch hier nochmal der Hinweis, dass ich zur vereinfachten Darstellung hier ausgedachte und verk\u00fcrzte Zufallswerte benutze. Ein echter Authorization Code sieht anders aus).<\/p>\n\n\n\n Au\u00dferdem taucht wieder der State-Parameter auf. Diesen haben wir im vorherigen Schritt als Zufallswert generiert und dem Auth Provider mitgeschickt. Der Auth Provider schickt den State unver\u00e4ndert wieder zur\u00fcck. Auf diese Weise kann unsere Client App herausfinden, ob der Antwort-Request tats\u00e4chlich auf einen eigenen Token Request folgt oder nicht. Sollte ein Angreifer einen Token Request initiiert haben, w\u00e4re der dazugeh\u00f6rige State-Parameter bei der App unbekannt und der Request damit direkt als unsicher entlarvt. Dieses Verfahren sch\u00fctzt insbesondere gegen sogenannte CSRF-Attacken (Cross Site Request Forgery, weitergehende Erkl\u00e4rung u. a. hier: https:\/\/security.stackexchange.com\/questions\/20187\/oauth2-cross-site-request-forgery-and-stateparameter<\/a>).<\/p>\n\n\n\n Nun k\u00f6nnen wir unseren Authorization Code gegen den eigentlichen Access Token austauschen. Dazu starten wir einen POST-Request: <\/p>\n\n\n\n Als Parameter \u00fcbergeben wir u. a. den Authorization Code und den Code Verifier. Als Antwort erhalten wir nun endlich den Access Token, den wir anschlie\u00dfend f\u00fcr Requests gegen den API-Server verwenden k\u00f6nnen. Die Antwort sieht in etwa so aus: <\/p>\n\n\n\n Wir erhalten den Access Token und einige weitere Informationen zum Token. <\/p>\n\n\n\n
Wie bei OAuth \u00fcblich, kommt hierbei ein separater Authentication-Service zum Einsatz, wir wollen daher die Benutzerverwaltung nicht selbst implementieren. Dies k\u00f6nnte z. B. ein Cloud-Anbieter sein oder eine selbst gehostete Software, beispielsweise der freie Open-Source-Authentication-Server „Keycloak“. Wichtig ist lediglich, dass der Authentication-Dienst OAuth2\/OpenID Connect „spricht“.<\/p>\n\n\n\nArbeiten mit OAuth: Implicit Flow und Authorization Code Flow<\/strong><\/h2>\n\n\n\n
Das Problem mit der browserbasierten Single-Page-App<\/strong><\/h2>\n\n\n\n
Authorization Code Flow mit PKCE<\/strong><\/strong><\/h2>\n\n\n\n
PKCE im Detail <\/h2>\n\n\n\n
const code_verifier = \"fkljl34l5jksdlf\" \/\/ generate random string\nconst code_challenge = sha256(code_verifier)<\/pre>\n\n\n\n
GET <auth-server>\/openid-connect\/auth?\n& response_type=code\n& client_id=oauth-demo\n& scope=openid\n& state=hkjshkdwe\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_challenge=shkjhek34hk2lhkds\n& code_challenge_method=S256<\/pre>\n\n\n\n
https:\/\/<app-url>\/callback?\n& code=jehrejkjhsad223ndskj2\n& state=hkjshkdwe<\/pre>\n\n\n\n
POST <auth-server>\/openid-connect\/auth\/token?\n& grant_type=authorization_code\n& code=jehrejkjhsad223ndskj2\n& client_id=oauth-demo\n& redirect_uri=https:\/\/<app-url>\/callback\n& code_verifier=fkljl34l5jksdlf<\/pre>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Type: application\/json\n{\n\"access_token\": \"<jwt token>\",\n\"token_type\": \"bearer\",\n\"expires_in\": 3600,\n\"refresh_token\": \"<jwt token>\",\n\"scope\": \"tasks\"\n}<\/pre>\n\n\n\n