Authentifizierung und Autorisierung (Martina Kraus)

Martina Was mir persönlich immer geholfen hat, ist, wenn ich auch verstanden habe, wie die Dinge im Hintergrund funktionieren. Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja, du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach, jetzt, um im OAuth-Kontext zu bleiben, den Authorization Code Flow mit PKCE verwenden. Dann bist du sicher. Damit habe ich irgendwie immer Probleme, weil ich irgendwie gerne auch wissen würde, warum denn? Also warum ist das jetzt wichtig, dass ich diese Erweiterung nutze? Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch zu schreiben und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level als dann auch sehr detailreich geschafft, um halt klarzumachen, wie die ganzen sogenannten Flows, wie die halt genau funktionieren.

Ali Hallo und herzlich willkommen zu Klüger als gestern. Mein Name ist Ali Hackalife, das ist ein Rheinwerk-Podcast und heute darf ich mit Martina Kraus sprechen. Sie hat ein Buch geschrieben über Authentifizierung und Autorisierung, was dahinter steckt und was es da zu lernen gibt, das besprechen wir heute. Hallo Martina.

Martina Hallo, ja, danke für die Einladung, ich freue mich sehr.

Ali Wie kommt es, dass du ein Buch zu diesem Thema schreibst, bei dem ich am Anfang gedacht habe, wie füllt man dazu so viele Seiten? Ich habe dein Buch gelesen, ich verstehe, wie man dazu so viele Seiten füllt, aber wie bist du zu IT-Security und diesem speziellen Thema gekommen?

Martina Ja, tatsächlich, seit Beginn habe ich mich generell für Security interessiert, habe dann auch Informatik studiert, bin dann in die Web-Entwicklung letztendlich reingekommen und darüber dann auch in das ganze Thema Web-Security. Und da hat sich schon ein bisschen herausgestellt, dass mich das ganze Thema Authentifizierung, Autorisierung, vor allem weil es erstmal so komplex erscheint, mich wahnsinnig interessiert und ich liebe es tatsächlich nichts mehr als komplexe Themen so einfach wie möglich darzustellen, damit sie auch jeder und jede verstehen kann. Und so bin ich auch mal dabei gelandet, für einen führenden Identity Provider, der das Ganze also auch wirklich implementiert, zu arbeiten und konnte da halt mein Wissen rund um Authentifizierung und Autorisierung zu vertiefen. Und ja, und umso mehr hat es mich dann gefreut, als ich gefragt wurde, ob ich mein Wissen auch in ein Buch teilen darf. Und da habe ich natürlich sofort Ja gesagt.

Ali Ich habe dein Buch in Vorbereitung auf die Sendung gelesen und ich hatte so grob im Hinterkopf, also ich bin IT-Autodidakt, ich mache das auch irgendwie seit 15 Jahren mittlerweile und ich hatte im Kopf, ja, es gibt da was mit Tokens und dann gibt es hier und da einen Handshake und die überprüfen sich gegenseitig. Aber wie das im Detail funktioniert, das war sowas, wo ich immer wusste, wo ich nachschaue, aber es nie nachgeschaut habe. Und du gehst in deinem Buch ja sehr detailreich durch, was überhaupt der Vorteil von verschiedenen Systemen ist, wie zum Beispiel OAuth 2 und dem OpenID Connect System und wo die Anwendung finden. Und ich habe sehr viel darüber verstanden, was im Hintergrund passiert und vor allem was in einer wahnsinnigen Geschwindigkeit im Hintergrund passiert und worüber man ja gar nicht so nachdenkt. Also diese Mechanismen sind ja allgegenwärtig. Und ich habe dann auch nochmal separat ein bisschen in der Historie gegraben und was ich nicht wusste, wie neu das alles ist. Und vor allem OAuth, das erste, ist von Leuten von Ma.gnolia und Twitter zusammen entwickelt worden. Also Twitter war mal wirklich der Innovationsort fürs Internet. Dann stellt sich ja direkt die Frage, ich habe doch einen Benutzernamen und ein Passwort. Wofür brauche ich denn was anderes? Was können Benutzernamen und Passwort nicht, was diese ganzen OAuth-Systeme können?

Martina Einer der größten Herausforderungen, die halt da durch Twitter kam, war die Einbindung von sogenannter Third-Party-Software oder Third-Party-Quellen, also Bilder oder URLs oder Videos von YouTube, von vielleicht Google, vielleicht auch etwas, was den Google-Kalender betroffen hat. Und man musste dann halt Twitter die Berechtigung geben, auf vielleicht meinen Google-Account zuzugreifen, auf mein YouTube-Profil zuzugreifen. Und das hat tatsächlich die Internetwelt vor ganz großen Problemen gestoßen, weil wie macht man das? Ich muss ja irgendwie Twitter jetzt meinen Nutzername und Passwort geben. Klar, dann bin ich in Twitter eingeloggt, aber ich müsste ja jetzt Twitter meinen Nutzername und Passwort geben, damit Twitter sich in meinem Namen jetzt auf YouTube oder irgendeine andere, Webseite, um mal vielleicht Bilder davon zu laden, einloggen zu können. Damit Twitter eben diese Bilder oder Medien anzeigen kann. Also diese Weitergabe von Zugriffsberechtigung. Und da ist dann halt Nutzernamen und Passwörter an ihre Grenzen gestoßen, weil ich finde es persönlich natürlich nicht so cool, wenn ich jetzt Twitter meinen Nutzernamen und Passwort gebe, um vielleicht auf YouTube zugreifen zu können. Und ich weiß ja auch nicht, was Twitter vielleicht mit den Nutzernamen und Passwort macht. Und da hat dann halt sich ganz schnell herausgestellt, wir brauchen irgendetwas, was wir Access Delegation nennen, also die Weitergabe von Zugriffsrechten, dass ich Twitter einfach sagen kann, ja, liebes Twitter, du darfst jetzt genau auf diese Medien zugreifen, und dann darfst du sie anzeigen, aber sonst darfst du auch nichts mehr machen. Also du darfst nicht irgendwelche anderen Bilder laden oder du darfst da nicht in meinem Namen des Google-Accounts auf irgendwelche Inhalte oder meine E-Mails zugreifen, sondern wirklich nur sehr dediziert, um zum Beispiel ein Bild anzuzeigen in Twitter.

Ali Und dieses Weiterleiten von diesen sehr spezifischen Zugriffsrechten, dafür brauche ich dann mehr als Nutzername und Passwort und da kommen dann Tokens beziehungsweise die OAuth Mechanismen zum Greifen?

Martina Absolut richtig, genau. Denn, also da greift mir jetzt schon ein bisschen viel vor, aber quasi, wenn ich mich in so einem Identity Provider einlogge, dann erhalte ich diesen sogenannten Access Token. Und da steht halt ganz genau drin, welche Berechtigungen jetzt dieses Token hat. Das ist auch völlig losgelöst dann letztendlich von dem Nutzer oder Nutzerin. Jeder, der eigentlich dieses Token dann hat, und darf eben auf die APIs, auf die Daten, auf die Services zugreifen mit den Berechtigungen, die eben letztendlich in diesem Token vorhanden sind.

Ali Wer sind solche Identity Provider? Also wer bestätigt, dass das gerade eine echte Identität ist?

Martina Das können zum Beispiel Google sein. Es gibt Google Identity. Wir haben aber auch Entra ID, kennt man wahrscheinlich. Früher hieß das Azure, Microsoft Azure AD. Wir haben aber auch Open Source Lösungen wie zum Beispiel Keycloak. Man kann aber auch ganz verrückt sein und das quasi selbst implementieren. Da bietet zum Beispiel Java Spring Security, die bieten sogar eigene Bibliotheken an, um quasi so einen Identity Provider zu implementieren. Konkret würde ich davon aber abraten, da gibt es einfach zu viel, was man leider falsch machen kann. Ich würde da eher auf sogenannte Identity-as-a-Service-Lösungen, wie sie halt von auch zum Beispiel Auth0 oder Okta oder Entra ID angeboten werden oder zumindest halt so eine, Self-Hosting-Lösung, wie sie zum Beispiel von Keycloak angeboten wird, zurückgreifen.

