WEBVTT 00:00:00.017 --> 00:00:03.877 Was mir persönlich immer geholfen hat, ist, wenn ich auch verstanden habe, 00:00:04.177 --> 00:00:06.361 wie die Dinge im Hintergrund funktionieren. 00:00:06.750 --> 00:00:10.557 Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja, 00:00:10.557 --> 00:00:15.977 du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach, 00:00:15.977 --> 00:00:21.089 jetzt, um im OAuth-Kontext zu bleiben, den Authorization Code Flow mit PKCE verwenden. 00:00:21.681 --> 00:00:24.487 Dann bist du sicher. Damit habe ich irgendwie immer Probleme, 00:00:24.487 --> 00:00:27.777 weil ich irgendwie gerne auch wissen würde, warum denn? 00:00:28.117 --> 00:00:32.484 Also warum ist das jetzt wichtig, dass ich diese Erweiterung nutze? 00:00:32.966 --> 00:00:36.297 Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch 00:00:36.297 --> 00:00:40.117 zu schreiben und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level 00:00:40.117 --> 00:00:43.517 als dann auch sehr detailreich geschafft, um halt klarzumachen, 00:00:43.877 --> 00:00:52.854 wie die ganzen sogenannten Flows, wie die halt genau funktionieren. 00:00:53.807 --> 00:00:57.777 Hallo und herzlich willkommen zu Klüger als gestern. Mein Name ist Ali Hackalife, 00:00:57.777 --> 00:01:02.010 das ist ein Rheinwerk-Podcast und heute darf ich mit Martina Kraus sprechen. 00:01:02.341 --> 00:01:06.224 Sie hat ein Buch geschrieben über Authentifizierung und Autorisierung, 00:01:06.388 --> 00:01:11.071 was dahinter steckt und was es da zu lernen gibt, das besprechen wir heute. Hallo Martina. 00:01:11.641 --> 00:01:14.137 Hallo, ja, danke für die Einladung, ich freue mich sehr. 00:01:14.711 --> 00:01:18.267 Wie kommt es, dass du ein Buch zu diesem Thema schreibst, bei dem ich am Anfang 00:01:18.267 --> 00:01:21.537 gedacht habe, wie füllt man dazu so viele Seiten? Ich habe dein Buch gelesen, 00:01:21.537 --> 00:01:25.477 ich verstehe, wie man dazu so viele Seiten füllt, aber wie bist du zu IT-Security 00:01:25.477 --> 00:01:27.012 und diesem speziellen Thema gekommen? 00:01:27.791 --> 00:01:33.470 Ja, tatsächlich, seit Beginn habe ich mich generell für Security interessiert, 00:01:33.470 --> 00:01:38.490 habe dann auch Informatik studiert, bin dann in die Web-Entwicklung letztendlich 00:01:38.490 --> 00:01:42.762 reingekommen und darüber dann auch in das ganze Thema Web-Security. 00:01:43.220 --> 00:01:46.300 Und da hat sich schon ein bisschen herausgestellt, dass mich das ganze Thema 00:01:46.620 --> 00:01:51.915 Authentifizierung, Autorisierung, vor allem weil es erstmal so komplex erscheint, 00:01:52.432 --> 00:01:57.360 mich wahnsinnig interessiert und ich liebe es tatsächlich nichts mehr als komplexe 00:01:57.360 --> 00:02:02.800 Themen so einfach wie möglich darzustellen, damit sie auch jeder und jede verstehen kann. 00:02:02.800 --> 00:02:08.380 Und so bin ich auch mal dabei gelandet, für einen führenden Identity Provider, 00:02:08.380 --> 00:02:12.540 der das Ganze also auch wirklich implementiert, zu arbeiten und konnte da halt 00:02:12.540 --> 00:02:17.196 mein Wissen rund um Authentifizierung und Autorisierung zu vertiefen. 00:02:17.323 --> 00:02:21.390 Und ja, und umso mehr hat es mich dann gefreut, als ich gefragt wurde, 00:02:21.390 --> 00:02:25.381 ob ich mein Wissen auch in ein Buch teilen darf. Und da habe ich natürlich sofort Ja gesagt. 00:02:26.437 --> 00:02:29.780 Ich habe dein Buch in Vorbereitung auf die Sendung gelesen und ich hatte so 00:02:30.100 --> 00:02:33.570 grob im Hinterkopf, also ich bin IT-Autodidakt, ich mache das auch irgendwie 00:02:33.570 --> 00:02:37.710 seit 15 Jahren mittlerweile und ich hatte im Kopf, ja, es gibt da was mit Tokens 00:02:37.710 --> 00:02:40.790 und dann gibt es hier und da einen Handshake und die überprüfen sich gegenseitig. 00:02:40.790 --> 00:02:43.910 Aber wie das im Detail funktioniert, das war sowas, wo ich immer wusste, 00:02:43.910 --> 00:02:46.070 wo ich nachschaue, aber es nie nachgeschaut habe. 00:02:46.337 --> 00:02:51.640 Und du gehst in deinem Buch ja sehr detailreich durch, was überhaupt der Vorteil 00:02:51.640 --> 00:02:57.610 von verschiedenen Systemen ist, wie zum Beispiel OAuth 2 und dem OpenID Connect 00:02:57.610 --> 00:03:00.060 System und wo die Anwendung finden. 00:03:00.060 --> 00:03:03.280 Und ich habe sehr viel darüber verstanden, was im Hintergrund passiert und vor 00:03:03.280 --> 00:03:06.090 allem was in einer wahnsinnigen Geschwindigkeit im Hintergrund passiert und 00:03:06.090 --> 00:03:10.508 worüber man ja gar nicht so nachdenkt. Also diese Mechanismen sind ja allgegenwärtig. 00:03:10.937 --> 00:03:14.400 Und ich habe dann auch nochmal separat ein bisschen in der Historie gegraben 00:03:14.400 --> 00:03:18.260 und was ich nicht wusste, wie neu das alles ist. Und vor allem OAuth, 00:03:18.260 --> 00:03:23.847 das erste, ist von Leuten von Ma.gnolia und Twitter zusammen entwickelt worden. 00:03:24.219 --> 00:03:27.319 Also Twitter war mal wirklich der Innovationsort fürs Internet. 00:03:27.928 --> 00:03:31.678 Dann stellt sich ja direkt die Frage, ich habe doch einen Benutzernamen und ein Passwort. 00:03:31.864 --> 00:03:35.195 Wofür brauche ich denn was anderes? Was können Benutzernamen und Passwort nicht, 00:03:35.195 --> 00:03:37.385 was diese ganzen OAuth-Systeme können? 00:03:38.691 --> 00:03:42.238 Einer der größten Herausforderungen, die halt da durch Twitter kam, 00:03:42.568 --> 00:03:49.815 war die Einbindung von sogenannter Third-Party-Software oder Third-Party-Quellen, also Bilder 00:03:50.215 --> 00:03:56.035 oder URLs oder Videos von YouTube, von vielleicht Google, vielleicht auch etwas, 00:03:56.035 --> 00:03:57.753 was den Google-Kalender betroffen hat. 00:03:58.374 --> 00:04:03.335 Und man musste dann halt Twitter die Berechtigung geben, auf vielleicht meinen 00:04:03.335 --> 00:04:06.809 Google-Account zuzugreifen, auf mein YouTube-Profil zuzugreifen. 00:04:07.262 --> 00:04:12.355 Und das hat tatsächlich die Internetwelt vor ganz großen Problemen gestoßen, 00:04:12.355 --> 00:04:18.181 weil wie macht man das? Ich muss ja irgendwie Twitter jetzt meinen Nutzername und Passwort geben. 00:04:18.367 --> 00:04:22.365 Klar, dann bin ich in Twitter eingeloggt, aber ich müsste ja jetzt Twitter meinen 00:04:22.365 --> 00:04:27.555 Nutzername und Passwort geben, damit Twitter sich in meinem Namen jetzt auf 00:04:27.555 --> 00:04:30.095 YouTube oder irgendeine andere, 00:04:30.615 --> 00:04:34.336 Webseite, um mal vielleicht Bilder davon zu laden, einloggen zu können. 00:04:35.033 --> 00:04:41.458 Damit Twitter eben diese Bilder oder Medien anzeigen kann. Also diese Weitergabe 00:04:41.458 --> 00:04:43.026 von Zugriffsberechtigung. 00:04:43.444 --> 00:04:47.218 Und da ist dann halt Nutzernamen und Passwörter an ihre Grenzen gestoßen, 00:04:47.218 --> 00:04:51.498 weil ich finde es persönlich natürlich nicht so cool, wenn ich jetzt Twitter 00:04:51.818 --> 00:04:56.522 meinen Nutzernamen und Passwort gebe, um vielleicht auf YouTube zugreifen zu können. 00:04:56.928 --> 00:05:00.408 Und ich weiß ja auch nicht, was Twitter vielleicht mit den Nutzernamen und Passwort macht. 00:05:00.408 --> 00:05:05.118 Und da hat dann halt sich ganz schnell herausgestellt, wir brauchen irgendetwas, 00:05:05.118 --> 00:05:09.571 was wir Access Delegation nennen, also die Weitergabe von Zugriffsrechten, 00:05:09.885 --> 00:05:14.528 dass ich Twitter einfach sagen kann, ja, liebes Twitter, du darfst jetzt genau 00:05:14.528 --> 00:05:16.717 auf diese Medien zugreifen, 00:05:17.280 --> 00:05:20.748 und dann darfst du sie anzeigen, aber sonst darfst du auch nichts mehr machen. 00:05:20.748 --> 00:05:24.228 Also du darfst nicht irgendwelche anderen Bilder laden oder du darfst da nicht 00:05:24.228 --> 00:05:29.208 in meinem Namen des Google-Accounts auf irgendwelche Inhalte oder meine E-Mails 00:05:29.208 --> 00:05:34.167 zugreifen, sondern wirklich nur sehr dediziert, um zum Beispiel ein Bild anzuzeigen in Twitter. 00:05:35.392 --> 00:05:39.531 Und dieses Weiterleiten von diesen sehr spezifischen Zugriffsrechten, 00:05:39.879 --> 00:05:43.968 dafür brauche ich dann mehr als Nutzername und Passwort und da kommen dann Tokens 00:05:43.968 --> 00:05:47.586 beziehungsweise die OAuth Mechanismen zum Greifen? 00:05:48.399 --> 00:05:52.738 Absolut richtig, genau. Denn, also da greift mir jetzt schon ein bisschen viel 00:05:52.738 --> 00:05:57.298 vor, aber quasi, wenn ich mich in so einem Identity Provider einlogge, 00:05:57.483 --> 00:05:59.846 dann erhalte ich diesen sogenannten Access Token. 00:06:00.235 --> 00:06:05.657 Und da steht halt ganz genau drin, welche Berechtigungen jetzt dieses Token hat. 00:06:05.860 --> 00:06:10.626 Das ist auch völlig losgelöst dann letztendlich von dem Nutzer oder Nutzerin. 00:06:10.922 --> 00:06:17.648 Jeder, der eigentlich dieses Token dann hat, und darf eben auf die APIs, 00:06:17.648 --> 00:06:21.148 auf die Daten, auf die Services zugreifen mit den Berechtigungen, 00:06:21.148 --> 00:06:24.198 die eben letztendlich in diesem Token vorhanden sind. 00:06:24.691 --> 00:06:29.742 Wer sind solche Identity Provider? Also wer bestätigt, dass das gerade eine echte Identität ist? 00:06:30.914 --> 00:06:34.935 Das können zum Beispiel Google sein. Es gibt Google Identity. 00:06:35.695 --> 00:06:40.968 Wir haben aber auch Entra ID, kennt man wahrscheinlich. Früher hieß das Azure, Microsoft Azure AD. 00:06:41.497 --> 00:06:44.566 Wir haben aber auch Open Source Lösungen wie zum Beispiel Keycloak. 00:06:45.037 --> 00:06:49.475 Man kann aber auch ganz verrückt sein und das quasi selbst implementieren. 00:06:49.475 --> 00:06:55.915 Da bietet zum Beispiel Java Spring Security, die bieten sogar eigene Bibliotheken 00:06:55.915 --> 00:06:59.735 an, um quasi so einen Identity Provider zu implementieren. 00:07:00.205 --> 00:07:03.525 Konkret würde ich davon aber abraten, da gibt es einfach zu viel, 00:07:03.525 --> 00:07:05.540 was man leider falsch machen kann. 00:07:06.161 --> 00:07:10.405 Ich würde da eher auf sogenannte Identity-as-a-Service-Lösungen, 00:07:10.405 --> 00:07:15.635 wie sie halt von auch zum Beispiel Auth0 oder Okta oder Entra ID angeboten werden 00:07:16.053 --> 00:07:17.455 oder zumindest halt so eine, 00:07:18.455 --> 00:07:23.059 Self-Hosting-Lösung, wie sie zum Beispiel von Keycloak angeboten wird, zurückgreifen. 00:07:23.262 --> 00:07:29.925 Das ist ja generell bei Security ein riesiges Thema, wo ich auch in meiner IT-Karriere 00:07:29.925 --> 00:07:33.165 sehr oft drüber gestolpert bin, dass Leute sagen, die Kryptografie dafür, 00:07:33.165 --> 00:07:35.695 das machen wir einfach selbst, anstatt diese Library zu benutzen, 00:07:35.695 --> 00:07:36.544 dann sind wir unabhängig. 00:07:36.759 --> 00:07:40.095 Und das war in der Regel immer der Schuss in den Fuß. Also es ging danach nie 00:07:40.095 --> 00:07:45.335 besser, weil es gibt einen Grund, dass sich da große Industriestandards etabliert 00:07:45.335 --> 00:07:47.242 haben und nicht alle ihre eigene Suppe kochen. 00:07:48.297 --> 00:07:54.328 Absolut. Also es betrifft auch hier natürlich nicht nur OAuth oder OpenID Connect, 00:07:54.665 --> 00:07:57.248 wenn ich auch beispielsweise meine Passwörter hashen möchte. 00:07:57.591 --> 00:08:02.167 Da gibt es bestehende Algorithmen, also bestehende Hash-Funktionen wie beispielsweise 00:08:02.167 --> 00:08:05.973 scrypt oder Argon2 und die will ich auch gar nicht selbst implementieren. 00:08:06.887 --> 00:08:12.657 Da gibt es Leute, Kryptografen, die haben sich darüber Gedanken gemacht, 00:08:12.657 --> 00:08:16.127 haben dazu mathematische Paper verfasst und sehr clevere Menschen, 00:08:16.127 --> 00:08:20.447 viel cleverere Menschen als ich es bin definitiv, haben diese Hash-Algorithmen 00:08:20.447 --> 00:08:21.763 dann auch implementiert. 00:08:22.245 --> 00:08:25.857 Ja, um mal einen Begriff in den Raum zu werfen. Bei elliptischer Kryptografie 00:08:25.857 --> 00:08:28.915 sitze ich immer davor und habe das Gefühl, jemand erzählt mir gerade etwas, 00:08:29.106 --> 00:08:32.340 das ist so sci-fi, dass ich beeindruckt bin, dass Menschen das können. 00:08:32.775 --> 00:08:35.997 Aber ich habe großen Respekt davor und ich bin einfach froh, 00:08:35.997 --> 00:08:38.731 dass ich nur eine Library einbinden muss und das nicht verstehen muss. 00:08:39.206 --> 00:08:42.851 Aber zum Thema Verstehen. Du sagtest gerade, Passworte hashen. 00:08:43.466 --> 00:08:48.647 Warum ist in der Moderne, wir haben jetzt das mit dem ein anderer Anbieter möchte, 00:08:49.047 --> 00:08:53.087 Daten durchleiten können, beziehungsweise Zugriffe minimal gewährleisten, 00:08:53.087 --> 00:08:54.557 auf spezielle Dinge angerissen. 00:08:54.557 --> 00:08:57.657 Aber warum reicht es nicht mehr, dass ich sage, ich habe Nutzernamen und Passwort 00:08:57.657 --> 00:09:00.427 und meinetwegen ist das Passwort noch gehasht. Das heißt, Twitter selbst hat 00:09:00.427 --> 00:09:03.801 mein Passwort gar nicht im Klartext da liegen oder beliebiger anderer Online-Dienst 00:09:03.941 --> 00:09:05.496 hat mein Passwort gar nicht mehr im Klartext da liegen. 00:09:05.787 --> 00:09:10.297 Welche anderen Vorteile bringen mir Möglichkeiten wie OAuth dabei, 00:09:10.297 --> 00:09:13.670 wenn ich mich mit einer Plattform verbinde oder Plattform untereinander verbinde? 00:09:14.947 --> 00:09:21.154 Also, da muss man tatsächlich etwas differenzieren, weil OAuth beschäftigt sich 00:09:21.154 --> 00:09:24.810 gar nicht so mit der Frage Nutzername, Passwort. 00:09:25.814 --> 00:09:30.522 OAuth ist per se ein reines Autorisierungsframework. 00:09:31.247 --> 00:09:36.794 In OAuth ist gar nicht bestimmt, wie sich dieser Nutzer jetzt eigentlich authentifiziert. 00:09:36.794 --> 00:09:40.434 Also der kann sich dann mit dem Nutzername Passwort authentifizieren, 00:09:40.434 --> 00:09:44.724 der kann sich mit einem Passkey authentifizieren, mit einem zweiten, 00:09:44.724 --> 00:09:46.832 dritten, fünften Faktor, wie auch immer. 00:09:47.268 --> 00:09:49.990 Das ist in OAuth selbst gar nicht beschrieben. 00:09:50.513 --> 00:09:56.974 Was OAuth letztendlich eigentlich nur beschreibt ist, wie erhält jetzt ein Nutzer 00:09:56.974 --> 00:10:01.614 oder Nutzerin, nachdem er oder sie sich identifiziert hat, nachdem das quasi 00:10:01.614 --> 00:10:04.474 geklärt ist, jetzt einen Token, 00:10:05.112 --> 00:10:10.610 um dann mit diesem Token eben, in dem gewisse Berechtigungen drinstehen, 00:10:11.028 --> 00:10:16.212 dann letztendlich die richtigen APIs, die richtigen Services aufrufen kann. 00:10:16.699 --> 00:10:22.649 Und dabei ist ganz klar beschrieben, was halt in diesem Access-Token drinsteht. 00:10:23.714 --> 00:10:25.194 Dass dieser wirklich nur für 00:10:25.194 --> 00:10:29.684 eine Teilmenge von Berechtigung oder auch für eine Teilmenge an Services. 00:10:29.684 --> 00:10:34.474 Ich kann nicht mit dem einen Access-Token jetzt eine Google API aufrufen und 00:10:34.474 --> 00:10:38.774 mit demselben Access-Token vielleicht dann noch einen anderen Service aufrufen, 00:10:38.774 --> 00:10:41.368 um gegebenenfalls davon noch Bilder zu laden. 00:10:41.745 --> 00:10:45.461 Und das ist halt, wie gesagt, ganz streng getrennt voneinander. 00:10:46.012 --> 00:10:51.564 Und Authentifizierung, wie das Ganze vonstatten geht, darum kümmert sich tatsächlich 00:10:51.564 --> 00:10:53.194 eigentlich eher dann OpenID Connect. 00:10:54.215 --> 00:10:56.862 Jetzt hast du gerade gesagt einen zweiten, dritten oder fünften Faktor. 00:10:57.721 --> 00:11:00.544 Um das hier nochmal kurz anzureißen, du und ich, wir wissen was damit gemeint 00:11:00.544 --> 00:11:05.194 ist, viele Nutzer sind bestimmt schon mal über den Second Factor oder Two Factor 00:11:05.194 --> 00:11:08.054 Authentication gestolpert, die ja mittlerweile immer gängiger wird, 00:11:08.553 --> 00:11:13.064 wo ich auch sagen muss, SMS ist ein wahnsinnig schlechter Second Factor, weil 00:11:13.564 --> 00:11:17.534 mir so passiert, mein Telefonanbieter hat, nachdem ich den Vertrag gelöscht 00:11:17.534 --> 00:11:19.246 habe, die Nummer nicht mehr angeboten und 00:11:19.786 --> 00:11:22.424 stellt sich raus, das war zu einem meiner GitHub-Accounts 00:11:23.004 --> 00:11:26.054 der Second Factor, dass ich eine SMS an dieser Handynummer bekommen kann und 00:11:26.054 --> 00:11:27.338 dann habe ich mich da ausgeschlossen. 00:11:27.709 --> 00:11:32.274 Und dann steht GitHub da als Plattform, die dir sagt, ja, also wir können die 00:11:32.274 --> 00:11:34.834 nicht verändern, das musst du schon können. Und mein Telefonprovider sagt, 00:11:34.834 --> 00:11:37.274 ja, die Nummer ist in unserem Pool, die können wir nicht nochmal vergeben, 00:11:37.274 --> 00:11:38.662 auch nicht, wenn du ganz lieb bitte sagst. 00:11:38.993 --> 00:11:43.004 Also bei der Frage, was sind weitere Faktoren, können wir vielleicht nochmal 00:11:43.004 --> 00:11:46.744 reingehen und erklären, bei dem, was die meisten Leute als Second Factor kennen, 00:11:46.744 --> 00:11:49.974 wie sieht das idealerweise aus? Da gibt es ja Unterscheidungen zwischen etwas, 00:11:49.974 --> 00:11:51.944 das ich habe, etwas, das ich weiß und so weiter. 00:11:53.209 --> 00:11:57.684 Genau, ja. Das, was du natürlich beschreibst, ist wirklich so das Worst-Case-Szenario. 00:11:57.684 --> 00:12:02.244 Aber auch wie du schon richtig gesagt hast, dieser SMS-Code gilt eigentlich 00:12:02.244 --> 00:12:05.597 als so das Unsicherste, was man nutzen kann. 00:12:05.754 --> 00:12:11.768 Was man normalerweise nutzt, sind sogenannte Authenticators auf dem Smartphone. 00:12:12.180 --> 00:12:17.344 Die werden beispielsweise von Microsoft oder Google angeboten oder auch natürlich 00:12:17.344 --> 00:12:22.258 hat jedes Betriebssystem sowie Android oder auch iOS ihre eigenen Authenticators. 00:12:22.774 --> 00:12:27.128 Und letztendlich kann ich damit eben mein Account verknüpfen. 00:12:27.546 --> 00:12:34.551 Und was dann eigentlich passiert ist, dass auf meinem Smartphone wird quasi ein Code generiert. 00:12:35.446 --> 00:12:40.247 Und das ist meistens so ein sechsstelliger Code und der ist dann für 60 Sekunden dann gültig. 00:12:40.886 --> 00:12:44.891 Und immer wenn ich mich eingeloggt habe mit Nutzername und Passwort, 00:12:45.164 --> 00:12:49.093 werde ich eben nach diesem zweiten Faktor, nach diesem Code gefragt. 00:12:49.093 --> 00:12:55.677 Und das ist meistens etwas, was ich habe. Also das kategorisiert man in diese 00:12:55.851 --> 00:12:58.138 zweite Faktorkategorie etwas, das ich habe. 00:12:58.695 --> 00:13:04.053 Es gibt natürlich auch die Möglichkeit, etwas, was ich bin, das wäre dann, 00:13:04.053 --> 00:13:08.313 dass der zweite Faktor tatsächlich eine Art Gesichtserkennung ist oder auch 00:13:08.313 --> 00:13:11.669 meine biometrischen Daten, also mein Fingerprint zum Beispiel, 00:13:12.087 --> 00:13:15.286 dass wenn ich mich zum Beispiel auf meinem Smartphone irgendwie einlogge, 00:13:15.477 --> 00:13:17.413 dass mein Smartphone mich dann auch nur fragt. 00:13:18.473 --> 00:13:24.661 Bitte gebe mir noch einen zweiten Faktor als dein Fingerprint halt letztendlich zur Verfügung. 00:13:25.493 --> 00:13:32.653 Was es natürlich auch noch gibt, ist die IP-Adresse oder auch mein Standort, wo ich gerade bin. 00:13:32.909 --> 00:13:38.029 Da können dann sehr viele verschiedene Arten als sogenannter zweiter Faktor zugezogen werden. 00:13:38.470 --> 00:13:43.323 Aber klar, am besten eignet sich halt eben etwas Biometrisches, 00:13:43.323 --> 00:13:49.193 also wirklich so Iris-Scan, wie man es so aus James-Bond-Filmen kennt. 00:13:50.293 --> 00:13:53.772 Dass man dann jemanden vielleicht den Fingerabdruck klaut. 00:13:54.433 --> 00:13:58.243 Sowas ist natürlich in der reellen Welt, kommt nicht so häufig vor. 00:13:58.243 --> 00:14:01.208 Es gibt natürlich immer eine kleine Möglichkeit. 00:14:01.458 --> 00:14:05.434 Man darf keine absoluten Aussagen treffen in der Sicherheit. 00:14:06.020 --> 00:14:09.163 Aber ja, also sowas, was eher so nur in James-Bond-Filmen vorkommt, 00:14:09.163 --> 00:14:11.349 ist ja in der Realität nicht immer ganz so gängig. 00:14:11.819 --> 00:14:16.753 Und deshalb ist gerade so biometrische zweite Faktoren oder auch natürlich diesen 00:14:16.753 --> 00:14:19.621 Code, von dem ich anfänglich gesprochen habe, am sichersten. 00:14:20.213 --> 00:14:23.971 Also biometrische Faktoren sind natürlich beliebt, haben nur einen großen Nachteil. 00:14:23.971 --> 00:14:28.111 Wenn sie einmal in die Öffentlichkeit gelangen, kann man sie nicht mehr ändern. 00:14:28.111 --> 00:14:31.727 Ich kann meinen Fingerabdruck, meine Iris oder mein Gesicht nicht so ohne weiteres ändern. 00:14:32.221 --> 00:14:36.301 Und dementsprechend, ich erinnere mich da sehr prominent an eine Pressekonferenz, 00:14:36.301 --> 00:14:41.501 bei der Ursula von der Leyens Daumen mit einem Teleobjektiv fotografiert wurde und von, 00:14:42.041 --> 00:14:46.261 ich glaube Schäuble war es, gibt es ein Wasserglas, von dem nach der Bundespressekonferenz 00:14:46.261 --> 00:14:50.750 mal mit Talgpulver einfach ein Negativ vom Finger runtergepinselt wurde, um zu zeigen, 00:14:51.122 --> 00:14:55.313 die Menschen, die sich hier dafür einsetzen, dass biometrische Daten in, 00:14:55.464 --> 00:14:57.861 ich glaube Reisedokumente war es, damals verpflichtend reinkommen. 00:14:58.041 --> 00:15:01.246 Wenn deren eigene Daten dann in die Öffentlichkeit geraten, sind sie ganz alert. 00:15:01.635 --> 00:15:03.781 Wo ich sagen muss, ich kann das auch schon verstehen. Ich fände es auch nicht 00:15:03.781 --> 00:15:06.111 schön, wenn mein Fingerabdruck öffentlich rumgereicht werden würde, 00:15:06.111 --> 00:15:10.251 aber da ist halt das Problem. Wenn diese Form der Verifizierung einmal bekannt 00:15:10.251 --> 00:15:13.959 ist, ist sie nicht komplett wertlos, aber ein Angriffsvektor. 00:15:14.713 --> 00:15:18.911 Ja klar, das ist auf jeden Fall ein guter Punkt und deshalb bevorzuge ich, 00:15:18.911 --> 00:15:22.671 wenn man noch Nutzername und Passwort benutzt, als zweiten Faktor eben halt 00:15:22.671 --> 00:15:26.341 diesen sechs- oder fünfstelligen Code, je nach Authenticator, 00:15:26.781 --> 00:15:28.127 den man dann eingeben muss. 00:15:30.001 --> 00:15:33.482 Wenn wir generell gerade ein bisschen davon sprechen, von Authentifizierung, 00:15:33.482 --> 00:15:38.721 gibt es ja noch eine weitere Möglichkeit, die ganz von Nutzername und Passwort 00:15:38.721 --> 00:15:42.221 mittlerweile absieht und das sind die sogenannten Passkeys. 00:15:42.221 --> 00:15:47.325 Oh ja, bin ich großer Freund von. Und hast du auch in deinem Buch angeschnitten. 00:15:47.499 --> 00:15:50.971 Ich finde, die Idee dahinter ist so schön, dass man gar nicht mehr sagt, 00:15:50.971 --> 00:15:54.076 ich gebe dir als Website, als Anbieter 00:15:54.552 --> 00:15:57.871 die Informationen, mit denen ich mich authentifiziere, sondern ich gebe dir 00:15:57.871 --> 00:16:01.391 im Prinzip ein Schloss in die Hand, zu dem ich den Schlüssel halte und du prüfst 00:16:01.391 --> 00:16:02.801 nur, ob ich das Schloss aufschließen kann. 00:16:03.736 --> 00:16:06.666 Das ist so eine elegante Lösung, die sich sehr zeitgemäß anfühlt. 00:16:06.666 --> 00:16:07.961 Also ich bin großer Passkey-Fan. 00:16:08.431 --> 00:16:13.096 Ich auch tatsächlich. Also ich reise viel auf Konferenzen und rede eigentlich 00:16:13.096 --> 00:16:19.266 nur über Passkeys, weil das für mich so die bislang jetzt vielversprechendste 00:16:19.266 --> 00:16:22.648 Variante ist, um sich auch sicher authentifizieren zu können. 00:16:23.019 --> 00:16:26.506 Aber wie gesagt, das sind alles so auch Dinge, weil zum Beispiel Passkeys, 00:16:26.506 --> 00:16:30.158 das hat gar nichts mehr mit OpenID Connect oder OAuth zu tun. 00:16:30.443 --> 00:16:35.586 Das ist zum Beispiel in der FIDO2-Allianz, das ist Fast Identity Online, 00:16:35.586 --> 00:16:39.636 das ist quasi eine eigene Gruppierung, die sich zusammengefunden hat, 00:16:39.636 --> 00:16:43.858 um einfach passwortlose Authentifizierung zu ermöglichen. 00:16:44.253 --> 00:16:49.706 Und darüber könnte man auch stundenlang natürlich reden. Aber OIDC und OAuth beschäftigt 00:16:49.706 --> 00:16:51.979 sich quasi so ein bisschen mit den Schritten danach. 00:16:52.432 --> 00:16:56.675 Also womit sich dann OIDC, also OpenID Connect noch beschäftigt, 00:16:56.832 --> 00:17:01.906 ist beispielsweise auch diese Identity Federation, wie man es auch so gerne 00:17:01.906 --> 00:17:06.486 nennt, dass ich beispielsweise mich auch einfach mit Google einloggen kann. 00:17:06.828 --> 00:17:11.596 Man kennt es ja vielleicht, man ist auf irgendeiner Webseite und dann bekomme 00:17:11.596 --> 00:17:16.896 ich die Möglichkeit, mich über vielleicht damals auch noch Twitter-Account oder 00:17:16.896 --> 00:17:20.946 auch Facebook-Account, GitHub oder auch eben mit Google einloggen zu können. 00:17:20.946 --> 00:17:26.111 Das heißt, ich brauche gar nicht eine wirkliche Registrierung auf diesem Service, 00:17:26.413 --> 00:17:32.676 sondern ich kann mich einfach dann einloggen mit eben Google oder auch von mir aus auch meinem, 00:17:33.416 --> 00:17:37.181 iCloud Keychain Passwort, also meiner Apple ID ist das dann. 00:17:38.096 --> 00:17:41.727 All die Möglichkeiten, das ist tatsächlich auch in OIDC beschrieben worden. 00:17:42.528 --> 00:17:45.658 Und das führt natürlich dazu, wenn ich dann den Service wieder besuche, 00:17:45.658 --> 00:17:49.407 dann kann ich einfach nur auf Login with Google quasi drücken. 00:17:49.668 --> 00:17:53.888 Dann werde ich vielleicht kurz zu Google redirected und muss mich dann gegebenenfalls 00:17:53.888 --> 00:17:57.487 nochmal gegenüber Google authentifizieren. Aber das ist dann das Wilde. 00:17:57.946 --> 00:18:01.318 Ich sehe dann gar nicht so richtig, was passiert, weil wenn ich dann auf Login 00:18:01.318 --> 00:18:04.898 with Google drücke, dann sieht man, dass in dieser Browser-Adresszeile wilde 00:18:04.898 --> 00:18:07.042 Dinge passieren und dann bin ich plötzlich eingeloggt. 00:18:07.605 --> 00:18:11.468 Und genau diese wilden Dinge, die da hinten dran passieren, das ist halt letztendlich 00:18:11.468 --> 00:18:14.386 auch, was in OIDC so genau spezifiziert ist. 00:18:14.925 --> 00:18:18.598 Bevor wir da im Detail drauf eingehen, es gibt natürlich die valide Kritik, 00:18:18.598 --> 00:18:24.508 dass bei den Sign-in-with-Buttons, dass man sich da mehr und mehr abhängig von Big Tech macht. 00:18:24.508 --> 00:18:28.488 Also ich selbst bin im Apple-Ökosystem, ich habe einige Services, 00:18:28.488 --> 00:18:31.596 bei denen ich Sign in with Apple angeklickt habe für die Convenience, vor allem wenn man 00:18:31.939 --> 00:18:34.968 mal was nur schnell ausprobieren möchte und man möchte sich jetzt nicht einen 00:18:34.968 --> 00:18:37.788 Account anlegen, wobei das ja auch mittlerweile immer einfacher geworden ist, 00:18:37.788 --> 00:18:41.111 aber es gibt dann noch einige Services, wo ich Sign in with Apple angeklickt habe. 00:18:41.360 --> 00:18:45.698 Wenn ich jetzt sagen würde, ich möchte Open Source gehen, ich verlasse macOS, 00:18:45.698 --> 00:18:49.478 dann wäre das schon eine ziemliche Arbeit, all meine Accounts aufzuspüren, 00:18:49.478 --> 00:18:53.008 in denen ich Sign in with Apple angeklickt habe und da neue Credentials zu hinterlegen, 00:18:53.008 --> 00:18:54.079 um die Accounts zu behalten. 00:18:54.415 --> 00:18:58.903 Also das kommt natürlich auch mit seinem Preis, dass man entsprechend diese Services vorschickt. 00:18:59.721 --> 00:19:04.258 Absolut. Und ein weiterer Punkt ist natürlich, angenommen, ich habe jetzt überall 00:19:04.658 --> 00:19:09.568 mich eingeloggt mit Google, wenn dann jemand mal mein Google-Passwort hat und 00:19:09.568 --> 00:19:12.980 vielleicht keinen zweiten Faktor hat, das ist nicht ausreichend geschützt und so weiter. 00:19:14.547 --> 00:19:18.308 Und die Person, der Angreifer, die Angreiferin sich dann in meinen Google-Account 00:19:18.308 --> 00:19:21.788 einloggen kann, dann kann die Person sich natürlich ebenfalls in alle, 00:19:21.788 --> 00:19:26.018 alle, alle anderen Services automatisch einloggen, weil ich ja überall Login 00:19:26.018 --> 00:19:27.212 mit Google geklickt habe. 00:19:27.548 --> 00:19:31.358 Das heißt, es ist nicht ganz so von der Hand zu weisen, dass es natürlich ein 00:19:31.358 --> 00:19:32.686 paar Risiken mit sich bringt. 00:19:33.725 --> 00:19:38.386 Wo wir natürlich erneut zu dem Punkt kommen, einfach Passkeys zu benutzen, für jeden Service einen. 00:19:38.938 --> 00:19:41.874 Aber wie du schon gesagt hast, das ist ja auch eine Art Convenience. 00:19:42.354 --> 00:19:45.967 Und ich bin in beiden oder in vielen Ecosystemen unterwegs. 00:19:46.316 --> 00:19:49.854 Glaube zwar eher so ein bisschen in den Google-Ecosystemen, aber dadurch, 00:19:49.854 --> 00:19:52.928 dass ich auch Mac habe, habe ich auch viel in meiner iCloud Keychain, 00:19:53.351 --> 00:19:56.634 dass es so ein bisschen verteilt ist. Aber ja, man macht sich absolut abhängig 00:19:56.634 --> 00:19:58.390 von den ganzen Vendors auf jeden Fall. 00:19:59.627 --> 00:20:03.144 Jetzt hatten wir, bevor wir auf dieses Detail eingegangen sind, 00:20:03.487 --> 00:20:06.344 noch darüber gesprochen. Du meintest, da passiert da ganz viel ganz schnell 00:20:06.344 --> 00:20:09.019 in deiner Adresszeile und du bekommst das gar nicht so im Detail mit. 00:20:09.600 --> 00:20:13.044 Das gehst du ja in deinem Buch wirklich mal im Detail nach. 00:20:13.044 --> 00:20:19.114 Wer da an wen, wo, wie eine Information weiterleitet, die dann von wem wie bestätigt 00:20:19.114 --> 00:20:23.443 und validiert und weitergereicht wird, sodass die Services im Zweifel nur wissen, 00:20:23.635 --> 00:20:26.590 ist es ein legitimer Zugriff und nicht mehr über mich wissen müssen. 00:20:27.781 --> 00:20:32.884 Ja, genau, weil für mich ist es ganz wichtig. Oder was mir persönlich immer 00:20:32.884 --> 00:20:38.293 geholfen hat, ist, wenn ich auch verstanden habe, wie die Dinge im Hintergrund funktionieren. 00:20:38.694 --> 00:20:42.494 Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja, 00:20:42.494 --> 00:20:47.914 du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach, 00:20:47.914 --> 00:20:53.032 jetzt, um im OAuth-Kontext zu bleiben, den Authorization-Codeflow mit PKCE verwenden. 00:20:53.665 --> 00:20:56.414 Dann bist du sicher. Ja, damit habe ich irgendwie immer Probleme, 00:20:56.414 --> 00:20:59.704 weil ich irgendwie gerne auch wissen würde, warum denn? 00:21:00.044 --> 00:21:06.244 Also es ist jetzt vielleicht aufwendiger, diese Erweiterung PKCE noch zu verwenden, 00:21:06.544 --> 00:21:09.164 weil ich das irgendwie auch konfigurieren muss und ich will doch einfach nur 00:21:09.164 --> 00:21:10.244 ein Access-Token haben. 00:21:10.569 --> 00:21:14.412 Warum ist das jetzt wichtig, dass ich diese Erweiterung nutze? 00:21:14.952 --> 00:21:18.764 Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch zu schreiben. 00:21:18.764 --> 00:21:22.624 Und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level als dann 00:21:22.624 --> 00:21:29.057 auch sehr detailreich geschafft, um halt klarzumachen, wie die ganzen sogenannten Flows, 00:21:29.631 --> 00:21:35.570 da kann ich gleich dazu kommen, was die genau bedeuten, und wie die halt genau funktionieren. 00:21:36.029 --> 00:21:41.724 Ein großes Problem oder eins der größten Probleme, die OAuth löst oder versucht 00:21:41.724 --> 00:21:48.800 zu lösen, ist eben, ich habe jetzt eine Webseite und in dieser Webseite möchte ich mich einloggen. 00:21:49.374 --> 00:21:55.364 Diese Webseite möchte natürlich auch Daten haben und diese Daten sollen ja geschützt 00:21:55.364 --> 00:21:58.524 sein mit so einem Access, also mit einem Access-Token, sprich, 00:21:59.044 --> 00:22:01.304 wenn diese Webseite Daten braucht. 00:22:01.930 --> 00:22:08.259 Angenommen, wir sind vielleicht auf einer Shop-Webseite, wo ich irgendwie einkaufen 00:22:08.259 --> 00:22:12.629 kann und dann sollen mir ja quasi die ganzen Produkte angezeigt werden. 00:22:12.629 --> 00:22:16.314 Das heißt, ich rufe in den meisten Fällen so eine Art Produkt-API auf. 00:22:16.645 --> 00:22:20.189 Ich will ja vielleicht aber jetzt auch meinen Warenkorb sehen und ich will jetzt 00:22:20.189 --> 00:22:24.089 natürlich nur die Produkte angezeigt bekommen, die ich jetzt bereits in den 00:22:24.089 --> 00:22:26.687 Warenkorb gelegt habe oder die ich bereits eingekauft habe. 00:22:26.850 --> 00:22:30.443 Auch wenn ich meine Rechnungen einsehen will, das soll ja alles beschützt sein. 00:22:30.786 --> 00:22:33.665 Deshalb muss ich an diese API so einen Access-Token senden. 00:22:34.095 --> 00:22:38.861 Jetzt ist es aber gar nicht so einfach, an diesen Access-Token zu kommen. 00:22:39.366 --> 00:22:46.679 Denn wie schaffe ich denn es sicher, meinem Authorization-Server zum einen natürlich 00:22:46.679 --> 00:22:49.299 zu beweisen, dass ich ich bin. 00:22:49.839 --> 00:22:54.575 Okay, da gibt es so dieses Nutzername-Passwort. Okay, das funktioniert dann schon. 00:22:54.795 --> 00:22:58.656 Aber dann, nachdem ich mich erfolgreich vielleicht authentifiziert habe, 00:22:59.021 --> 00:23:04.879 muss ja dieser Identity Provider irgendwie jetzt diesen Access Token wieder 00:23:04.879 --> 00:23:09.267 zurücksenden an meinen Browser, damit der das halt weiterverarbeiten kann. 00:23:09.639 --> 00:23:13.079 Und dieses Zurücksenden, das hat wahnsinnig. 00:23:13.899 --> 00:23:20.289 Viele Risiken und Probleme, weil sich da eben Angreifer und Angreiferinnen theoretischerweise 00:23:20.289 --> 00:23:27.191 relativ einfach dazwischen schalten können und so tun können gegenüber diesem Identity Provider. 00:23:27.376 --> 00:23:31.239 Ja, ja, du kannst den Token an mich senden und nicht an das, 00:23:31.239 --> 00:23:34.799 was du hast für eine Anfrage bekommen von so einem anderen Browser, 00:23:34.799 --> 00:23:37.013 aber sende mal den Token bitte an mich. 00:23:37.407 --> 00:23:42.899 Und da gibt es viele verschiedene Angriffsszenarien und deshalb macht es es 00:23:42.899 --> 00:23:44.832 eben auch so kompliziert, weil... 00:23:45.709 --> 00:23:51.077 Ein Hauptproblem, kurz noch der eine Satz dazu, ein Hauptproblem ist, 00:23:51.997 --> 00:23:56.647 dass ich halt als Browser kann ich dem Authorization Server oder auch Identity 00:23:56.647 --> 00:24:02.219 Provider genannt, nicht sagen, guck mal, hier, ich bin der legitime Client, 00:24:02.521 --> 00:24:04.203 mir darfst du den Access Token geben. 00:24:04.897 --> 00:24:09.178 Meine Client-Application, meine heutzutage Single-Page-Application, 00:24:09.538 --> 00:24:13.267 kann sich ja nicht authentifizieren gegenüber dem Authorization-Server. 00:24:13.267 --> 00:24:17.247 Der kann ja nicht sagen, guck mal, ich bin der richtige Client, 00:24:17.247 --> 00:24:20.026 der liebe Client, mir kannst du den Access-Token jetzt geben. 00:24:20.386 --> 00:24:24.142 Wie soll das funktionieren, wenn ich ein Secret oder so ein Passwort 00:24:24.502 --> 00:24:29.447 halt in meiner Single-Page-Application speichere, dann kann die natürlich jeder 00:24:29.447 --> 00:24:33.277 einsehen, weil das liegt dann im JavaScript rum, es ist dann im Browser ausgeliefert 00:24:33.637 --> 00:24:37.064 und das kann natürlich jeder über die Dev-Konsole letztendlich auslesen. 00:24:37.857 --> 00:24:42.294 Ab dem Moment, wo ich im Browser im Cookie hinterlege, ich bin vertrauenswürdig, 00:24:42.521 --> 00:24:47.339 ist das etwas, was andere Leute im Prinzip lokal selbst reinschreiben könnten oder eben ablesen. 00:24:48.697 --> 00:24:54.009 Genau, nicht nur in dem Cookie. Der Cookie ist nochmal ein bisschen anders tatsächlich. 00:24:54.287 --> 00:24:58.746 Der Cookie ist schon beschützt durch gewisse andere Maßnahmen, 00:24:59.349 --> 00:25:05.787 aber der Cookie hilft uns gar nicht so viel, weil der Cookie darf halt nur immer 00:25:06.194 --> 00:25:12.195 an dieselbe Domäne mitgesendet werden, wie von der Domäne, die den Cookie gesetzt hat. 00:25:12.462 --> 00:25:17.376 Also zum Beispiel authserver.com. Wenn mein authserver.com mir ein Cookie setzt, 00:25:17.376 --> 00:25:21.709 dann wird der Cookie ja nur mitgesendet, wenn ich ein Request an authserver.com sende. 00:25:22.562 --> 00:25:27.646 Hauptsächlich, also damit das funktioniert, irgendwie würde das nur möglich 00:25:27.646 --> 00:25:32.546 sein, dass ich irgendwie ein Secret in mein JavaScript lege und da kann ich 00:25:32.546 --> 00:25:34.434 es natürlich jederzeit auslesen. 00:25:34.817 --> 00:25:38.723 Aber klar, theoretischerweise, wenn ich das Secret auch so in den Cookie speichere 00:25:39.066 --> 00:25:42.586 und das Secret ist immer gleich, was es halt vielleicht sein muss dann für den 00:25:42.586 --> 00:25:46.326 Client, dann kann ich auch den Cookie natürlich über die Developer-Konsole mal 00:25:46.326 --> 00:25:49.106 kurz öffnen und auch reingucken und das auslesen. 00:25:50.212 --> 00:25:55.648 Und jetzt hattest du vorhin gesagt, die Flows im Hintergrund seien interessant. 00:25:55.648 --> 00:26:02.308 Also ich denke, es ist nachvollziehbar, dass es ein Problem ist bei diesen Großanwendungen, 00:26:02.308 --> 00:26:06.268 also zum Beispiel beliebiger Online-Webshop, wo es relativ reibungslos sein muss. 00:26:06.622 --> 00:26:10.588 Und natürlich im Hochsicherheitsbereich würde man das Ganze anders regeln, 00:26:10.588 --> 00:26:15.598 dass man sagt, was hier untereinander spricht, das hat alles Zertifikate, die entweder, also 00:26:16.298 --> 00:26:20.808 das kann man ja beliebig komplex denken, dass ich darkside alle Zertifikate 00:26:20.808 --> 00:26:24.495 nur aus diesem Gebäude heraus vergeben habe mit Geräten, die physisch vor Ort waren. 00:26:24.796 --> 00:26:27.488 Da kann ich mir relativ sicher sein, dass die Geräte, die sich da zurückmelden 00:26:27.488 --> 00:26:30.381 mit dem entsprechenden Zertifikat, die Geräte sind, die ich rausgegeben habe. 00:26:30.717 --> 00:26:33.951 Aber ab dem Moment, wo ich das on scale mache, wie ein 00:26:34.578 --> 00:26:38.808 großer beliebiger Online-Shop, der ja nicht mit den Leuten vorher noch Zertifikate 00:26:38.808 --> 00:26:41.548 austauschen kann in Person, ab da an brauche ich ja andere Wege, 00:26:41.548 --> 00:26:46.048 um sicher zu gehen, dass meine Rücksendung auch bei einem entsprechenden Browser 00:26:46.048 --> 00:26:48.008 ankommt und nicht unterwegs abgegriffen werden kann. 00:26:48.008 --> 00:26:51.290 Also da gibt es auch in der Wikipedia beschrieben 00:26:51.581 --> 00:26:55.928 ein potenzielles Angriffsszenario und man versucht ja Man-in-the-Middle zu umgehen, 00:26:55.928 --> 00:26:58.860 aber wenn ich bei den Authentifizierungsservern 00:26:59.133 --> 00:27:02.488 Schad-Server dabei habe, wie gesagt, große Diagramme, komplizierte Angriffe, 00:27:02.488 --> 00:27:05.138 ich bin froh, dass die Wikipedia das sehr vereinfacht hat, aber da gibt es ja 00:27:05.138 --> 00:27:08.228 durchaus Probleme, dass da nicht ganz klar ist, an wen schicke ich jetzt zurück. 00:27:08.466 --> 00:27:11.488 Ich kann nicht ohne weiteres als Authentifizierungsserver bestätigen, 00:27:11.488 --> 00:27:14.078 dass der, dem ich gerade die Authentifizierung erteilt habe, 00:27:14.078 --> 00:27:15.275 der ist, der sie angefordert hat. 00:27:16.036 --> 00:27:21.857 Ja, also absolut richtig. Und das ist halt hauptsächlich, wie gesagt, 00:27:21.857 --> 00:27:25.974 eins der größten Probleme bei den Single-Applications, die wir heutzutage haben. 00:27:27.408 --> 00:27:32.017 Es gibt natürlich auch Szenarien, wo wir Microservices haben, 00:27:32.017 --> 00:27:34.902 wo ein Server mit einem anderen Server irgendwie redet. 00:27:35.279 --> 00:27:39.407 Meistens ist man ja so mittlerweile, dass man so seine ganze Web-Applikation 00:27:39.407 --> 00:27:43.117 so ein bisschen schneidet, vertikal und es gibt verschieden, 00:27:43.117 --> 00:27:45.119 für jede Domäne gibt es einen eigenen Microservice. 00:27:45.606 --> 00:27:49.473 Und klar, wenn ich dann Daten anfrage, die über mehrere Microservices gehen, 00:27:49.809 --> 00:27:53.617 dann müssen die ja auch miteinander reden, dass alle Daten zusammen kumuliert 00:27:53.617 --> 00:27:56.977 werden und halt als eine Datenmenge vielleicht wieder zurückgegeben werden. 00:27:56.977 --> 00:28:01.797 Das wäre zumindest ganz nett, dass ich nicht als Client alle Microservices einzeln aufrufen muss. 00:28:02.313 --> 00:28:07.137 Und da kommt es natürlich auch zu Trage, dass sich ein Microservice auch einen 00:28:07.137 --> 00:28:11.761 Access-Token holt, damit dieser sich natürlich auch ausweist als, 00:28:11.953 --> 00:28:16.910 hey, guck mal, ich habe die Berechtigung und darf jetzt auf deinen Daten ebenfalls zugreifen. 00:28:17.294 --> 00:28:22.877 Der größte Vorteil ist halt daran, dass ich, wenn ich in der Backend-Welt bin, 00:28:22.877 --> 00:28:28.907 hinter gesicherten Firewalls, es zumindest weitaus ungefährlicher ist, 00:28:28.907 --> 00:28:30.857 dass jetzt ein Backend natürlich. 00:28:32.317 --> 00:28:34.947 Eine kleine ID und einen kleinen Secret nennt sich das dann, 00:28:34.947 --> 00:28:39.010 also halt ein Secret letztendlich speichere, um sich damit halt ein Token zu holen. 00:28:39.451 --> 00:28:43.307 Und das ist in diesen sogenannten Flows niedergeschrieben. 00:28:43.307 --> 00:28:45.988 Das ist auch eigentlich ein guter Einstieg vielleicht mal da rein, 00:28:46.307 --> 00:28:52.197 denn so ein Backend, da gibt es dann wie gesagt einen Microservice und der agiert 00:28:52.197 --> 00:28:55.380 jetzt als ein OAuth-Client, weil er Daten haben möchte. 00:28:55.827 --> 00:28:57.998 Und dieser Microservice, der 00:28:58.688 --> 00:29:04.143 nimmt jetzt einen speziellen Flow, der nennt sich Client-Credentials-Flow. 00:29:04.509 --> 00:29:08.438 Der macht nichts anderes, als einmal zum Authorization-Server zu gehen und zu 00:29:08.438 --> 00:29:11.382 sagen, hey, guck mal, ich habe hier ein Client-ID, Client-Secret, 00:29:11.707 --> 00:29:15.637 ich möchte mit dem Microservice sprechen, bitte stelle mir so einen Access-Token aus. 00:29:16.026 --> 00:29:20.688 Und dieser Flow ist super einfach und super simpel, weil dann der Authorization-Server 00:29:20.688 --> 00:29:25.488 sagt, okay, ich kenne dich, du hast mir dein richtiges Passwort verraten, also dieses Secret, 00:29:25.988 --> 00:29:30.178 Und ich schreibe eben dein Target Service, wo du Daten haben möchtest, 00:29:30.178 --> 00:29:34.898 auch noch als eine Audience, also damit auch klar ist, für wen das Token bestimmt 00:29:34.898 --> 00:29:37.858 ist, in den Token rein und dann hast du den Access Token. 00:29:37.858 --> 00:29:41.028 Und das ist alles super simple und alles super cool. 00:29:41.638 --> 00:29:45.771 Aber wie gesagt, das geht halt nicht so einfach in Single-Page-Application. 00:29:46.235 --> 00:29:50.578 Und was ich immer, wenn ich über OAuth rede, dann liebe ich es immer zu sagen, 00:29:50.578 --> 00:29:53.508 dass es halt bei OAuth rund irgendwie, 00:29:54.088 --> 00:30:03.198 sieben Flows gibt und fünf davon sind nur alleine für Single-Page-Applications oder für das Web. 00:30:03.198 --> 00:30:06.208 Sagen wir mal, das hat nicht gestimmt, Single-Page-Application nicht, 00:30:06.208 --> 00:30:09.788 aber für die Web-Applikation, dass man 00:30:10.088 --> 00:30:14.365 als Web-Applikation ebenfalls ein Access-Token holen kann, was halt die, 00:30:14.948 --> 00:30:19.114 Schwierigkeit und die Irrsinnigkeit vielleicht auch ein bisschen am besten beschreibt dafür natürlich. 00:30:20.309 --> 00:30:24.188 Das ist durchaus sehr nachvollziehbar. Vor allem, wir leben ja mittlerweile 00:30:24.188 --> 00:30:29.518 in einer Welt, wo Web-Apps omnipräsent sind und Dinge werden zu immer kruderen, 00:30:29.518 --> 00:30:33.005 einfach nur anders ausgespielten Websites, wenn man mal wirklich tief gräbt. 00:30:33.469 --> 00:30:36.408 Und dementsprechend, ich verstehe, dass da so ein großer Fokus drauf liegt. 00:30:36.408 --> 00:30:38.328 Ich verstehe, dass das große Probleme mit sich bringt. 00:30:38.856 --> 00:30:43.953 Du sagtest gerade, der Authentication-Server kann das sehr einfach dann bestätigen. 00:30:44.487 --> 00:30:51.180 Und ein Begriff, der in deinem Buch auch vorkommt, zum Thema Einfaches bestätigen, das ist Zero Trust. 00:30:51.372 --> 00:30:54.668 Und Zero Trust ist eine der Sachen, ich weiß nicht, ob es da auch Anwendung findet. 00:30:55.337 --> 00:30:57.160 Im Zweifel musst du mich da korrigieren. 00:30:57.582 --> 00:31:00.828 Na klar, also Zero Trust ist eigentlich ja genau das. 00:31:01.448 --> 00:31:04.687 Also Zero Trust gibt es in verschiedenen Ebenen, 00:31:05.648 --> 00:31:10.578 also dass ich als Server auch keinem Client vertraue, aber Zero Trust ist oftmals 00:31:10.578 --> 00:31:12.828 eigentlich so in der Microservice-Welt, 00:31:13.408 --> 00:31:17.868 bedeutet letztendlich, dass ich natürlich auf jeden Fall immer auch mit einem 00:31:17.868 --> 00:31:22.828 Access-Token an Inter-Service-Kommunikation letztendlich halt haben muss, 00:31:22.828 --> 00:31:24.581 dass ich da auch immer ein Access-Token haben muss. 00:31:24.958 --> 00:31:28.818 Und natürlich auch TLS, also dass auch die Services untereinander immer nur 00:31:28.818 --> 00:31:33.399 verschlüsselt sprechen, dass ich halt nur, weil ich vielleicht im selben Netzwerk bin, 00:31:33.963 --> 00:31:37.460 dass ich halt nicht einfach belanglos jetzt jedem Service vertraue, 00:31:37.460 --> 00:31:38.870 der meine Daten haben möchte. 00:31:39.570 --> 00:31:43.670 Wo du TLS sagst, also Transportverschlüsselung. OAuth in der ersten Version 00:31:43.670 --> 00:31:48.690 war noch für HTTP entwickelt und dementsprechend ohne Transportverschlüsselung 00:31:48.690 --> 00:31:52.237 in mind. Und da sind wir jetzt auch, wie gesagt, 2007 entwickelt. 00:31:52.521 --> 00:31:54.251 Da hat sich ja auch mittlerweile viel getan. 00:31:54.658 --> 00:32:00.580 Ja, klar. Also OAuth 2 setzt auf jeden Fall TLS voraus. OAuth 1 hatte halt 00:32:00.580 --> 00:32:08.918 so ein bisschen noch den Vorteil, dass wir so etwas hatten, was sich Sender-Constrained-Tokens nennt. 00:32:10.150 --> 00:32:17.080 Also dass das Token quasi hochkryptografisch gebunden ist und klar ist, 00:32:17.405 --> 00:32:21.910 ich klar verifiziere als Empfänger des Tokens, der den Token dann auswertet, 00:32:22.328 --> 00:32:27.425 ganz klar verifizieren kann, dass der Token auch vom richtigen Sender kommt. 00:32:27.837 --> 00:32:32.820 Da konnte ich nicht einfach so ein Token mal austauschen, sage ich mal, 00:32:32.820 --> 00:32:38.150 oder an jemanden geben und die Person kann dann mit ihrem Client und dem Token 00:32:38.150 --> 00:32:39.963 irgendwie mal eine Anfrage senden. 00:32:40.207 --> 00:32:45.043 Das wäre auf keinen Fall gegangen, weil das halt kryptografisch an den Absender gebunden ist. 00:32:45.223 --> 00:32:49.220 Und das hat man auch Sender-Constraining genannt. Und das ist etwas, 00:32:49.220 --> 00:32:56.071 was man halt mit OAuth 2 absolut entfernt hat. Da gibt es kein Sender-Constraining mehr. 00:32:56.408 --> 00:33:00.883 Da ist dann das entstanden, was man auch vielleicht kennt, das nennt sich dann Bearer-Token. 00:33:01.278 --> 00:33:07.397 Also der Träger des Tokens, der ist legitimiert, einfach jetzt die Anfrage zu senden. 00:33:08.760 --> 00:33:13.243 Das bringt natürlich das Problem auf sich, wenn ich so eine schöne Cross-Site-Scripting-Attacke 00:33:13.243 --> 00:33:18.463 auf meiner Webseite habe und mein Access-Token liegt vielleicht in einem Speicher 00:33:18.463 --> 00:33:20.997 im Webbrowser, der über JavaScript zugänglich ist, 00:33:21.502 --> 00:33:24.950 wie beispielsweise der wunderschöne Local oder Session Storage, 00:33:25.408 --> 00:33:30.337 dann könnte ich halt mit so einer Cross-Site-Scripting-Attacke diesen Access-Token stehlen. 00:33:30.859 --> 00:33:37.198 Und wenn ich ihn gestohlen habe, dann kann ich halt einfach so den Access-Token selbst verwenden. 00:33:37.744 --> 00:33:39.263 Der hat eine gewisse Gültigkeit. 00:33:40.484 --> 00:33:43.665 Eigentlich soll er meistens so fünf bis 15 Minuten lang gültig sein. 00:33:44.008 --> 00:33:48.363 Aber 15 Minuten, wenn ich ihn dann bereits nach zwei Minuten gestohlen habe, 00:33:48.363 --> 00:33:49.952 dann habe ich noch 13 Minuten Zeit. 00:33:50.405 --> 00:33:54.543 Damit kann ich halt schon noch einiges anstellen und auch machen im Namen des 00:33:54.543 --> 00:33:55.947 Nutzers oder der Nutzerin. 00:33:56.377 --> 00:34:01.113 Wir hatten ja gerade Zero Trust auch beschrieben und Zero Trust ist so eine 00:34:01.113 --> 00:34:04.973 der Sachen, da gibt es schöne, einfache Schaubilder zu, über die ich mich sehr 00:34:04.973 --> 00:34:07.650 gefreut habe und wenn man dann das erste Mal die Mathematik dahinter sieht, 00:34:07.847 --> 00:34:09.560 dann bin ich wirklich sehr beeindruckt. 00:34:09.885 --> 00:34:13.033 Ich weiß nicht, wie tief du da mal gegraben hast. Also ich finde Zero Trust 00:34:13.033 --> 00:34:16.926 zu erklären ist gar nicht so schwer, aber Zero Trust nachzubauen ist, 00:34:17.896 --> 00:34:21.629 oh mein Gott, was hat die Menschheit da geschafft, das ist im Prinzip die nächste Mondlandung. 00:34:22.766 --> 00:34:28.391 Auf jeden Fall. Und es ist halt noch komplizierter, das auch umzusetzen und 00:34:28.391 --> 00:34:33.407 so diszipliniert umzusetzen. Und klar gibt es Lösungen, die das anbieten. 00:34:34.144 --> 00:34:38.671 Aber Zero Trust bedeutet halt auch Performance-Einbußen. Und das ist halt natürlich 00:34:38.671 --> 00:34:43.252 etwas, was viele gerade in der sehr schnelllebigen Webwelt, 00:34:44.164 --> 00:34:50.131 deshalb doch nicht implementieren wollen, also Zero Trust dann nicht so durchgängig 00:34:50.131 --> 00:34:54.041 implementieren wollen, weil sie halt sagen, das ist zu viel Kryptografie. 00:34:54.041 --> 00:35:00.191 Kryptografie sind performanceintensive Operationen und deshalb ist es nur so 00:35:00.191 --> 00:35:03.464 ein halbes Zero Trust, das oftmals implementiert wird. 00:35:03.876 --> 00:35:07.961 Also in der Idealvorstellung bedeutet Zero Trust jetzt hier einmal im Schaubild 00:35:07.961 --> 00:35:11.417 gesprochen, das macht dann auch verständlich, was eins der Performance-Probleme ist, 00:35:11.951 --> 00:35:18.011 dass ich dem Anbieter gegenüber gar nicht beweisen muss, dass ich weiß, 00:35:18.011 --> 00:35:22.741 was er weiß, sondern es gibt dieses Schaubild von, es gibt eine Felswand, 00:35:22.741 --> 00:35:25.601 in der es sind ganz viele Höhlen und Höhleneingänge und ein paar von denen sind 00:35:25.601 --> 00:35:26.463 miteinander verbunden. 00:35:27.038 --> 00:35:32.721 Und der Anbieter weiß, dass es einen direkten Weg gibt von der Höhle 1 zu der Höhle 2 00:35:33.390 --> 00:35:37.034 und ich zeige ihm jetzt, dass ich diesen Weg kenne, indem ich in die eine Höhle 00:35:37.034 --> 00:35:38.626 rein und aus der anderen Höhle rauskomme. 00:35:39.154 --> 00:35:42.434 Aber es gibt hunderte mögliche Höhlenein- und -ausgänge. Das heißt, 00:35:42.434 --> 00:35:46.694 es reicht nicht, wenn ich auf Verdacht sage, übrigens der Eingang ist der da 00:35:46.694 --> 00:35:50.714 oben links und der Ausgang ist der da unten rechts, weil es könnten ganz viele andere Wege sein. 00:35:51.054 --> 00:35:53.584 Ganz viele von diesen Höhlen sind theoretisch nicht miteinander verbunden. 00:35:53.584 --> 00:35:57.544 Also ich muss sehr spezifisch beweisen, ich kenne Ein- und Ausgang und wie ich 00:35:57.544 --> 00:36:00.944 zwischendrin belege, dass ich den Weg zwischen denen kenne, muss der Anbieter, 00:36:00.944 --> 00:36:05.420 der verifiziert, gar nicht wissen. Für den reicht es, dass ich performen kann. 00:36:05.780 --> 00:36:09.002 Ich kenne die Start- und die Endbedingungen und dazwischen kann ich nur über 00:36:09.402 --> 00:36:11.875 komplizierte Kryptografie wirklich den Weg gefunden haben. 00:36:12.224 --> 00:36:16.314 Das zu erraten, ist halt so ein klassisches Problem von, wenn man das bruteforced, 00:36:16.314 --> 00:36:19.234 sind wir schnell an dem Punkt von, so viel Zeit hat das Universum nicht oder 00:36:19.234 --> 00:36:21.430 es ist für die Anwendung nicht relevant, wenn man sagt, 00:36:21.906 --> 00:36:24.904 Bruteforce ist möglich, aber bei der aktuellen Rechenleistung bräuchtest du 00:36:24.904 --> 00:36:29.006 1,5 Millionen Jahre, ist das ein Risiko, das man eingehen kann. 00:36:29.319 --> 00:36:33.975 Hat aber das Problem, dass wenn ich anfange zu bruteforcen, der Authentifizierungsserver 00:36:34.271 --> 00:36:36.599 erstmal damit überlastet ist, dass er die ganze Zeit sagen muss, 00:36:36.959 --> 00:36:39.754 nee, das war nicht richtig, auch hier wieder nicht richtig, auch hier wieder 00:36:39.754 --> 00:36:42.288 nicht richtig, ich mache die Session mal zu, neue Session kommt auf, 00:36:42.520 --> 00:36:44.344 oh, du hast wieder mehrfach falsch angefragt. 00:36:44.344 --> 00:36:47.544 Und das sind halt solche Probleme, die dann on scale dazu führen, 00:36:47.544 --> 00:36:50.734 dass man als Anbieter, der mit Zero Trust verifizieren möchte, 00:36:50.734 --> 00:36:53.874 schnell das Problem läuft, dass wenn man angegriffen wird, man einfach sehr 00:36:53.874 --> 00:36:56.746 viele Ressourcen darauf werfen muss, dass jemand gerade versucht einzubrechen. 00:36:57.449 --> 00:37:03.494 Ja, genau. Und wie du schon beschrieben hast, das sind halt super viele komplexe, 00:37:03.954 --> 00:37:08.194 kryptografische Fahnen dahinter, es gibt aber tatsächlich also Zero Trust ist 00:37:08.194 --> 00:37:11.769 ja auch mehr ist ja kein Produkt in dem Sinne ist ja kein, 00:37:12.754 --> 00:37:17.882 etwas was man jetzt konkret anwenden kann, sondern ist ja mehr so ein Gedankenmodell, 00:37:18.276 --> 00:37:19.714 was man dann halt letztendlich, 00:37:20.796 --> 00:37:22.434 umsetzen kann, muss, 00:37:24.354 --> 00:37:28.006 mit dem Nachteil dann natürlich, dass wir vielleicht ein bisschen Performance einbüßen müssen. 00:37:28.929 --> 00:37:32.898 Jetzt hast du in deinem Buch am Ende ein Fazit geschrieben, in dem es darum 00:37:32.898 --> 00:37:38.048 geht, wie sich die Moderne umsetzt. Also du hast moderne Ansätze und Standards 00:37:38.048 --> 00:37:42.448 beschrieben, praktische Umsetzungen davon, wo man anfängt, wie man die umsetzen kann. 00:37:42.919 --> 00:37:46.688 Und du machst auch einen Zukunftsausblick und der de facto Standard im Moment, 00:37:46.688 --> 00:37:50.668 den beschreibst du ja auch. Und ein Kapitel, das JSON-Web-Token. 00:37:50.668 --> 00:37:54.823 Ich denke, wir kommen nicht drum herum zu beschreiben, warum das gerade so wichtig ist. 00:37:55.729 --> 00:38:00.431 Ja, JSON-Web-Tokens sind tatsächlich einfach erstmal komplett losgelöst von OAuth. 00:38:00.826 --> 00:38:05.808 OAuth selbst sagt sogar, dass die Access-Tokens gar nicht JSON-Web-Tokens sein 00:38:05.808 --> 00:38:10.418 müssen, sondern das können auch sogenannte Opaque-Tokens, nennen sich dann also 00:38:10.418 --> 00:38:12.703 einfach nur Reference-Tokens in dem Sinne. 00:38:13.301 --> 00:38:17.678 Aber in den meisten Fällen oder nahezu immer ist ein Access-Token halt so ein JSON-Web-Token. 00:38:18.043 --> 00:38:23.788 Und das Coole an so einem JSON-Web-Token ist halt, dass es self-contained ist 00:38:23.788 --> 00:38:26.646 und man kann es verifizieren. Was bedeutet das? 00:38:27.618 --> 00:38:32.318 Da müssen wir vielleicht einen kleinen Zurückschwenker zu cookiebasierter Authentifizierung machen. 00:38:33.278 --> 00:38:36.688 Wenn wir uns ja mit Cookies authentifizieren, ist das ja normalerweise so, 00:38:36.688 --> 00:38:42.506 ich logge mich ein mit Passkey, Second Factor, wie auch immer ich mich halt authentifizieren möchte. 00:38:42.877 --> 00:38:47.558 Und der Server, der in den meisten Fällen damals halt so eine traditionelle 00:38:47.558 --> 00:38:52.548 Web App war, der baut dann eine Session auf und erstellt ein Session Cookie. 00:38:52.548 --> 00:38:55.809 Und diese Session Cookie wird mir dann in meiner Web App eben. 00:38:57.141 --> 00:39:01.171 Die ebenfalls von demselben Web-Server ausgeliefert wird. Und das war dann eigentlich 00:39:01.171 --> 00:39:04.701 ganz cool, weil jedes Mal, wenn ich Daten haben wollte, habe ich halt so ein 00:39:04.701 --> 00:39:08.411 Request an meinen Web-Server geschickt und der Browser setzt dieses Cookie ganz 00:39:08.411 --> 00:39:11.401 automatisch. Also es war ein Browser-Feature. 00:39:11.859 --> 00:39:15.991 Ich musste das Cookie nicht manuell speichern, nicht manuell auslesen. 00:39:15.991 --> 00:39:20.761 Der Browser hat es einfach mitgesendet. Und der Nachteil davon war halt aber, 00:39:20.761 --> 00:39:23.681 dass ich halt total stateful war. 00:39:23.681 --> 00:39:28.741 Also, dass ich halt jedes Mal, wenn ich halt Daten haben wollte, 00:39:28.741 --> 00:39:30.501 musste der Cookie mitgesendet werden. 00:39:30.501 --> 00:39:33.831 Und ich konnte jetzt auch nicht einfach sagen, oh, schick mir jetzt bitte einen 00:39:33.831 --> 00:39:37.571 Request an einen anderen Server, weil ich von dem auch Daten haben möchte. 00:39:37.571 --> 00:39:42.671 Weil der andere Server wäre dann auf einer ganz anderen Domäne gelaufen und 00:39:42.671 --> 00:39:47.077 hätte auch die Session gar nicht gespeichert und wüsste dann gar nicht, wer ich bin. 00:39:47.454 --> 00:39:49.532 Und ich hätte mich da vielleicht auch nochmal einloggen müssen. 00:39:50.078 --> 00:39:56.101 Das ist alles so ein bisschen nicht so vorteilhaft gewesen, weshalb man dann 00:39:56.101 --> 00:39:59.781 natürlich gesagt hat, ja, wir wollen eine gewisse Flexibilität haben. 00:39:59.781 --> 00:40:05.941 Es wäre super, wenn wir einfach etwas an die Server senden können und die Server 00:40:05.941 --> 00:40:11.801 können total unabhängig von wer auch immer diesen Token ausgestellt hat, also 00:40:12.481 --> 00:40:15.556 wer auch immer dieses Authentifizierungs- oder Autorisierungstoken ausgestellt hat, 00:40:15.881 --> 00:40:19.411 halt einfach verifizieren, dass jetzt dieser Client oder Nutzer, 00:40:19.411 --> 00:40:22.133 der diesen Token gesendet hat, eben die Daten haben darf. 00:40:22.580 --> 00:40:27.671 Und da kamen dann diese JSON-Web-Tokens ins Spiel. Und in diesen JSON-Web-Tokens, 00:40:27.671 --> 00:40:32.161 das ist eigentlich nichts anderes wie ein sogenannter Header, 00:40:32.761 --> 00:40:35.003 ein Payload und eben die Signatur. 00:40:35.671 --> 00:40:40.709 Und die Signatur hat halt diesen Vorteil, dass halt der Token natürlich signiert ist. 00:40:41.121 --> 00:40:44.542 Und wie wir vielleicht schon wissen, wenn wir etwas signieren, 00:40:44.542 --> 00:40:48.470 dann können wir auf die Authentizität überprüfen, 00:40:49.126 --> 00:40:54.572 aber auch überprüfen, dass auch niemand den Token irgendwie boshaft verändert 00:40:54.572 --> 00:40:56.986 hat, also diesen Payload hauptsächlich irgendwie verändert hat. 00:40:57.480 --> 00:41:00.700 Weil in diesem Payload stehen ja halt jetzt meine Berechtigungen drin. 00:41:01.073 --> 00:41:03.790 Man kann sich ja schon vorstellen, wenn ich jetzt eine Berechtigung, 00:41:04.067 --> 00:41:09.721 ich sag mal einfach nur lesen habe und ich würde jetzt bösartig eine Admin-Berechtigung reinschreiben, 00:41:10.355 --> 00:41:14.922 dann habe ich wenigstens den Vorteil, dass halt der Token nicht mehr verifiziert 00:41:14.922 --> 00:41:19.232 werden kann, weil halt die Integrität, also die Signaturprüfung dann natürlich gebrochen ist. 00:41:19.752 --> 00:41:22.794 Zum Thema der Integrität des Tokens hast du auch ein eigenes Kapitel, 00:41:23.148 --> 00:41:28.182 was ich sehr zukunftsorientiert fand, über die Quantencomputer-Angriffsvektoren 00:41:28.182 --> 00:41:33.082 und die Post-Quanten-Kryptographie, die in den Web-Tokens, in den 00:41:35.472 --> 00:41:38.536 JWTs mittlerweile drinsteckt. Das war so etwas, wo ich gedacht habe, 00:41:38.803 --> 00:41:42.042 ganz oft, wenn Leute sagen, welche tollen Anwendungsbereiche Quantencomputer 00:41:42.042 --> 00:41:45.622 haben, dann sehe ich immer nur den, ja, wir können Security umgehen und dann 00:41:45.622 --> 00:41:48.352 bin ich immer froh, wenn aus der Security-Kryptographie, 00:41:48.967 --> 00:41:53.987 Branche heraus schon kommt übrigens und wir haben hier Post-Quantum-Cryptography-Sicherheit 00:41:53.987 --> 00:41:57.597 implementiert, wo es auch nicht hilft, wenn man das Token tatsächlich mit dem 00:41:57.597 --> 00:41:59.508 Quantencomputer in Anführungszeichen aufbrechen kann. 00:41:59.874 --> 00:42:04.777 Ja, es gibt doch schon zig Post-Quantum-Algorithmen, die sowohl für Verschlüsselung, 00:42:04.777 --> 00:42:11.937 Entschlüsselung als auch für die Signaturüberprüfung eben zugezogen werden können. 00:42:11.937 --> 00:42:17.907 Ich arbeite auch sehr viel im Banken- oder Finanzsektor und da ist es eigentlich 00:42:17.907 --> 00:42:18.903 sogar schon gang und gäbe, 00:42:19.367 --> 00:42:24.497 dass da gerade Post-Quantum-Algorithmen eingebaut werden, weil die haben halt 00:42:24.497 --> 00:42:28.284 einfach schon auch die Pflicht und müssen das letztendlich umsetzen. 00:42:29.340 --> 00:42:34.017 Ein kleiner, das habe ich auch kurz in meinem Buch erwähnt, aber nur als Info 00:42:34.017 --> 00:42:39.837 ist, es gibt sogar noch etwas, das nennt sich FAPI, Financial API und das setzt 00:42:39.837 --> 00:42:41.692 sogar OAuth noch eins oben drauf. 00:42:41.936 --> 00:42:45.287 Da steht beispielsweise drin, müssen wir jetzt gar nicht groß ausführen, 00:42:45.287 --> 00:42:51.277 aber da steht beispielsweise nämlich drin, dass wir bitte so etwas wie Post-Quantum-Kryptographie 00:42:51.277 --> 00:42:54.335 schon implementieren in diesen Access-Tokens. 00:42:54.765 --> 00:42:59.737 Eben, dass halt quasi die Hochsicherheitsstufe ausgerufen ist, 00:43:00.137 --> 00:43:01.545 die Requirements dafür. 00:43:02.637 --> 00:43:07.234 Und die müssen dann natürlich gerade im Medizin- und Finanzsektor dann natürlich auch umgesetzt werden. 00:43:08.064 --> 00:43:12.997 Und da ist dann das ewige Waffenrennen zwischen, wie sicher kann ich es machen, 00:43:12.997 --> 00:43:15.937 wie performativ bleibt das System zeitgleich und 00:43:17.544 --> 00:43:19.871 welche Risiken kann ich eingehen, weil wir hatten ja schon mal angeschnitten, 00:43:20.121 --> 00:43:23.887 ich kann theoretisch extrem sichere Systeme bauen, die extrem nutzerunfreundlich 00:43:23.887 --> 00:43:28.602 sind und da dann die Abwägungen zu schaffen zu, es muss immer noch schnell gehen, es muss 00:43:29.200 --> 00:43:33.205 sicher genug sein, es muss zukunftssicher genug sein, das ist ja wirklich etwas, 00:43:33.997 --> 00:43:37.047 da gibt es keine richtige Entscheidung, sondern das sind halt sehr komplizierte 00:43:37.047 --> 00:43:38.318 Pfade, die da zusammenlaufen. 00:43:39.096 --> 00:43:43.602 Ja, absolut. Das ist ja auch schon das heutige Problem alleine, 00:43:43.602 --> 00:43:46.068 wenn ich Passwörter verschlüsseln möchte, also hashen möchte. 00:43:46.782 --> 00:43:53.835 Ich kann natürlich mein scrypt oder Argon2-Hash-Funktion kann ich ja konfigurieren, 00:43:54.149 --> 00:43:58.148 wie, um es mal sehr salopp zu sagen, wie langsam sie sein sollen. 00:43:58.415 --> 00:44:02.412 Denn gerade mal so Bruteforce-Attacken oder wenn ich dann mal so Datenbanken 00:44:02.412 --> 00:44:07.252 geklaut habe, wo ganz viele Hash-Werte drinstehen, dann will ich ja ganz, 00:44:07.252 --> 00:44:10.408 ganz viele Versuche schaffen, das zu hashen, 00:44:11.302 --> 00:44:15.112 innerhalb von wenigen Sekunden und wenn ich einmal diese Hash-Ausführung aber 00:44:15.112 --> 00:44:16.933 jetzt irgendwie fünf Sekunden lang mache…, 00:44:17.683 --> 00:44:22.126 Und ich brauche vielleicht eine Million mal, um ein einziges Passwort zu knacken, 00:44:22.126 --> 00:44:26.373 dann ist ja eine Million mal fünf, ist ja schon eine ganz schön lange Zeitdauer. 00:44:26.890 --> 00:44:30.706 Aber deshalb könnte man natürlich sagen, ja, wieso dann nur fünf Sekunden? 00:44:30.706 --> 00:44:36.156 Dann mach doch die Hash-Funktion, konfiguriere doch die Hash-Funktion so, 00:44:36.156 --> 00:44:37.993 dass sie 20 Sekunden braucht. 00:44:38.330 --> 00:44:40.757 Ja, das wäre natürlich viel, viel, viel sicherer. 00:44:41.186 --> 00:44:44.890 Aber wenn ich als Nutzerin, ich persönlich mich irgendwo einlogge, 00:44:45.296 --> 00:44:49.026 dann muss ja mein Passwort ebenfalls gehasht werden, um zu vergleichen, 00:44:49.026 --> 00:44:50.817 ob derselbe Hashwert auch in der Datenbank steht. 00:44:51.415 --> 00:44:54.694 Und ich kriege schon die Krise, wenn ich auf eine Webseite gehe und sie braucht, 00:44:55.252 --> 00:44:56.446 zwei Sekunden zum Laden. 00:44:57.826 --> 00:44:59.205 Oh, du lebst nicht in Deutschland? 00:45:00.906 --> 00:45:04.786 Ja, da hast du absolut recht. Das ist sehr schade manchmal. 00:45:06.351 --> 00:45:09.116 Also zwei Sekunden zum Laden, das rechne ich hier immer noch zu 00:45:09.116 --> 00:45:12.136 „So ist das Internet hier halt" ein, aber ich verstehe komplett, 00:45:12.136 --> 00:45:13.479 was du meinst, vor allem bei den 20 Sekunden. 00:45:14.766 --> 00:45:18.426 Als moderner Mensch hat man einen Passwortmanager und tippt das Passwort nicht 00:45:18.426 --> 00:45:21.256 mehr von Hand ein, aber wenn es dann doch eins ist, das man mal von Hand eintippen 00:45:21.256 --> 00:45:24.146 muss und man muss 20 Sekunden bei jedem Typo, den man gemacht hat, 00:45:24.146 --> 00:45:26.413 warten, das ist natürlich auch einfach unpraktisch. 00:45:27.069 --> 00:45:30.746 Ja, da gibt es natürlich was, was helfen kann und das sind Passkeys. 00:45:33.306 --> 00:45:39.736 Ja, also Passkeys haben tatsächlich schon statistisch die Login-Dauer auch verringert. 00:45:39.736 --> 00:45:42.671 Also da gibt es ganz coole Statistiken von der Fido-Allianz dazu. 00:45:43.546 --> 00:45:45.132 Ja, großer, großer Fan. 00:45:46.094 --> 00:45:51.857 Ja, jetzt hattest du verschiedene Gremien erwähnt und auch bei OpenID Connect, 00:45:51.857 --> 00:45:56.047 es stehen ja Organisationen hinter diesen de facto Standards, 00:45:56.047 --> 00:45:57.572 hinter diesen Entwicklungen. 00:45:58.320 --> 00:46:04.167 Wie ist das, welche Interessen haben die, entwickeln die das für das Greater 00:46:04.167 --> 00:46:07.097 Good der Menschheit, entwickeln die das, um selbst sicher zu sein, 00:46:07.352 --> 00:46:08.972 weil wir hatten es ja auch schon mal angeschnitten, 00:46:09.483 --> 00:46:12.717 irgendwann kommst du an den Punkt mit, es gibt verschiedene konkurrierende Systeme 00:46:12.717 --> 00:46:16.167 und Interoperabilität ist ja total wichtig, damit so ein System sich durchsetzen kann. 00:46:16.167 --> 00:46:20.867 Also wer entwickelt an diesen Standards und wer unterstützt, 00:46:20.867 --> 00:46:23.267 dass diese Entwicklung stattfinden kann, denn das ist ja jetzt nichts, 00:46:23.267 --> 00:46:26.764 was ausschließlich durch Goodwill und ein paar Universitäten entsteht. 00:46:27.671 --> 00:46:33.429 Ja, in den meisten Fällen ist es der IETF, das ist der Internet Engineering 00:46:33.429 --> 00:46:37.950 Task Force und die erstellen sogenannte RFCs. 00:46:38.385 --> 00:46:41.735 Und da ist letztendlich, die RFCs sind quasi die Spezifikation. 00:46:42.066 --> 00:46:46.617 Und da finden sich aber meistens dann Menschen aus der Industrie zusammen. 00:46:47.052 --> 00:46:52.189 Das kann mal jemand von Microsoft sein oder mal jemand von Ping Identity ist 00:46:52.189 --> 00:46:56.561 hauptsächlich auch oftmals dabei, aber auch von Google natürlich, von Apple. 00:46:56.828 --> 00:47:03.199 Also schon die Big Tech-Vendors natürlich, die ihre eigenen Interessen natürlich 00:47:03.199 --> 00:47:05.117 auch ein bisschen umgesetzt haben möchten. 00:47:05.559 --> 00:47:12.839 Sei es, dass es doch noch irgendwo in den Secure Enclave von MacBooks vielleicht 00:47:12.839 --> 00:47:18.659 eine Backdoor gibt oder so und die muss auch irgendwie abgebildet sein in diesem RFC, 00:47:19.357 --> 00:47:26.039 weil wenn sich dann Apple plötzlich an den RFC beteiligen muss und den implementieren 00:47:26.039 --> 00:47:30.710 muss, dann kann das natürlich auch für Apple vielleicht Millionen kosten oder Milliarden sogar. 00:47:31.041 --> 00:47:34.499 Und deshalb steigen die natürlich sehr gerne damit ein, also nicht nur Apple, 00:47:34.499 --> 00:47:38.189 auch Google und Microsoft und so weiter, senden quasi Vertreter aus und die 00:47:38.189 --> 00:47:44.253 arbeiten dann in sogenannten Taskforce-Gruppen oder Working Groups dann an dem entsprechenden RFC. 00:47:45.252 --> 00:47:51.369 Das ist immer ein bisschen schwierig natürlich, weil es gibt meistens auch natürlich 00:47:51.369 --> 00:47:56.809 jemanden dabei, der wirklich nur Goodwill ist, der wirklich einfach nur die 00:47:56.809 --> 00:47:58.839 Menschheit ein bisschen sicherer machen möchte. 00:48:00.979 --> 00:48:06.459 In der Webwelt. Und dann kommt man natürlich da ein bisschen oder stößt man 00:48:06.459 --> 00:48:10.149 natürlich ein bisschen auf Widerstand, weil dann natürlich Google, 00:48:10.149 --> 00:48:13.830 Microsoft und wie sie alle heißen, da vielleicht ein bisschen dagegen wirken. 00:48:14.451 --> 00:48:19.285 Eins der zum Beispiel größten oder der größten Probleme war tatsächlich damals 00:48:19.285 --> 00:48:22.119 der Umstieg von OAuth 1 auf OAuth 2.0. 00:48:23.015 --> 00:48:28.455 Ich hatte ja schon angedeutet, dass OAuth 1 dieses coole Sender Constraining eigentlich 00:48:28.455 --> 00:48:32.555 mit drin hat, dass man halt den Access Token nicht einfach so senden kann, 00:48:32.555 --> 00:48:36.700 sondern der muss immer irgendwie an den Client gebunden sein, kryptografisch. 00:48:37.310 --> 00:48:42.885 Und jetzt kam halt tatsächlich, nachdem Twitter aufkam, kam natürlich da auch 00:48:42.885 --> 00:48:44.635 Apple und Microsoft dazu und 00:48:44.635 --> 00:48:49.187 haben gesagt, jetzt wollen wir aber dieses Internet weiter voranbringen. 00:48:49.477 --> 00:48:51.793 Wir wollen Webseiten weiter voranbringen. 00:48:52.136 --> 00:48:58.925 Und in so einem Browser kann ich nicht so richtig standaktuell Sender-Constraining 00:48:58.925 --> 00:49:03.130 umsetzen, weil Sender-Constraining würde ja bedeuten, dass ich vielleicht auch so eine Art, 00:49:03.746 --> 00:49:08.616 Private Key dann im Browser habe, mit dem ich dann den Token vielleicht signiere, 00:49:09.423 --> 00:49:11.739 und ein Private Key einfach so im Browser zu haben. 00:49:13.638 --> 00:49:17.518 Also mittlerweile ist das möglich. Es gibt so eine Web-Crypto-API. 00:49:17.518 --> 00:49:22.803 Mittlerweile geht es, aber damals hat man halt keine Möglichkeit gehabt für sowas. 00:49:23.325 --> 00:49:29.368 Und dann hat halt tatsächlich Apple und Google gesagt, wir entfernen das Ganze. 00:49:29.368 --> 00:49:33.390 Wir entfernen das Ganze, Sender-Constraining einfach und machen das zu Bearer-Tokens. 00:49:33.667 --> 00:49:39.938 Haben also ihren Willen durchgebracht, nur damit sie halt mehr in dieser Webwelt 00:49:39.938 --> 00:49:42.752 flexibler ihre Interessen durchdrücken können. 00:49:43.558 --> 00:49:49.155 Und das hat halt sogar dazu geführt, dass der ursprüngliche Gründer von OAuth, 00:49:50.278 --> 00:49:55.257 der hat eine riesige Hasstirade tatsächlich in einem Artikel verfasst. 00:49:55.645 --> 00:49:57.607 Das nennt sich OAuth 2, Road to Hell. 00:49:59.278 --> 00:50:04.838 Wie schlimm jetzt das ist, dass die Vendors tatsächlich da in Spezifikationen 00:50:04.838 --> 00:50:10.078 eingreifen, dass jetzt dieses ganze Kryptografische wegfällt und damit, 00:50:11.203 --> 00:50:17.164 landen wir halt dabei, dass wir Autorisierung, Authentifizierung weitaus unsicherer machen. 00:50:17.605 --> 00:50:22.758 Jetzt kann man natürlich nochmal den Bogen spannen auf die OWASP Top Ten. 00:50:22.758 --> 00:50:29.448 Das ist so eine coole Liste, wo quasi die gängigsten Angriffsszenarien aufgelistet 00:50:29.448 --> 00:50:34.351 sind, was so die größten Schwachstellen sind heutzutage in Web-Anwendungen. 00:50:34.723 --> 00:50:36.133 Und die kommt alle vier Jahre raus. 00:50:36.668 --> 00:50:44.887 Und seit 2021 ist Platz, also auch davor schon, aber ist Platz 1 Broken Access Control. 00:50:45.131 --> 00:50:50.478 Also quasi genau das ein bisschen, was er vorausgesagt hat, dass Broken Access 00:50:50.478 --> 00:50:53.049 Control, dass halt der Token gestohlen wurde, dass einfach, 00:50:54.198 --> 00:50:57.769 Token irgendwo hingesendet wurde, die werden nicht richtig überprüft, 00:50:58.216 --> 00:51:01.176 weil man halt diese ganze Kryptografie letztendlich entfernt hat. 00:51:02.610 --> 00:51:06.778 Aber um wieder den ganzen Bogen zurückzuspannen, also ja, es gibt dann immer 00:51:07.218 --> 00:51:10.758 diese Taskforce und die kümmert sich halt um die Spezifikationen, 00:51:10.758 --> 00:51:14.798 aber klar mischen da die großen Big Tech Companies halt mit, 00:51:14.798 --> 00:51:16.873 um auch ihre eigenen Interessen durchzudrücken. 00:51:18.731 --> 00:51:23.693 Das ist bei solchen Standards ja durchaus immer eine Schwierigkeit, 00:51:23.693 --> 00:51:26.723 die man auch in der Open-Source-Community viel sieht von Leuten, 00:51:26.723 --> 00:51:31.833 die etwas aus Idealismus anfangen oder weil sie eine Idee haben und dann kommen 00:51:31.833 --> 00:51:33.423 die Leute, die damit ein Produkt machen wollen. 00:51:33.423 --> 00:51:36.693 Und dann entsteht natürlich auch dieses, wenn Apple es schafft, 00:51:36.693 --> 00:51:40.063 vor Google einen entsprechenden Service anzubieten, der viel reibungsloser ist, 00:51:40.063 --> 00:51:41.364 ist das für sie ein Marktvorteil. 00:51:41.799 --> 00:51:46.593 Und dieses, man arbeitet schon zusammen, aber man hat ja nicht unbedingt das 00:51:46.593 --> 00:51:49.573 gleiche Interesse, nämlich wir machen das Internet sicher, sondern man hat immer 00:51:49.573 --> 00:51:52.910 noch im Hinterkopf das Interesse, die Leute sollen meine und nicht deine Produkte kaufen. 00:51:53.340 --> 00:51:56.723 Das ist hochkompliziert und ich finde es immer spannend, wenn man sieht, 00:51:56.723 --> 00:51:58.313 wer auf solchen entsprechenden 00:51:59.033 --> 00:52:03.143 Konferenzen, Panels und so weiter und so fort als Sponsoren auftaucht und man 00:52:03.143 --> 00:52:06.343 sieht, da ist dann teilweise komplett Big Tech vertreten und dann schaffen sie 00:52:06.343 --> 00:52:10.033 es irgendwie hier an einem Strang zu ziehen und dann fehlt auffällig einer wie 00:52:10.033 --> 00:52:12.713 zum Beispiel Microsoft oder Amazon und man fragt sich, warum? 00:52:12.713 --> 00:52:15.723 Also profitieren die jetzt nur von dem neuen Standard, der hier ausgearbeitet 00:52:15.723 --> 00:52:18.533 wird und warum unterstützen sie ihn nicht oder haben sie selbst was, 00:52:18.533 --> 00:52:21.933 das sie da gerade kochen? Also da gibt es, ich glaube, man könnte einen kompletten 00:52:21.933 --> 00:52:23.503 Gossip-Podcast machen, nur 00:52:23.503 --> 00:52:26.973 um szeneninterne Streitigkeiten bei der Weiterentwicklung von Standards. 00:52:27.453 --> 00:52:30.633 Ja, absolut. Es gibt ja auch, jetzt fange ich später damit an, 00:52:30.633 --> 00:52:33.923 aber es gibt ja auch einen relativ langen, ausführlichen Blogartikel, 00:52:33.923 --> 00:52:36.847 wie Apple es fast geschafft hätte, Passkeys zu töten, 00:52:37.404 --> 00:52:42.413 eben weil sie sich nicht so richtig an den Standard, der geschrieben wurde, 00:52:42.413 --> 00:52:44.817 gehalten haben und ihr eigenes Süppchen gekocht haben. 00:52:45.200 --> 00:52:49.133 Was halt dann in dem Moment bedeutet, dass wenn ich ein Passkey halt anlege in 00:52:49.133 --> 00:52:54.213 Apple, in meiner iCloud Keychain oder auf dem Gerät, dass ich den halt definitiv 00:52:54.213 --> 00:52:58.073 nicht synchronisiert bekomme mit anderen, mit Google oder wie auch immer. Ja. 00:52:58.545 --> 00:53:01.476 Und glücklicherweise hat sich das mittlerweile wieder ein bisschen geregelt, 00:53:02.010 --> 00:53:06.818 aber sie hätten es halt beinahe leider geschafft, halt Passkeys wieder aussterben 00:53:06.818 --> 00:53:10.143 zu lassen, bevor es richtig im Kommen war letztendlich. 00:53:10.445 --> 00:53:14.838 Eine Sache, mit der ich dann das Ganze auch abbinden würde, du hattest RFCs 00:53:14.838 --> 00:53:18.188 gerade erwähnt und in deinem Buch, in deinem Schlusswort, in deiner Danksagung, 00:53:18.188 --> 00:53:20.661 da schreibst du auch, es gibt all diese RFCs, also die 00:53:21.125 --> 00:53:26.164 Anleitungen, wie das Ganze technisch gedacht ist und wie das Ganze umzusetzen ist, 00:53:26.715 --> 00:53:29.678 aber aus denen ergibt sich jetzt noch nicht direkt ein Lehrbuch, 00:53:29.678 --> 00:53:31.428 mit dem man versteht, was das Ganze ist. 00:53:31.428 --> 00:53:35.588 Und das Buch, das du geschrieben hast über Authentifizierung und Autorisierung 00:53:35.588 --> 00:53:40.018 im Rheinwerk Verlag, das befasst sich ja damit, genau das zu sein. 00:53:40.018 --> 00:53:45.947 Ein Lehrbuch, ein Nachschlagewerk für etwas, das an sich sehr technische Beschreibungen sind. 00:53:46.464 --> 00:53:51.845 Was hast du selbst bei dem Verfassen dieses Buchs nochmal über die entsprechenden RFCs gelernt? 00:53:53.604 --> 00:53:58.318 Das ist tatsächlich eine sehr gute Frage, denn ich muss auch sagen, 00:53:58.602 --> 00:54:04.926 bevor ich das Buch geschrieben habe, habe ich nicht jeden RFCs von oben nach unten durchgelesen. 00:54:05.426 --> 00:54:09.283 Mittlerweile dann schon, weil ich würde natürlich das Buch schon richtig schreiben. 00:54:09.794 --> 00:54:16.736 Aber das war tatsächlich sehr interessant, gerade OAuth 2 hat halt irgendwie 15 00:54:16.736 --> 00:54:19.120 verschiedene RFCs letztendlich. 00:54:19.306 --> 00:54:25.140 Was ich glaube ich daraus gezogen habe, ist, dass es, wie du auch gesagt hast, 00:54:25.732 --> 00:54:30.426 es steht halt irgendwie eine Spezifikation drin und es gibt vor allen Dingen 00:54:30.426 --> 00:54:34.080 im deutschsprachigen Raum aber auch nichts so in die Richtung, 00:54:34.521 --> 00:54:37.296 jetzt erkläre ich es euch mal, wie das funktioniert. 00:54:37.296 --> 00:54:41.366 Und viele Entwickler und Entwicklerinnen wollen halt einfach einen Authorization-Server 00:54:41.366 --> 00:54:43.519 anbinden und wollen einfach nur so einen Access-Token haben. 00:54:43.838 --> 00:54:49.016 Und das leider so ein heikles Thema ist und es aber leider keine vernünftigen 00:54:49.016 --> 00:54:52.206 Ressourcen dazu gibt, wie man es richtig macht, außer die RFCs. 00:54:53.486 --> 00:54:58.589 Neigt man halt dazu, wild rumzuklicken und Trial and Error und halt zu gucken, 00:54:58.890 --> 00:55:00.963 okay, jetzt habe ich endlich den Access-Token. 00:55:01.398 --> 00:55:05.446 Sehr gut. Ich habe irgendeiner dieser Flows ausgewählt, auch wenn es vielleicht 00:55:05.446 --> 00:55:08.696 ein unsicherer war, aber mir jetzt gerade egal, weil ich habe zwei Tage lang 00:55:08.696 --> 00:55:12.201 damit rumgemacht, so ein Access-Token zu bekommen und damit übertreibe ich tatsächlich nicht. 00:55:12.823 --> 00:55:17.126 Und dann ist natürlich auch das Problem, dass alle Identity Provider, 00:55:18.192 --> 00:55:22.766 die auch ein bisschen unterschiedlich implementieren, also kein Identity Provider 00:55:22.766 --> 00:55:25.296 implementiert die RFCs zu 100 Prozent. 00:55:25.296 --> 00:55:29.776 Und sprich, selbst wenn man jetzt die RFCs liest, ist nicht sichergestellt, 00:55:29.776 --> 00:55:32.606 dass das jetzt eins zu eins das ist, was man jetzt in Keycloak, 00:55:32.606 --> 00:55:35.078 in Entra ID, wie auch immer vorfindet, 00:55:35.398 --> 00:55:40.297 weil die dann doch wieder so ein bisschen gesagt haben, wir wissen es aber besser 00:55:40.709 --> 00:55:43.226 und wir machen es vielleicht ein bisschen anders. 00:55:44.526 --> 00:55:50.526 Es gibt zum Beispiel nicht den Token Exchange Flow in Entra ID, der heißt OBO Flow on behalf of User. 00:55:50.526 --> 00:55:53.724 Und der ist ein eigenkreierter Flow, weil sie halt gesagt haben, 00:55:53.985 --> 00:55:57.246 der RFC ist noch nicht so weit und deshalb machen wir jetzt schon mal wieder, 00:55:57.786 --> 00:55:58.816 unser eigenes Süppchen. 00:55:58.816 --> 00:56:04.036 Und was ich halt mit dem Buch versucht habe, ist auch die Unterschiede aufzuweisen. 00:56:04.036 --> 00:56:08.686 Also gerade in dem Implementierungskapitel habe ich halt auch riesige Tabellen 00:56:08.686 --> 00:56:14.110 gemacht, um die gängigsten Identity Provider, wie heißt der Flow da, 00:56:14.255 --> 00:56:17.953 was muss man dafür konfigurieren, damit man diesen Flow einsetzen kann. 00:56:19.106 --> 00:56:23.936 Und das Wichtigste, wenn man sich aber ein bisschen mit den RFCs beschäftigen 00:56:23.936 --> 00:56:26.782 möchte, ist man, glaube ich, gut damit geraten, 00:56:27.078 --> 00:56:34.874 nur noch den OAuth 2.1 RFC durchzulesen und nach alles, was dort beschrieben ist an Requirements and 00:56:35.287 --> 00:56:40.366 Should Have, Must Have, dass man sich eher daran hält, weil OAuth 2.1 ist keine 00:56:40.366 --> 00:56:44.886 wirkliche Weiterentwicklung, sondern mehr so die Zusammenfassung von, 00:56:45.480 --> 00:56:48.592 allem, was man aus OAuth 2.0 gelernt hat. 00:56:49.085 --> 00:56:54.925 Alles klar. Ich glaube, wir haben für das Buch, das ja doch sehr, 00:56:55.058 --> 00:56:58.556 sehr technisch ist, ein Nachschlagewerk, ich glaube, wir haben ein sehr gutes 00:56:58.556 --> 00:57:01.306 Gespräch darüber zusammenbekommen, warum es sich lohnt, reinzuschauen, 00:57:01.306 --> 00:57:02.843 warum der eine oder andere da vielleicht noch 00:57:03.348 --> 00:57:08.106 etwas ausgiebig lernt über die RFCs, die man sonst nur als Handlungsanweisung 00:57:08.106 --> 00:57:10.771 und nicht als Lehrbuch benutzen kann. Danke für deine Zeit. 00:57:11.932 --> 00:57:14.063 Ja, sehr gerne. Hat mir super viel Spaß gemacht.