Ali Das ist ja generell bei Security ein riesiges Thema, wo ich auch in meiner IT-Karriere sehr oft drüber gestolpert bin, dass Leute sagen, die Kryptografie dafür, das machen wir einfach selbst, anstatt diese Library zu benutzen, dann sind wir unabhängig. Und das war in der Regel immer der Schuss in den Fuß. Also es ging danach nie besser, weil es gibt einen Grund, dass sich da große Industriestandards etabliert haben und nicht alle ihre eigene Suppe kochen.

Martina Absolut. Also es betrifft auch hier natürlich nicht nur OAuth oder OpenID Connect, wenn ich auch beispielsweise meine Passwörter hashen möchte. Da gibt es bestehende Algorithmen, also bestehende Hash-Funktionen wie beispielsweise scrypt oder Argon2 und die will ich auch gar nicht selbst implementieren. Da gibt es Leute, Kryptografen, die haben sich darüber Gedanken gemacht, haben dazu mathematische Paper verfasst und sehr clevere Menschen, viel cleverere Menschen als ich es bin definitiv, haben diese Hash-Algorithmen dann auch implementiert.

Ali Ja, um mal einen Begriff in den Raum zu werfen. Bei elliptischer Kryptografie sitze ich immer davor und habe das Gefühl, jemand erzählt mir gerade etwas, das ist so sci-fi, dass ich beeindruckt bin, dass Menschen das können. Aber ich habe großen Respekt davor und ich bin einfach froh, dass ich nur eine Library einbinden muss und das nicht verstehen muss. Aber zum Thema Verstehen. Du sagtest gerade, Passworte hashen. Warum ist in der Moderne, wir haben jetzt das mit dem ein anderer Anbieter möchte, Daten durchleiten können, beziehungsweise Zugriffe minimal gewährleisten, auf spezielle Dinge angerissen. Aber warum reicht es nicht mehr, dass ich sage, ich habe Nutzernamen und Passwort und meinetwegen ist das Passwort noch gehasht. Das heißt, Twitter selbst hat mein Passwort gar nicht im Klartext da liegen oder beliebiger anderer Online-Dienst hat mein Passwort gar nicht mehr im Klartext da liegen. Welche anderen Vorteile bringen mir Möglichkeiten wie OAuth dabei, wenn ich mich mit einer Plattform verbinde oder Plattform untereinander verbinde?

Martina Also, da muss man tatsächlich etwas differenzieren, weil OAuth beschäftigt sich gar nicht so mit der Frage Nutzername, Passwort. OAuth ist per se ein reines Autorisierungsframework. In OAuth ist gar nicht bestimmt, wie sich dieser Nutzer jetzt eigentlich authentifiziert. Also der kann sich dann mit dem Nutzername Passwort authentifizieren, der kann sich mit einem Passkey authentifizieren, mit einem zweiten, dritten, fünften Faktor, wie auch immer. Das ist in OAuth selbst gar nicht beschrieben. Was OAuth letztendlich eigentlich nur beschreibt ist, wie erhält jetzt ein Nutzer oder Nutzerin, nachdem er oder sie sich identifiziert hat, nachdem das quasi geklärt ist, jetzt einen Token, um dann mit diesem Token eben, in dem gewisse Berechtigungen drinstehen, dann letztendlich die richtigen APIs, die richtigen Services aufrufen kann. Und dabei ist ganz klar beschrieben, was halt in diesem Access-Token drinsteht. Dass dieser wirklich nur für eine Teilmenge von Berechtigung oder auch für eine Teilmenge an Services. Ich kann nicht mit dem einen Access-Token jetzt eine Google API aufrufen und mit demselben Access-Token vielleicht dann noch einen anderen Service aufrufen, um gegebenenfalls davon noch Bilder zu laden. Und das ist halt, wie gesagt, ganz streng getrennt voneinander. Und Authentifizierung, wie das Ganze vonstatten geht, darum kümmert sich tatsächlich eigentlich eher dann OpenID Connect.

Ali Jetzt hast du gerade gesagt einen zweiten, dritten oder fünften Faktor. Um das hier nochmal kurz anzureißen, du und ich, wir wissen was damit gemeint ist, viele Nutzer sind bestimmt schon mal über den Second Factor oder Two Factor Authentication gestolpert, die ja mittlerweile immer gängiger wird, wo ich auch sagen muss, SMS ist ein wahnsinnig schlechter Second Factor, weil mir so passiert, mein Telefonanbieter hat, nachdem ich den Vertrag gelöscht habe, die Nummer nicht mehr angeboten und stellt sich raus, das war zu einem meiner GitHub-Accounts der Second Factor, dass ich eine SMS an dieser Handynummer bekommen kann und dann habe ich mich da ausgeschlossen. Und dann steht GitHub da als Plattform, die dir sagt, ja, also wir können die nicht verändern, das musst du schon können. Und mein Telefonprovider sagt, ja, die Nummer ist in unserem Pool, die können wir nicht nochmal vergeben, auch nicht, wenn du ganz lieb bitte sagst. Also bei der Frage, was sind weitere Faktoren, können wir vielleicht nochmal reingehen und erklären, bei dem, was die meisten Leute als Second Factor kennen, wie sieht das idealerweise aus? Da gibt es ja Unterscheidungen zwischen etwas, das ich habe, etwas, das ich weiß und so weiter.

Martina Genau, ja. Das, was du natürlich beschreibst, ist wirklich so das Worst-Case-Szenario. Aber auch wie du schon richtig gesagt hast, dieser SMS-Code gilt eigentlich als so das Unsicherste, was man nutzen kann. Was man normalerweise nutzt, sind sogenannte Authenticators auf dem Smartphone. Die werden beispielsweise von Microsoft oder Google angeboten oder auch natürlich hat jedes Betriebssystem sowie Android oder auch iOS ihre eigenen Authenticators. Und letztendlich kann ich damit eben mein Account verknüpfen. Und was dann eigentlich passiert ist, dass auf meinem Smartphone wird quasi ein Code generiert. Und das ist meistens so ein sechsstelliger Code und der ist dann für 60 Sekunden dann gültig. Und immer wenn ich mich eingeloggt habe mit Nutzername und Passwort, werde ich eben nach diesem zweiten Faktor, nach diesem Code gefragt. Und das ist meistens etwas, was ich habe. Also das kategorisiert man in diese zweite Faktorkategorie etwas, das ich habe. Es gibt natürlich auch die Möglichkeit, etwas, was ich bin, das wäre dann, dass der zweite Faktor tatsächlich eine Art Gesichtserkennung ist oder auch meine biometrischen Daten, also mein Fingerprint zum Beispiel, dass wenn ich mich zum Beispiel auf meinem Smartphone irgendwie einlogge, dass mein Smartphone mich dann auch nur fragt. Bitte gebe mir noch einen zweiten Faktor als dein Fingerprint halt letztendlich zur Verfügung. Was es natürlich auch noch gibt, ist die IP-Adresse oder auch mein Standort, wo ich gerade bin. Da können dann sehr viele verschiedene Arten als sogenannter zweiter Faktor zugezogen werden. Aber klar, am besten eignet sich halt eben etwas Biometrisches, also wirklich so Iris-Scan, wie man es so aus James-Bond-Filmen kennt. Dass man dann jemanden vielleicht den Fingerabdruck klaut. Sowas ist natürlich in der reellen Welt, kommt nicht so häufig vor. Es gibt natürlich immer eine kleine Möglichkeit. Man darf keine absoluten Aussagen treffen in der Sicherheit. Aber ja, also sowas, was eher so nur in James-Bond-Filmen vorkommt, ist ja in der Realität nicht immer ganz so gängig. Und deshalb ist gerade so biometrische zweite Faktoren oder auch natürlich diesen Code, von dem ich anfänglich gesprochen habe, am sichersten.

Ali Also biometrische Faktoren sind natürlich beliebt, haben nur einen großen Nachteil. Wenn sie einmal in die Öffentlichkeit gelangen, kann man sie nicht mehr ändern. Ich kann meinen Fingerabdruck, meine Iris oder mein Gesicht nicht so ohne weiteres ändern. Und dementsprechend, ich erinnere mich da sehr prominent an eine Pressekonferenz, bei der Ursula von der Leyens Daumen mit einem Teleobjektiv fotografiert wurde und von, ich glaube Schäuble war es, gibt es ein Wasserglas, von dem nach der Bundespressekonferenz mal mit Talgpulver einfach ein Negativ vom Finger runtergepinselt wurde, um zu zeigen, die Menschen, die sich hier dafür einsetzen, dass biometrische Daten in, ich glaube Reisedokumente war es, damals verpflichtend reinkommen. Wenn deren eigene Daten dann in die Öffentlichkeit geraten, sind sie ganz alert. Wo ich sagen muss, ich kann das auch schon verstehen. Ich fände es auch nicht schön, wenn mein Fingerabdruck öffentlich rumgereicht werden würde, aber da ist halt das Problem. Wenn diese Form der Verifizierung einmal bekannt ist, ist sie nicht komplett wertlos, aber ein Angriffsvektor.

Martina Ja klar, das ist auf jeden Fall ein guter Punkt und deshalb bevorzuge ich, wenn man noch Nutzername und Passwort benutzt, als zweiten Faktor eben halt diesen sechs- oder fünfstelligen Code, je nach Authenticator, den man dann eingeben muss. Wenn wir generell gerade ein bisschen davon sprechen, von Authentifizierung, gibt es ja noch eine weitere Möglichkeit, die ganz von Nutzername und Passwort mittlerweile absieht und das sind die sogenannten Passkeys.

Ali Oh ja, bin ich großer Freund von. Und hast du auch in deinem Buch angeschnitten. Ich finde, die Idee dahinter ist so schön, dass man gar nicht mehr sagt, ich gebe dir als Website, als Anbieter die Informationen, mit denen ich mich authentifiziere, sondern ich gebe dir im Prinzip ein Schloss in die Hand, zu dem ich den Schlüssel halte und du prüfst nur, ob ich das Schloss aufschließen kann. Das ist so eine elegante Lösung, die sich sehr zeitgemäß anfühlt. Also ich bin großer Passkey-Fan.

Martina Ich auch tatsächlich. Also ich reise viel auf Konferenzen und rede eigentlich nur über Passkeys, weil das für mich so die bislang jetzt vielversprechendste Variante ist, um sich auch sicher authentifizieren zu können. Aber wie gesagt, das sind alles so auch Dinge, weil zum Beispiel Passkeys, das hat gar nichts mehr mit OpenID Connect oder OAuth zu tun. Das ist zum Beispiel in der FIDO2-Allianz, das ist Fast Identity Online, das ist quasi eine eigene Gruppierung, die sich zusammengefunden hat, um einfach passwortlose Authentifizierung zu ermöglichen. Und darüber könnte man auch stundenlang natürlich reden. Aber OIDC und OAuth beschäftigt sich quasi so ein bisschen mit den Schritten danach. Also womit sich dann OIDC, also OpenID Connect noch beschäftigt, ist beispielsweise auch diese Identity Federation, wie man es auch so gerne nennt, dass ich beispielsweise mich auch einfach mit Google einloggen kann. Man kennt es ja vielleicht, man ist auf irgendeiner Webseite und dann bekomme ich die Möglichkeit, mich über vielleicht damals auch noch Twitter-Account oder auch Facebook-Account, GitHub oder auch eben mit Google einloggen zu können. Das heißt, ich brauche gar nicht eine wirkliche Registrierung auf diesem Service, sondern ich kann mich einfach dann einloggen mit eben Google oder auch von mir aus auch meinem, iCloud Keychain Passwort, also meiner Apple ID ist das dann. All die Möglichkeiten, das ist tatsächlich auch in OIDC beschrieben worden. Und das führt natürlich dazu, wenn ich dann den Service wieder besuche, dann kann ich einfach nur auf Login with Google quasi drücken. Dann werde ich vielleicht kurz zu Google redirected und muss mich dann gegebenenfalls nochmal gegenüber Google authentifizieren. Aber das ist dann das Wilde. Ich sehe dann gar nicht so richtig, was passiert, weil wenn ich dann auf Login with Google drücke, dann sieht man, dass in dieser Browser-Adresszeile wilde Dinge passieren und dann bin ich plötzlich eingeloggt. Und genau diese wilden Dinge, die da hinten dran passieren, das ist halt letztendlich auch, was in OIDC so genau spezifiziert ist.

Ali Bevor wir da im Detail drauf eingehen, es gibt natürlich die valide Kritik, dass bei den Sign-in-with-Buttons, dass man sich da mehr und mehr abhängig von Big Tech macht. Also ich selbst bin im Apple-Ökosystem, ich habe einige Services, bei denen ich Sign in with Apple angeklickt habe für die Convenience, vor allem wenn man mal was nur schnell ausprobieren möchte und man möchte sich jetzt nicht einen Account anlegen, wobei das ja auch mittlerweile immer einfacher geworden ist, aber es gibt dann noch einige Services, wo ich Sign in with Apple angeklickt habe. Wenn ich jetzt sagen würde, ich möchte Open Source gehen, ich verlasse macOS, dann wäre das schon eine ziemliche Arbeit, all meine Accounts aufzuspüren, in denen ich Sign in with Apple angeklickt habe und da neue Credentials zu hinterlegen, um die Accounts zu behalten. Also das kommt natürlich auch mit seinem Preis, dass man entsprechend diese Services vorschickt.

Martina Absolut. Und ein weiterer Punkt ist natürlich, angenommen, ich habe jetzt überall mich eingeloggt mit Google, wenn dann jemand mal mein Google-Passwort hat und vielleicht keinen zweiten Faktor hat, das ist nicht ausreichend geschützt und so weiter. Und die Person, der Angreifer, die Angreiferin sich dann in meinen Google-Account einloggen kann, dann kann die Person sich natürlich ebenfalls in alle, alle, alle anderen Services automatisch einloggen, weil ich ja überall Login mit Google geklickt habe. Das heißt, es ist nicht ganz so von der Hand zu weisen, dass es natürlich ein paar Risiken mit sich bringt. Wo wir natürlich erneut zu dem Punkt kommen, einfach Passkeys zu benutzen, für jeden Service einen. Aber wie du schon gesagt hast, das ist ja auch eine Art Convenience. Und ich bin in beiden oder in vielen Ecosystemen unterwegs. Glaube zwar eher so ein bisschen in den Google-Ecosystemen, aber dadurch, dass ich auch Mac habe, habe ich auch viel in meiner iCloud Keychain, dass es so ein bisschen verteilt ist. Aber ja, man macht sich absolut abhängig von den ganzen Vendors auf jeden Fall.

Ali Jetzt hatten wir, bevor wir auf dieses Detail eingegangen sind, noch darüber gesprochen. Du meintest, da passiert da ganz viel ganz schnell in deiner Adresszeile und du bekommst das gar nicht so im Detail mit. Das gehst du ja in deinem Buch wirklich mal im Detail nach. Wer da an wen, wo, wie eine Information weiterleitet, die dann von wem wie bestätigt und validiert und weitergereicht wird, sodass die Services im Zweifel nur wissen, ist es ein legitimer Zugriff und nicht mehr über mich wissen müssen.

Martina Ja, genau, weil für mich ist es ganz wichtig. Oder was mir persönlich immer geholfen hat, ist, wenn ich auch verstanden habe, wie die Dinge im Hintergrund funktionieren. Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja, du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach, jetzt, um im OAuth-Kontext zu bleiben, den Authorization-Codeflow mit PKCE verwenden. Dann bist du sicher. Ja, damit habe ich irgendwie immer Probleme, weil ich irgendwie gerne auch wissen würde, warum denn? Also es ist jetzt vielleicht aufwendiger, diese Erweiterung PKCE noch zu verwenden, weil ich das irgendwie auch konfigurieren muss und ich will doch einfach nur ein Access-Token haben. Warum ist das jetzt wichtig, dass ich diese Erweiterung nutze? Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch zu schreiben. Und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level als dann auch sehr detailreich geschafft, um halt klarzumachen, wie die ganzen sogenannten Flows, da kann ich gleich dazu kommen, was die genau bedeuten, und wie die halt genau funktionieren. Ein großes Problem oder eins der größten Probleme, die OAuth löst oder versucht zu lösen, ist eben, ich habe jetzt eine Webseite und in dieser Webseite möchte ich mich einloggen. Diese Webseite möchte natürlich auch Daten haben und diese Daten sollen ja geschützt sein mit so einem Access, also mit einem Access-Token, sprich, wenn diese Webseite Daten braucht. Angenommen, wir sind vielleicht auf einer Shop-Webseite, wo ich irgendwie einkaufen kann und dann sollen mir ja quasi die ganzen Produkte angezeigt werden. Das heißt, ich rufe in den meisten Fällen so eine Art Produkt-API auf. Ich will ja vielleicht aber jetzt auch meinen Warenkorb sehen und ich will jetzt natürlich nur die Produkte angezeigt bekommen, die ich jetzt bereits in den Warenkorb gelegt habe oder die ich bereits eingekauft habe. Auch wenn ich meine Rechnungen einsehen will, das soll ja alles beschützt sein. Deshalb muss ich an diese API so einen Access-Token senden. Jetzt ist es aber gar nicht so einfach, an diesen Access-Token zu kommen. Denn wie schaffe ich denn es sicher, meinem Authorization-Server zum einen natürlich zu beweisen, dass ich ich bin. Okay, da gibt es so dieses Nutzername-Passwort. Okay, das funktioniert dann schon. Aber dann, nachdem ich mich erfolgreich vielleicht authentifiziert habe, muss ja dieser Identity Provider irgendwie jetzt diesen Access Token wieder zurücksenden an meinen Browser, damit der das halt weiterverarbeiten kann. Und dieses Zurücksenden, das hat wahnsinnig. Viele Risiken und Probleme, weil sich da eben Angreifer und Angreiferinnen theoretischerweise relativ einfach dazwischen schalten können und so tun können gegenüber diesem Identity Provider. Ja, ja, du kannst den Token an mich senden und nicht an das, was du hast für eine Anfrage bekommen von so einem anderen Browser, aber sende mal den Token bitte an mich. Und da gibt es viele verschiedene Angriffsszenarien und deshalb macht es es eben auch so kompliziert, weil... Ein Hauptproblem, kurz noch der eine Satz dazu, ein Hauptproblem ist, dass ich halt als Browser kann ich dem Authorization Server oder auch Identity Provider genannt, nicht sagen, guck mal, hier, ich bin der legitime Client, mir darfst du den Access Token geben. Meine Client-Application, meine heutzutage Single-Page-Application, kann sich ja nicht authentifizieren gegenüber dem Authorization-Server. Der kann ja nicht sagen, guck mal, ich bin der richtige Client, der liebe Client, mir kannst du den Access-Token jetzt geben. Wie soll das funktionieren, wenn ich ein Secret oder so ein Passwort halt in meiner Single-Page-Application speichere, dann kann die natürlich jeder einsehen, weil das liegt dann im JavaScript rum, es ist dann im Browser ausgeliefert und das kann natürlich jeder über die Dev-Konsole letztendlich auslesen.

Ali Ab dem Moment, wo ich im Browser im Cookie hinterlege, ich bin vertrauenswürdig, ist das etwas, was andere Leute im Prinzip lokal selbst reinschreiben könnten oder eben ablesen.

Martina Genau, nicht nur in dem Cookie. Der Cookie ist nochmal ein bisschen anders tatsächlich. Der Cookie ist schon beschützt durch gewisse andere Maßnahmen, aber der Cookie hilft uns gar nicht so viel, weil der Cookie darf halt nur immer an dieselbe Domäne mitgesendet werden, wie von der Domäne, die den Cookie gesetzt hat. Also zum Beispiel authserver.com. Wenn mein authserver.com mir ein Cookie setzt, dann wird der Cookie ja nur mitgesendet, wenn ich ein Request an authserver.com sende. Hauptsächlich, also damit das funktioniert, irgendwie würde das nur möglich sein, dass ich irgendwie ein Secret in mein JavaScript lege und da kann ich es natürlich jederzeit auslesen. Aber klar, theoretischerweise, wenn ich das Secret auch so in den Cookie speichere und das Secret ist immer gleich, was es halt vielleicht sein muss dann für den Client, dann kann ich auch den Cookie natürlich über die Developer-Konsole mal kurz öffnen und auch reingucken und das auslesen.

Ali Und jetzt hattest du vorhin gesagt, die Flows im Hintergrund seien interessant. Also ich denke, es ist nachvollziehbar, dass es ein Problem ist bei diesen Großanwendungen, also zum Beispiel beliebiger Online-Webshop, wo es relativ reibungslos sein muss. Und natürlich im Hochsicherheitsbereich würde man das Ganze anders regeln, dass man sagt, was hier untereinander spricht, das hat alles Zertifikate, die entweder, also das kann man ja beliebig komplex denken, dass ich darkside alle Zertifikate nur aus diesem Gebäude heraus vergeben habe mit Geräten, die physisch vor Ort waren. Da kann ich mir relativ sicher sein, dass die Geräte, die sich da zurückmelden mit dem entsprechenden Zertifikat, die Geräte sind, die ich rausgegeben habe. Aber ab dem Moment, wo ich das on scale mache, wie ein großer beliebiger Online-Shop, der ja nicht mit den Leuten vorher noch Zertifikate austauschen kann in Person, ab da an brauche ich ja andere Wege, um sicher zu gehen, dass meine Rücksendung auch bei einem entsprechenden Browser ankommt und nicht unterwegs abgegriffen werden kann. Also da gibt es auch in der Wikipedia beschrieben ein potenzielles Angriffsszenario und man versucht ja Man-in-the-Middle zu umgehen, aber wenn ich bei den Authentifizierungsservern Schad-Server dabei habe, wie gesagt, große Diagramme, komplizierte Angriffe, ich bin froh, dass die Wikipedia das sehr vereinfacht hat, aber da gibt es ja durchaus Probleme, dass da nicht ganz klar ist, an wen schicke ich jetzt zurück. Ich kann nicht ohne weiteres als Authentifizierungsserver bestätigen, dass der, dem ich gerade die Authentifizierung erteilt habe, der ist, der sie angefordert hat.

Martina Ja, also absolut richtig. Und das ist halt hauptsächlich, wie gesagt, eins der größten Probleme bei den Single-Applications, die wir heutzutage haben. Es gibt natürlich auch Szenarien, wo wir Microservices haben, wo ein Server mit einem anderen Server irgendwie redet. Meistens ist man ja so mittlerweile, dass man so seine ganze Web-Applikation so ein bisschen schneidet, vertikal und es gibt verschieden, für jede Domäne gibt es einen eigenen Microservice. Und klar, wenn ich dann Daten anfrage, die über mehrere Microservices gehen, dann müssen die ja auch miteinander reden, dass alle Daten zusammen kumuliert werden und halt als eine Datenmenge vielleicht wieder zurückgegeben werden. Das wäre zumindest ganz nett, dass ich nicht als Client alle Microservices einzeln aufrufen muss. Und da kommt es natürlich auch zu Trage, dass sich ein Microservice auch einen Access-Token holt, damit dieser sich natürlich auch ausweist als, hey, guck mal, ich habe die Berechtigung und darf jetzt auf deinen Daten ebenfalls zugreifen. Der größte Vorteil ist halt daran, dass ich, wenn ich in der Backend-Welt bin, hinter gesicherten Firewalls, es zumindest weitaus ungefährlicher ist, dass jetzt ein Backend natürlich. Eine kleine ID und einen kleinen Secret nennt sich das dann, also halt ein Secret letztendlich speichere, um sich damit halt ein Token zu holen. Und das ist in diesen sogenannten Flows niedergeschrieben. Das ist auch eigentlich ein guter Einstieg vielleicht mal da rein, denn so ein Backend, da gibt es dann wie gesagt einen Microservice und der agiert jetzt als ein OAuth-Client, weil er Daten haben möchte. Und dieser Microservice, der nimmt jetzt einen speziellen Flow, der nennt sich Client-Credentials-Flow. Der macht nichts anderes, als einmal zum Authorization-Server zu gehen und zu sagen, hey, guck mal, ich habe hier ein Client-ID, Client-Secret, ich möchte mit dem Microservice sprechen, bitte stelle mir so einen Access-Token aus. Und dieser Flow ist super einfach und super simpel, weil dann der Authorization-Server sagt, okay, ich kenne dich, du hast mir dein richtiges Passwort verraten, also dieses Secret, Und ich schreibe eben dein Target Service, wo du Daten haben möchtest, auch noch als eine Audience, also damit auch klar ist, für wen das Token bestimmt ist, in den Token rein und dann hast du den Access Token. Und das ist alles super simple und alles super cool. Aber wie gesagt, das geht halt nicht so einfach in Single-Page-Application. Und was ich immer, wenn ich über OAuth rede, dann liebe ich es immer zu sagen, dass es halt bei OAuth rund irgendwie, sieben Flows gibt und fünf davon sind nur alleine für Single-Page-Applications oder für das Web. Sagen wir mal, das hat nicht gestimmt, Single-Page-Application nicht, aber für die Web-Applikation, dass man als Web-Applikation ebenfalls ein Access-Token holen kann, was halt die, Schwierigkeit und die Irrsinnigkeit vielleicht auch ein bisschen am besten beschreibt dafür natürlich.

Ali Das ist durchaus sehr nachvollziehbar. Vor allem, wir leben ja mittlerweile in einer Welt, wo Web-Apps omnipräsent sind und Dinge werden zu immer kruderen, einfach nur anders ausgespielten Websites, wenn man mal wirklich tief gräbt. Und dementsprechend, ich verstehe, dass da so ein großer Fokus drauf liegt. Ich verstehe, dass das große Probleme mit sich bringt. Du sagtest gerade, der Authentication-Server kann das sehr einfach dann bestätigen. Und ein Begriff, der in deinem Buch auch vorkommt, zum Thema Einfaches bestätigen, das ist Zero Trust. Und Zero Trust ist eine der Sachen, ich weiß nicht, ob es da auch Anwendung findet. Im Zweifel musst du mich da korrigieren.

Martina Na klar, also Zero Trust ist eigentlich ja genau das. Also Zero Trust gibt es in verschiedenen Ebenen, also dass ich als Server auch keinem Client vertraue, aber Zero Trust ist oftmals eigentlich so in der Microservice-Welt, bedeutet letztendlich, dass ich natürlich auf jeden Fall immer auch mit einem Access-Token an Inter-Service-Kommunikation letztendlich halt haben muss, dass ich da auch immer ein Access-Token haben muss. Und natürlich auch TLS, also dass auch die Services untereinander immer nur verschlüsselt sprechen, dass ich halt nur, weil ich vielleicht im selben Netzwerk bin, dass ich halt nicht einfach belanglos jetzt jedem Service vertraue, der meine Daten haben möchte.

Ali Wo du TLS sagst, also Transportverschlüsselung. OAuth in der ersten Version war noch für HTTP entwickelt und dementsprechend ohne Transportverschlüsselung in mind. Und da sind wir jetzt auch, wie gesagt, 2007 entwickelt. Da hat sich ja auch mittlerweile viel getan.

Martina Ja, klar. Also OAuth 2 setzt auf jeden Fall TLS voraus. OAuth 1 hatte halt so ein bisschen noch den Vorteil, dass wir so etwas hatten, was sich Sender-Constrained-Tokens nennt. Also dass das Token quasi hochkryptografisch gebunden ist und klar ist, ich klar verifiziere als Empfänger des Tokens, der den Token dann auswertet, ganz klar verifizieren kann, dass der Token auch vom richtigen Sender kommt. Da konnte ich nicht einfach so ein Token mal austauschen, sage ich mal, oder an jemanden geben und die Person kann dann mit ihrem Client und dem Token irgendwie mal eine Anfrage senden. Das wäre auf keinen Fall gegangen, weil das halt kryptografisch an den Absender gebunden ist. Und das hat man auch Sender-Constraining genannt. Und das ist etwas, was man halt mit OAuth 2 absolut entfernt hat. Da gibt es kein Sender-Constraining mehr. Da ist dann das entstanden, was man auch vielleicht kennt, das nennt sich dann Bearer-Token. Also der Träger des Tokens, der ist legitimiert, einfach jetzt die Anfrage zu senden. Das bringt natürlich das Problem auf sich, wenn ich so eine schöne Cross-Site-Scripting-Attacke auf meiner Webseite habe und mein Access-Token liegt vielleicht in einem Speicher im Webbrowser, der über JavaScript zugänglich ist, wie beispielsweise der wunderschöne Local oder Session Storage, dann könnte ich halt mit so einer Cross-Site-Scripting-Attacke diesen Access-Token stehlen. Und wenn ich ihn gestohlen habe, dann kann ich halt einfach so den Access-Token selbst verwenden. Der hat eine gewisse Gültigkeit. Eigentlich soll er meistens so fünf bis 15 Minuten lang gültig sein. Aber 15 Minuten, wenn ich ihn dann bereits nach zwei Minuten gestohlen habe, dann habe ich noch 13 Minuten Zeit. Damit kann ich halt schon noch einiges anstellen und auch machen im Namen des Nutzers oder der Nutzerin.

Ali Wir hatten ja gerade Zero Trust auch beschrieben und Zero Trust ist so eine der Sachen, da gibt es schöne, einfache Schaubilder zu, über die ich mich sehr gefreut habe und wenn man dann das erste Mal die Mathematik dahinter sieht, dann bin ich wirklich sehr beeindruckt. Ich weiß nicht, wie tief du da mal gegraben hast. Also ich finde Zero Trust zu erklären ist gar nicht so schwer, aber Zero Trust nachzubauen ist, oh mein Gott, was hat die Menschheit da geschafft, das ist im Prinzip die nächste Mondlandung.

Martina Auf jeden Fall. Und es ist halt noch komplizierter, das auch umzusetzen und so diszipliniert umzusetzen. Und klar gibt es Lösungen, die das anbieten. Aber Zero Trust bedeutet halt auch Performance-Einbußen. Und das ist halt natürlich etwas, was viele gerade in der sehr schnelllebigen Webwelt, deshalb doch nicht implementieren wollen, also Zero Trust dann nicht so durchgängig implementieren wollen, weil sie halt sagen, das ist zu viel Kryptografie. Kryptografie sind performanceintensive Operationen und deshalb ist es nur so ein halbes Zero Trust, das oftmals implementiert wird.

Ali Also in der Idealvorstellung bedeutet Zero Trust jetzt hier einmal im Schaubild gesprochen, das macht dann auch verständlich, was eins der Performance-Probleme ist, dass ich dem Anbieter gegenüber gar nicht beweisen muss, dass ich weiß, was er weiß, sondern es gibt dieses Schaubild von, es gibt eine Felswand, in der es sind ganz viele Höhlen und Höhleneingänge und ein paar von denen sind miteinander verbunden. Und der Anbieter weiß, dass es einen direkten Weg gibt von der Höhle 1 zu der Höhle 2 und ich zeige ihm jetzt, dass ich diesen Weg kenne, indem ich in die eine Höhle rein und aus der anderen Höhle rauskomme. Aber es gibt hunderte mögliche Höhlenein- und -ausgänge. Das heißt, es reicht nicht, wenn ich auf Verdacht sage, übrigens der Eingang ist der da oben links und der Ausgang ist der da unten rechts, weil es könnten ganz viele andere Wege sein. Ganz viele von diesen Höhlen sind theoretisch nicht miteinander verbunden. Also ich muss sehr spezifisch beweisen, ich kenne Ein- und Ausgang und wie ich zwischendrin belege, dass ich den Weg zwischen denen kenne, muss der Anbieter, der verifiziert, gar nicht wissen. Für den reicht es, dass ich performen kann. Ich kenne die Start- und die Endbedingungen und dazwischen kann ich nur über komplizierte Kryptografie wirklich den Weg gefunden haben. Das zu erraten, ist halt so ein klassisches Problem von, wenn man das bruteforced, sind wir schnell an dem Punkt von, so viel Zeit hat das Universum nicht oder es ist für die Anwendung nicht relevant, wenn man sagt, Bruteforce ist möglich, aber bei der aktuellen Rechenleistung bräuchtest du 1,5 Millionen Jahre, ist das ein Risiko, das man eingehen kann. Hat aber das Problem, dass wenn ich anfange zu bruteforcen, der Authentifizierungsserver erstmal damit überlastet ist, dass er die ganze Zeit sagen muss, nee, das war nicht richtig, auch hier wieder nicht richtig, auch hier wieder nicht richtig, ich mache die Session mal zu, neue Session kommt auf, oh, du hast wieder mehrfach falsch angefragt. Und das sind halt solche Probleme, die dann on scale dazu führen, dass man als Anbieter, der mit Zero Trust verifizieren möchte, schnell das Problem läuft, dass wenn man angegriffen wird, man einfach sehr viele Ressourcen darauf werfen muss, dass jemand gerade versucht einzubrechen.

Martina Ja, genau. Und wie du schon beschrieben hast, das sind halt super viele komplexe, kryptografische Fahnen dahinter, es gibt aber tatsächlich also Zero Trust ist ja auch mehr ist ja kein Produkt in dem Sinne ist ja kein, etwas was man jetzt konkret anwenden kann, sondern ist ja mehr so ein Gedankenmodell, was man dann halt letztendlich, umsetzen kann, muss, mit dem Nachteil dann natürlich, dass wir vielleicht ein bisschen Performance einbüßen müssen.

Ali Jetzt hast du in deinem Buch am Ende ein Fazit geschrieben, in dem es darum geht, wie sich die Moderne umsetzt. Also du hast moderne Ansätze und Standards beschrieben, praktische Umsetzungen davon, wo man anfängt, wie man die umsetzen kann. Und du machst auch einen Zukunftsausblick und der de facto Standard im Moment, den beschreibst du ja auch. Und ein Kapitel, das JSON-Web-Token. Ich denke, wir kommen nicht drum herum zu beschreiben, warum das gerade so wichtig ist.

Martina Ja, JSON-Web-Tokens sind tatsächlich einfach erstmal komplett losgelöst von OAuth. OAuth selbst sagt sogar, dass die Access-Tokens gar nicht JSON-Web-Tokens sein müssen, sondern das können auch sogenannte Opaque-Tokens, nennen sich dann also einfach nur Reference-Tokens in dem Sinne. Aber in den meisten Fällen oder nahezu immer ist ein Access-Token halt so ein JSON-Web-Token. Und das Coole an so einem JSON-Web-Token ist halt, dass es self-contained ist und man kann es verifizieren. Was bedeutet das? Da müssen wir vielleicht einen kleinen Zurückschwenker zu cookiebasierter Authentifizierung machen. Wenn wir uns ja mit Cookies authentifizieren, ist das ja normalerweise so, ich logge mich ein mit Passkey, Second Factor, wie auch immer ich mich halt authentifizieren möchte. Und der Server, der in den meisten Fällen damals halt so eine traditionelle Web App war, der baut dann eine Session auf und erstellt ein Session Cookie. Und diese Session Cookie wird mir dann in meiner Web App eben. Die ebenfalls von demselben Web-Server ausgeliefert wird. Und das war dann eigentlich ganz cool, weil jedes Mal, wenn ich Daten haben wollte, habe ich halt so ein Request an meinen Web-Server geschickt und der Browser setzt dieses Cookie ganz automatisch. Also es war ein Browser-Feature. Ich musste das Cookie nicht manuell speichern, nicht manuell auslesen. Der Browser hat es einfach mitgesendet. Und der Nachteil davon war halt aber, dass ich halt total stateful war. Also, dass ich halt jedes Mal, wenn ich halt Daten haben wollte, musste der Cookie mitgesendet werden. Und ich konnte jetzt auch nicht einfach sagen, oh, schick mir jetzt bitte einen Request an einen anderen Server, weil ich von dem auch Daten haben möchte. Weil der andere Server wäre dann auf einer ganz anderen Domäne gelaufen und hätte auch die Session gar nicht gespeichert und wüsste dann gar nicht, wer ich bin. Und ich hätte mich da vielleicht auch nochmal einloggen müssen. Das ist alles so ein bisschen nicht so vorteilhaft gewesen, weshalb man dann natürlich gesagt hat, ja, wir wollen eine gewisse Flexibilität haben. Es wäre super, wenn wir einfach etwas an die Server senden können und die Server können total unabhängig von wer auch immer diesen Token ausgestellt hat, also wer auch immer dieses Authentifizierungs- oder Autorisierungstoken ausgestellt hat, halt einfach verifizieren, dass jetzt dieser Client oder Nutzer, der diesen Token gesendet hat, eben die Daten haben darf. Und da kamen dann diese JSON-Web-Tokens ins Spiel. Und in diesen JSON-Web-Tokens, das ist eigentlich nichts anderes wie ein sogenannter Header, ein Payload und eben die Signatur. Und die Signatur hat halt diesen Vorteil, dass halt der Token natürlich signiert ist. Und wie wir vielleicht schon wissen, wenn wir etwas signieren, dann können wir auf die Authentizität überprüfen, aber auch überprüfen, dass auch niemand den Token irgendwie boshaft verändert hat, also diesen Payload hauptsächlich irgendwie verändert hat. Weil in diesem Payload stehen ja halt jetzt meine Berechtigungen drin. Man kann sich ja schon vorstellen, wenn ich jetzt eine Berechtigung, ich sag mal einfach nur lesen habe und ich würde jetzt bösartig eine Admin-Berechtigung reinschreiben, dann habe ich wenigstens den Vorteil, dass halt der Token nicht mehr verifiziert werden kann, weil halt die Integrität, also die Signaturprüfung dann natürlich gebrochen ist.

Ali Zum Thema der Integrität des Tokens hast du auch ein eigenes Kapitel, was ich sehr zukunftsorientiert fand, über die Quantencomputer-Angriffsvektoren und die Post-Quanten-Kryptographie, die in den Web-Tokens, in den JWTs mittlerweile drinsteckt. Das war so etwas, wo ich gedacht habe, ganz oft, wenn Leute sagen, welche tollen Anwendungsbereiche Quantencomputer haben, dann sehe ich immer nur den, ja, wir können Security umgehen und dann bin ich immer froh, wenn aus der Security-Kryptographie, Branche heraus schon kommt übrigens und wir haben hier Post-Quantum-Cryptography-Sicherheit implementiert, wo es auch nicht hilft, wenn man das Token tatsächlich mit dem Quantencomputer in Anführungszeichen aufbrechen kann.

Martina Ja, es gibt doch schon zig Post-Quantum-Algorithmen, die sowohl für Verschlüsselung, Entschlüsselung als auch für die Signaturüberprüfung eben zugezogen werden können. Ich arbeite auch sehr viel im Banken- oder Finanzsektor und da ist es eigentlich sogar schon gang und gäbe, dass da gerade Post-Quantum-Algorithmen eingebaut werden, weil die haben halt einfach schon auch die Pflicht und müssen das letztendlich umsetzen. Ein kleiner, das habe ich auch kurz in meinem Buch erwähnt, aber nur als Info ist, es gibt sogar noch etwas, das nennt sich FAPI, Financial API und das setzt sogar OAuth noch eins oben drauf. Da steht beispielsweise drin, müssen wir jetzt gar nicht groß ausführen, aber da steht beispielsweise nämlich drin, dass wir bitte so etwas wie Post-Quantum-Kryptographie schon implementieren in diesen Access-Tokens. Eben, dass halt quasi die Hochsicherheitsstufe ausgerufen ist, die Requirements dafür. Und die müssen dann natürlich gerade im Medizin- und Finanzsektor dann natürlich auch umgesetzt werden.

Ali Und da ist dann das ewige Waffenrennen zwischen, wie sicher kann ich es machen, wie performativ bleibt das System zeitgleich und welche Risiken kann ich eingehen, weil wir hatten ja schon mal angeschnitten, ich kann theoretisch extrem sichere Systeme bauen, die extrem nutzerunfreundlich sind und da dann die Abwägungen zu schaffen zu, es muss immer noch schnell gehen, es muss sicher genug sein, es muss zukunftssicher genug sein, das ist ja wirklich etwas, da gibt es keine richtige Entscheidung, sondern das sind halt sehr komplizierte Pfade, die da zusammenlaufen.

Martina Ja, absolut. Das ist ja auch schon das heutige Problem alleine, wenn ich Passwörter verschlüsseln möchte, also hashen möchte. Ich kann natürlich mein scrypt oder Argon2-Hash-Funktion kann ich ja konfigurieren, wie, um es mal sehr salopp zu sagen, wie langsam sie sein sollen. Denn gerade mal so Bruteforce-Attacken oder wenn ich dann mal so Datenbanken geklaut habe, wo ganz viele Hash-Werte drinstehen, dann will ich ja ganz, ganz viele Versuche schaffen, das zu hashen, innerhalb von wenigen Sekunden und wenn ich einmal diese Hash-Ausführung aber jetzt irgendwie fünf Sekunden lang mache…, Und ich brauche vielleicht eine Million mal, um ein einziges Passwort zu knacken, dann ist ja eine Million mal fünf, ist ja schon eine ganz schön lange Zeitdauer. Aber deshalb könnte man natürlich sagen, ja, wieso dann nur fünf Sekunden? Dann mach doch die Hash-Funktion, konfiguriere doch die Hash-Funktion so, dass sie 20 Sekunden braucht. Ja, das wäre natürlich viel, viel, viel sicherer. Aber wenn ich als Nutzerin, ich persönlich mich irgendwo einlogge, dann muss ja mein Passwort ebenfalls gehasht werden, um zu vergleichen, ob derselbe Hashwert auch in der Datenbank steht. Und ich kriege schon die Krise, wenn ich auf eine Webseite gehe und sie braucht, zwei Sekunden zum Laden.

Ali Oh, du lebst nicht in Deutschland?

Martina Ja, da hast du absolut recht. Das ist sehr schade manchmal.

Ali Also zwei Sekunden zum Laden, das rechne ich hier immer noch zu „So ist das Internet hier halt" ein, aber ich verstehe komplett, was du meinst, vor allem bei den 20 Sekunden. Als moderner Mensch hat man einen Passwortmanager und tippt das Passwort nicht mehr von Hand ein, aber wenn es dann doch eins ist, das man mal von Hand eintippen muss und man muss 20 Sekunden bei jedem Typo, den man gemacht hat, warten, das ist natürlich auch einfach unpraktisch.

Martina Ja, da gibt es natürlich was, was helfen kann und das sind Passkeys. Ja, also Passkeys haben tatsächlich schon statistisch die Login-Dauer auch verringert. Also da gibt es ganz coole Statistiken von der Fido-Allianz dazu. Ja, großer, großer Fan.

Ali Ja, jetzt hattest du verschiedene Gremien erwähnt und auch bei OpenID Connect, es stehen ja Organisationen hinter diesen de facto Standards, hinter diesen Entwicklungen. Wie ist das, welche Interessen haben die, entwickeln die das für das Greater Good der Menschheit, entwickeln die das, um selbst sicher zu sein, weil wir hatten es ja auch schon mal angeschnitten, irgendwann kommst du an den Punkt mit, es gibt verschiedene konkurrierende Systeme und Interoperabilität ist ja total wichtig, damit so ein System sich durchsetzen kann. Also wer entwickelt an diesen Standards und wer unterstützt, dass diese Entwicklung stattfinden kann, denn das ist ja jetzt nichts, was ausschließlich durch Goodwill und ein paar Universitäten entsteht.

Martina Ja, in den meisten Fällen ist es der IETF, das ist der Internet Engineering Task Force und die erstellen sogenannte RFCs. Und da ist letztendlich, die RFCs sind quasi die Spezifikation. Und da finden sich aber meistens dann Menschen aus der Industrie zusammen. Das kann mal jemand von Microsoft sein oder mal jemand von Ping Identity ist hauptsächlich auch oftmals dabei, aber auch von Google natürlich, von Apple. Also schon die Big Tech-Vendors natürlich, die ihre eigenen Interessen natürlich auch ein bisschen umgesetzt haben möchten. Sei es, dass es doch noch irgendwo in den Secure Enclave von MacBooks vielleicht eine Backdoor gibt oder so und die muss auch irgendwie abgebildet sein in diesem RFC, weil wenn sich dann Apple plötzlich an den RFC beteiligen muss und den implementieren muss, dann kann das natürlich auch für Apple vielleicht Millionen kosten oder Milliarden sogar. Und deshalb steigen die natürlich sehr gerne damit ein, also nicht nur Apple, auch Google und Microsoft und so weiter, senden quasi Vertreter aus und die arbeiten dann in sogenannten Taskforce-Gruppen oder Working Groups dann an dem entsprechenden RFC. Das ist immer ein bisschen schwierig natürlich, weil es gibt meistens auch natürlich jemanden dabei, der wirklich nur Goodwill ist, der wirklich einfach nur die Menschheit ein bisschen sicherer machen möchte. In der Webwelt. Und dann kommt man natürlich da ein bisschen oder stößt man natürlich ein bisschen auf Widerstand, weil dann natürlich Google, Microsoft und wie sie alle heißen, da vielleicht ein bisschen dagegen wirken. Eins der zum Beispiel größten oder der größten Probleme war tatsächlich damals der Umstieg von OAuth 1 auf OAuth 2.0. Ich hatte ja schon angedeutet, dass OAuth 1 dieses coole Sender Constraining eigentlich mit drin hat, dass man halt den Access Token nicht einfach so senden kann, sondern der muss immer irgendwie an den Client gebunden sein, kryptografisch. Und jetzt kam halt tatsächlich, nachdem Twitter aufkam, kam natürlich da auch Apple und Microsoft dazu und haben gesagt, jetzt wollen wir aber dieses Internet weiter voranbringen. Wir wollen Webseiten weiter voranbringen. Und in so einem Browser kann ich nicht so richtig standaktuell Sender-Constraining umsetzen, weil Sender-Constraining würde ja bedeuten, dass ich vielleicht auch so eine Art, Private Key dann im Browser habe, mit dem ich dann den Token vielleicht signiere, und ein Private Key einfach so im Browser zu haben. Also mittlerweile ist das möglich. Es gibt so eine Web-Crypto-API. Mittlerweile geht es, aber damals hat man halt keine Möglichkeit gehabt für sowas. Und dann hat halt tatsächlich Apple und Google gesagt, wir entfernen das Ganze. Wir entfernen das Ganze, Sender-Constraining einfach und machen das zu Bearer-Tokens. Haben also ihren Willen durchgebracht, nur damit sie halt mehr in dieser Webwelt flexibler ihre Interessen durchdrücken können. Und das hat halt sogar dazu geführt, dass der ursprüngliche Gründer von OAuth, der hat eine riesige Hasstirade tatsächlich in einem Artikel verfasst. Das nennt sich OAuth 2, Road to Hell. Wie schlimm jetzt das ist, dass die Vendors tatsächlich da in Spezifikationen eingreifen, dass jetzt dieses ganze Kryptografische wegfällt und damit, landen wir halt dabei, dass wir Autorisierung, Authentifizierung weitaus unsicherer machen. Jetzt kann man natürlich nochmal den Bogen spannen auf die OWASP Top Ten. Das ist so eine coole Liste, wo quasi die gängigsten Angriffsszenarien aufgelistet sind, was so die größten Schwachstellen sind heutzutage in Web-Anwendungen. Und die kommt alle vier Jahre raus. Und seit 2021 ist Platz, also auch davor schon, aber ist Platz 1 Broken Access Control. Also quasi genau das ein bisschen, was er vorausgesagt hat, dass Broken Access Control, dass halt der Token gestohlen wurde, dass einfach, Token irgendwo hingesendet wurde, die werden nicht richtig überprüft, weil man halt diese ganze Kryptografie letztendlich entfernt hat. Aber um wieder den ganzen Bogen zurückzuspannen, also ja, es gibt dann immer diese Taskforce und die kümmert sich halt um die Spezifikationen, aber klar mischen da die großen Big Tech Companies halt mit, um auch ihre eigenen Interessen durchzudrücken.

Ali Das ist bei solchen Standards ja durchaus immer eine Schwierigkeit, die man auch in der Open-Source-Community viel sieht von Leuten, die etwas aus Idealismus anfangen oder weil sie eine Idee haben und dann kommen die Leute, die damit ein Produkt machen wollen. Und dann entsteht natürlich auch dieses, wenn Apple es schafft, vor Google einen entsprechenden Service anzubieten, der viel reibungsloser ist, ist das für sie ein Marktvorteil. Und dieses, man arbeitet schon zusammen, aber man hat ja nicht unbedingt das gleiche Interesse, nämlich wir machen das Internet sicher, sondern man hat immer noch im Hinterkopf das Interesse, die Leute sollen meine und nicht deine Produkte kaufen. Das ist hochkompliziert und ich finde es immer spannend, wenn man sieht, wer auf solchen entsprechenden Konferenzen, Panels und so weiter und so fort als Sponsoren auftaucht und man sieht, da ist dann teilweise komplett Big Tech vertreten und dann schaffen sie es irgendwie hier an einem Strang zu ziehen und dann fehlt auffällig einer wie zum Beispiel Microsoft oder Amazon und man fragt sich, warum? Also profitieren die jetzt nur von dem neuen Standard, der hier ausgearbeitet wird und warum unterstützen sie ihn nicht oder haben sie selbst was, das sie da gerade kochen? Also da gibt es, ich glaube, man könnte einen kompletten Gossip-Podcast machen, nur um szeneninterne Streitigkeiten bei der Weiterentwicklung von Standards.

Martina Ja, absolut. Es gibt ja auch, jetzt fange ich später damit an, aber es gibt ja auch einen relativ langen, ausführlichen Blogartikel, wie Apple es fast geschafft hätte, Passkeys zu töten, eben weil sie sich nicht so richtig an den Standard, der geschrieben wurde, gehalten haben und ihr eigenes Süppchen gekocht haben. Was halt dann in dem Moment bedeutet, dass wenn ich ein Passkey halt anlege in Apple, in meiner iCloud Keychain oder auf dem Gerät, dass ich den halt definitiv nicht synchronisiert bekomme mit anderen, mit Google oder wie auch immer. Ja. Und glücklicherweise hat sich das mittlerweile wieder ein bisschen geregelt, aber sie hätten es halt beinahe leider geschafft, halt Passkeys wieder aussterben zu lassen, bevor es richtig im Kommen war letztendlich.

Ali Eine Sache, mit der ich dann das Ganze auch abbinden würde, du hattest RFCs gerade erwähnt und in deinem Buch, in deinem Schlusswort, in deiner Danksagung, da schreibst du auch, es gibt all diese RFCs, also die Anleitungen, wie das Ganze technisch gedacht ist und wie das Ganze umzusetzen ist, aber aus denen ergibt sich jetzt noch nicht direkt ein Lehrbuch, mit dem man versteht, was das Ganze ist. Und das Buch, das du geschrieben hast über Authentifizierung und Autorisierung im Rheinwerk Verlag, das befasst sich ja damit, genau das zu sein. Ein Lehrbuch, ein Nachschlagewerk für etwas, das an sich sehr technische Beschreibungen sind. Was hast du selbst bei dem Verfassen dieses Buchs nochmal über die entsprechenden RFCs gelernt?

Martina Das ist tatsächlich eine sehr gute Frage, denn ich muss auch sagen, bevor ich das Buch geschrieben habe, habe ich nicht jeden RFCs von oben nach unten durchgelesen. Mittlerweile dann schon, weil ich würde natürlich das Buch schon richtig schreiben. Aber das war tatsächlich sehr interessant, gerade OAuth 2 hat halt irgendwie 15 verschiedene RFCs letztendlich. Was ich glaube ich daraus gezogen habe, ist, dass es, wie du auch gesagt hast, es steht halt irgendwie eine Spezifikation drin und es gibt vor allen Dingen im deutschsprachigen Raum aber auch nichts so in die Richtung, jetzt erkläre ich es euch mal, wie das funktioniert. Und viele Entwickler und Entwicklerinnen wollen halt einfach einen Authorization-Server anbinden und wollen einfach nur so einen Access-Token haben. Und das leider so ein heikles Thema ist und es aber leider keine vernünftigen Ressourcen dazu gibt, wie man es richtig macht, außer die RFCs. Neigt man halt dazu, wild rumzuklicken und Trial and Error und halt zu gucken, okay, jetzt habe ich endlich den Access-Token. Sehr gut. Ich habe irgendeiner dieser Flows ausgewählt, auch wenn es vielleicht ein unsicherer war, aber mir jetzt gerade egal, weil ich habe zwei Tage lang damit rumgemacht, so ein Access-Token zu bekommen und damit übertreibe ich tatsächlich nicht. Und dann ist natürlich auch das Problem, dass alle Identity Provider, die auch ein bisschen unterschiedlich implementieren, also kein Identity Provider implementiert die RFCs zu 100 Prozent. Und sprich, selbst wenn man jetzt die RFCs liest, ist nicht sichergestellt, dass das jetzt eins zu eins das ist, was man jetzt in Keycloak, in Entra ID, wie auch immer vorfindet, weil die dann doch wieder so ein bisschen gesagt haben, wir wissen es aber besser und wir machen es vielleicht ein bisschen anders. Es gibt zum Beispiel nicht den Token Exchange Flow in Entra ID, der heißt OBO Flow on behalf of User. Und der ist ein eigenkreierter Flow, weil sie halt gesagt haben, der RFC ist noch nicht so weit und deshalb machen wir jetzt schon mal wieder, unser eigenes Süppchen. Und was ich halt mit dem Buch versucht habe, ist auch die Unterschiede aufzuweisen. Also gerade in dem Implementierungskapitel habe ich halt auch riesige Tabellen gemacht, um die gängigsten Identity Provider, wie heißt der Flow da, was muss man dafür konfigurieren, damit man diesen Flow einsetzen kann. Und das Wichtigste, wenn man sich aber ein bisschen mit den RFCs beschäftigen möchte, ist man, glaube ich, gut damit geraten, nur noch den OAuth 2.1 RFC durchzulesen und nach alles, was dort beschrieben ist an Requirements and Should Have, Must Have, dass man sich eher daran hält, weil OAuth 2.1 ist keine wirkliche Weiterentwicklung, sondern mehr so die Zusammenfassung von, allem, was man aus OAuth 2.0 gelernt hat.

Ali Alles klar. Ich glaube, wir haben für das Buch, das ja doch sehr, sehr technisch ist, ein Nachschlagewerk, ich glaube, wir haben ein sehr gutes Gespräch darüber zusammenbekommen, warum es sich lohnt, reinzuschauen, warum der eine oder andere da vielleicht noch etwas ausgiebig lernt über die RFCs, die man sonst nur als Handlungsanweisung und nicht als Lehrbuch benutzen kann. Danke für deine Zeit.

Martina Ja, sehr gerne. Hat mir super viel Spaß gemacht.