OAuth 2.0 für Authentifizierung und Autorisierung im Web #50

Was? Moin zufolge 50 der großen Jubiläumsfolge von einfach komplex heute wieder nur mit Burkhardt und Mia. Moin Moin. Moin ihr Lieben. Genau, ja, 50. Eigentlich wollten wir das schon unter einem Jahr erledigt haben, aber jetzt sind wir am 2 Wochen Takt, also hat es ein bisschen länger gedauert, ist ja aber nicht so schlimm würde ich sagen. Burkhard, Was hast du mitgebracht für heute, was besprechen wir?

Ja, ich weiß gar nicht, wie mir geschah die Jubiläumsfolge und so ein krasses Thema also tatsächlich jetzt nach 50 folgen, traue ich mich endlich mal über Authentifizierung und Autorisierung zu sprechen. Alleine die Worte lassen ja manchen Leuten die Nacken, also mir auch die Nackenhaare hochstehen. Komplex ist.

Sehr kompliziertes Thema kann man sich über Kopf und Kragen reden, ja, ist ein Dickicht, dann ist auch entsprechend viel passiert im Web, es gibt viele Fehlinformationen, es gibt glaube ich auch viel schlechte Implementierung und alles und wir versuchen mal so ein ganz bisschen die Taschenlampe reinzuhalten was da so los ist und ein bisschen. Klarheit zu schaffen glaub ich in dem Riesenthema. Ja, wir werden es einfach so n bisschen durchgehend versuchen.

Wir können das nicht in jeder Tiefe machen, das ist ganz klar, also dass man so ja vielleicht mal so ne Grundsatz Ahnung hat von allem, ja das wär der Plan für heute. Ja, wunderbar, das klingt doch ganz gut. Ich glaube, das ist allen Zuhörenden ganz lieb, wenn wir das nicht in der letzten Tiefe machen, aber fangen wir an. Wie fangen wir an? Lass uns doch allgemein einmal erklären, was ist Authentifizierung und was ist Autorisierung und ich muss auch schon tierisch aufpassen.

Die Worte, richtig, ich glaube so der klassische Begriff, man sagt immer so Authorization Rums und meint eigentlich alles. Und es ist auch ein bisschen akademisches Aufzudröseln. Aber tatsächlich muss man wirklich technisch und auch inhaltlich unterscheiden zwischen Authentifizierung und Autorisierung, also Authentication oder Authorization, und die machen nämlich ganz verschiedene Sachen, und das kann man ganz schnell erklären. Bei der Authentifizierung geht es darum.

Dass ich wissen möchte, mit wem ich spreche und bei der Autorisierung. Geht es mir darum, dass ich weiß, wenn ich schon weiß, mit wem ich spreche, was derjenige darf an Rechten, das kann der sehen, manipulieren und so weiter. Also das eine noch mal gesagt, das eine erklärt, wem spreche ich überhaupt, ich will mir sicher sein, dass ich zum Beispiel genau Gerrit Meyer eingeloggt hat bei mir. Ich habe Gerrit Meyer am Rohr, dann habe ich ihn authentifiziert, wenn ich das

weiß. Und wenn ich das weiß, und das ist ne Reihenfolge, erst dann kann ich den Gerrit autorisieren auf bestimmte Ressourcen, beispiel Kontakte von ihm und so weiter zuzugreifen. Das ist ganz wichtig. Das aber das ist ja auch ganz einfach, also das kann man sich einfach abspeichern, und das ist schon immer so gewesen und gilt für alles. Ja, nee, das ist tatsächlich einfach. Also Authentifizierung kommt immer vor der Autorisierung. Ja, jetzt hast du ein Beispiel

gemacht mit einer Person, aber. Trifft das auch zu auf Programme oder programmatische Kommunikation zwischen Computern oder in Netzwerken oder sowas? Ja, kann man so sagen. Genau ja, das ist irgendwie ne Client ID oder irgendwie aber also wir sprechen heute so n bisschen über. Wir wollen auch noch ansprechen und so weiter also wir, wir gehen mal davon aus, dass wir auch ne Person haben erstmal. Wir authentifizieren wollen und dann wollen wir Autorisierung

auch gestatten und so weiter. Weil wir die erstmal bei bleiben, sonst wird das Thema gleich schon wieder riesig komplex. So jetzt die ganzen. Aber ja du hast recht. Gut ja, ist doch gut, wenn wir die, wenn wir das Thema hier begrenzen, an der Stelle, ja, ich schätze mal, wir werden wahrscheinlich manchmal auch Authentication and authorization, also die englische Begriffe nutzen. Ja, durcheinander, aber das wisst ihr jetzt genau. Immer das Gleiche gemeint.

Ja genau, wieso ist das so ein wichtiges Thema, dass wir dem eine Folge widmen. Na ja, das hat ja überhaupt der ganzen Sicherheit vom Netz und den Ganzen.

Also wir sind ja im Zeitalter, wo wir relativ viele Daten im Netz haben, in der Cloud haben, man hat sehr viel persönliche Daten bei Facebook vielleicht ich nicht, aber oder bei Google ja, oder und mein mein Banking Account und so weiter und es ist ja lebensnotwendig, dass die Anwendung, die unsere Daten halten, genau wissen, wann wir auch tatsächlich am Rohr sind und was wir dann lesen dürfen oder was zum Beispiel andere, die wir einladen, zum Beispiel um irgendwas zu scheren oder

irgendsowas, was die dann dürfen, aber die. Sind nur Teilbereiche von unseren Daten, sehen aber nicht alle und so weiter also ganz krass essentiell für das ganze Funktionieren des modernen Internets?

Eigentlich ja, und ich weiß nicht, ihr kennt es ja, also jede mobile App, jede, ich sag mal fast jede Saßanwendung ne, also nicht jede Webseite, die nur statischen Content bietet, aber überall da wo ich mal irgendwas hinterlasse an meinen Daten oder Einstellungen, fast überall werde ich dann quasi authentifiziert. Ja, also ich muss irgendwie Usernamen Passwort eingeben oder mindestens Login via Google oder Irgendsowas kann man später dazu. Weil ansonsten ist ja der Kram irgendwie anonym.

Dann kannst du es später nicht mehr, dann kannst du es später ja nicht mehr zuordnen, nicht mehr zurückfinden müssen wir. Vielleicht später noch mal drüber reden, was mir gerade

einfällt ist Apps, weil du Apps angesprochen hast. Wenn ich an mein Telefon denke, muss ich mich ja nicht bei jeder App jedes Mal wieder einloggen. Also es gibt ja durchaus Apps. Wo du warst, dann aber mal eingeloggt, weil deine App dann halt ein Google Konto hinten liegen hat und dann bist du halt eingeloggt oder oder bei der Login bestehen bleibt oder bestehen bleibt genau das vielleicht später noch mal drauf

kommen. Ich glaube das ist ein Thema für die für die Sessions dann oder so, aber jetzt hast du gesagt. Das ganze Thema hat ne gewisse Geschichte. Also das ist steht bei uns auf der Agenda. Ja, ja genau, also wie fing es an beziehungsweise was war früher anders als es dann heute ist.

Ja, man kann ja erst überhaupt mal Authentifizierung und Autorisierung erstmal ganz einfach besprechen, wie man das mal so das ist, das hilft ja auch, um das mal einzuordnen, was passiert technisch so ganz grob und so, so wurde es tatsächlich früher auch implementiert, weil es noch gar nicht gar keine wilderen Technologien gab.

Ja, und dann wird, wenn wir davon sprechen, dann haben wir, dann haben wir die klassischen Parteien, dann haben wir den Klienten den Browser, wo du zum Beispiel Vorsitz Gerrit, und da ist typischerweise ein Formfeld drin, das kennt ja jeder irgendwie Username und Passwort oder E-Mail und Passwort, was ich dann da eintippe, um mich jetzt zu authentifizieren.

Und dann hat man, das war jetzt ich, spreche so in der Zeit von 2006 / 2007 herum, 2007 mal zur Einordnung kam das erste iphone raus, da haben wir ungefähr da war, das sind ja jetzt irgendwie, ich weiß gar nicht, wie viele Jahre rückwärts, so schnell kann ich gar nicht. Rechnen. Aber voll krass. Also so ein ein Webjahr ist ja ist ja was anderes als ein Kalenderjahr sage ich mal.

Also da waren Zeiten noch ganz anders, aber da gab es natürlich auch schon Webseiten und da konnte ich mich ja authentisch

authentifizieren. Und dann hatten die typischerweise ne Datenbank, die war halt ganz strikt an diese, an diesen ne. Es gab ja nur n Server, der hat quasi Webseite geliefert und an dem Server direkt dran meine Datenbank und da stand halt und wie funktioniert das da steht halt in der in der Datenbank drin Username und Passwort und wenn du dann halt deinen Username und Passwort eingibst, dann wird halt geguckt in der Datenbank gibt es zu diesem

Username dieses Passwort was er da gerade eingegeben hat und hier ist schon mindestens erste kleine Sicherheits dings dieses Passwort wird typischerweise wenn man es dann irgendwie geschickt macht nicht im Plain Text wie man so schön sagt eine Datenbank abgespeichert. Gehascht das Wort Hash hat mir schon ganz oft, ist halt einfach nur ne Funktion, wo man quasi nur einen Weg Verschlüsselung hat.

Ne, also das echte Passwort, das kennst genau du, das tippst du ein, dann geht es hoffentlich über TLS Verschlüsselung also auch nicht mitlesbar. Also nicht per Platex rüber an den Server und da wird eine Hash Funktion drauf angewendet und dann kommt irgendwas kryptisches raus und dieses kryptische hast du beim hast ja vorher schon mal angelegt beim sogenannten Signeup, dann wird einfach nur verglichen. Ist dieses kryptische das gleiche was da vorher kryptisch

angelegt war? Wenn ja, dann ist wohl das Passwort richtig und was dann passierte ist eigentlich dann entsteht ein sogenanntes Fashion Token, also den Begriff der Session, der ist wichtig den wir heute besprechen, der Session ist einfach nur ja eine gültige Session ist quasi die Zeit in der ich gültig eingeloggt bin Punkte aus, so kann man es eigentlich sagen ja und diese Session Token es wird quasi zurückgeschickt zu diesem Browser der jetzt diesen Request

abgegeben hat und dann eigentlich in Form von einem Keks von einem Cookie. Abgespeichert. Das hat den Vorteil. Cookies gab es damals auch schon, das hat den Vorteil, dass mit jedem weiteren Request gegen den Server automatisch diese Session Token das quasi dir sagt, okay, du bist halt, du hast mal eine valide Authentifizierung hinter dir, zum Server gescheckt und der kann dann quasi immer überprüft. Ja, stimmt das noch? Ist das das Session Token was ich erwarte?

Ja, also ist der Gerrit hier noch am Rohr? Ich spreche mit dem richtigen als Klima so so so klar und so

einfach ist das eigentlich. Ja, das war jetzt für das Internet schon ne du sagst ne Website, also wir sprechen heute von Webtechnologien im Prinzip. Wie ist es denn, wenn ich einfach in der Zeit, ja, hatte ich wahrscheinlich noch viel mehr Programme, die einfach auf meinem Rechner gelaufen sind und da lokal installiert waren, vermutlich ähnlich oder also einfach im User, dem Passwort und Teil dieses Programms war eine Datenbank, wo einfach schon dieser Username und dieses

Passwort hinterlegt sein mussten. Ja klar, aber wenn du so denkst, Desktop, Anwendungen und so weiter da war ja gar kein, das war ja das Internet für dich notwendig, das hättest du ja auch ohne Netzwerkkabel dann 386 oder was weiß gar nicht was es da gab unter Windows, da ist das halt das Betriebssystem. Da weißt du ja, du kannst ja

beim Windows auch. Also oft gab es das gar nicht, du musst das nicht, du kannst beim Windows ja eingeben, ich möchte mich als User mit dem Passwort, wenn das Windows startet authentifizieren und dann gibt es ja bestimmte Bereiche. Es gab damals schon von Windows, die dann halt nur für dich sind. Aber das ist jetzt meine, ist also, das ist jetzt keine Erfindung des Wertes.

Oder sowas gibt. Es schon viel länger, das ist schon klar, das ist was, was man immer zum Einloggen, das konnten schon die alten Griechen, ne, vielleicht nicht ganz so lange, aber im Prinzip ja genau ja, na du hast es jetzt gleich bezogen auf auf Web, weil das eigentlich das einzige Relevante heutzutage genau alles andere ist. Genau und ich würde sagen alles andere was nicht web ist würde mindestens von dem was ich gerade gesagt habe mit so einer Art Datenbankabgleich passt.

Username zu Passwort und das Passwort, dass ich das Encrypted quasi hinspeichere und nicht im Plaintext so so würde auch jedes andere System, es gibt ja nicht überall Internet, es gibt tatsächlich auch relevante Edge Cases, wir können ja zum

Beispiel gucken Oti edge wo. Keine Info, kein Internet hast aber du willst quasi irgendwie was weiß ich ne SPS mal authentifizieren oder irgendsowas, aber da könnte man das halt auch so machen. Ne gut verstanden, ist ja eigentlich erstmal relativ trivial. Schlicht und einfach genau. Relativ trivial. Genau. Und dann? Autorisierung wird es wahrscheinlich auch. Noch erklären, wie das Ja genau Autorisierung ist.

Dann aber das ist dann auch eigentlich einfach dann, das kann man dann implementieren, das wurde auch so gemacht, da gibt es im Prinzip keinen Standard zu, dann speicherst du halt quasi, wenn du erstmal weißt, mit wem du sprichst, dann kannst du natürlich in der Datenbank hinterlegen, typischerweise steht, dann gibt es eine User id. Name, das wäre dann Deine E-Mail-Adresse, gerrit.meier@heißenwer.com oder irgend sowas.

Und dann gibt es in der Datenbank ne ID zu dir und mit der ID wird in einem anderen Tabelle typischerweise deine Rechte festgelegt, was du denn darfst, wenn du eingeloggt bist. Ja und sowas und ich sag mal was dieser Rechte die du hast, die hast du auf dem englischen Scope, es kommt auch später von einem Scope und typischerweise sind das so Sachen wie E-Mail, read contact, doppelpunkt, ride, delete und so weiter und sofort also so und wie man das genau formuliert und wie das genau

ausgedrückt ist. Sind Standards, hat jeder so gemacht wie er Bock hat, aber man speichert irgendwohin. Was darf denn der jetzt? Ja, wenn man es überhaupt implementiert, ja ganz viele einfache Sachen damals waren ja. Ohne Autorisierung im Prinzip. Also du hast ja einfach authentifiziert und damit warst du in allem drin, so, ja. Letztes so n Admin und alle anderen. Admin und alle anderen oder Irgendsowas ganz genau.

Ja ja so, das war das und und dann gab es natürlich damit, man könnte jetzt meinen Okay Folge fertig ist ja ganz klar easy. Ganz so einfach ist es nicht. Ja gut, ich schätze mal, die Bedarfe haben sich mit der Zeit dann auch geändert.

Ja, also ja genau, und deswegen habe ich auch gesagt, es gab damals ja noch keine Mobiltelefone und die Mobiltelefone waren schon so ein Problem dafür, weil im Prinzip diese, also dieses ganze Gedöns mit dem Cookie und so wie man das immer so gemacht hatte, das funktionierte bei nativen Apps auf dem Mobiltelefon erstmal nicht, weil die kannten dieses dieses Cookie Krams noch nicht so.

Richtig Cookie, das hast du gerade so mit im Schwung, mit erklärt oder lass es mich wiederholen im Cookie, der wird ja dann abgelegt auf dem jeweiligen auf dem Klienten, also im Browser desjenigen, der da versucht sich einzuloggen oder sich eingeloggt hat und da drin ist dann mit so einem Session Token und. Beim neuen Anmelden oder neuen Aufrufen einer Website wird einfach geguckt. Ist da ein Cookie mit einem noch gültigen Session Token war das so fast. Genau.

Also es wird nicht geguckt, ist da n Cookie, sondern was passiert ist. Wenn du n Cookie hast. Und du nen Aufruf machst dann HTTP Aufruf, dann passiert es so. Das ist implementiert in den Browsern, dass der Inhalt des Cookies quasi ran attached wird an diesen HTTP aufruf, das wird automatisch mitgesendet, da musst du dich als Programmierer noch nicht mal drum kümmern. Hast du n Cookie wird quasi die. Die Daten das Cookies einfach mitgeschickt und das kann der Server dann auslesen.

Genau, aber im Prinzip richtig was du gesagt hast und dann kann und so n Session Token auch noch mal kurz gesagt ne also Token Token was ist überhaupt n Token ne n Token ist einfach nur ne lange Folge also n langer String also ne Abfolge von Charactern. Randomisiert da. Die müssen keinen inhaltlichen Zweck haben, außer dass sie einfach einen unikes Token sind, ein Unique. Tatsache, der Server kann damit was anfangen, quasi. Richtig.

Hauptsache also du kannst es quasi lesen und deswegen ist auch nicht schlimm, wenn das irgendwie das Cookie mal

irgendwie jemand liest. Das ist wichtig, ja, wenn dir das Session Token abhanden kommt und das ein dritter mitliest, dann kann er vielleicht für die für die Dauer der Session irgendwas machen, auch schon nicht so cool so, aber diese Session docken wird ja dann irgendwann erneuert, das hat meistens eine Expirory also das läuft eine gewisse Zeit nur und wenn du es halt nicht ständig wieder kommunizierst und das nicht automatisch erfrischt wird.

Dann läuft das halt irgendwann ab und dann wirst du halt wieder nach deinem Username und deiner E-Mail gefragt. Dann geht der ganze ganze Chose von reinem los. Also es hat keinen Inhalt und der Inhalt dieses Session Tokens, der fängt erst dann logisch an Sinn zu machen, wenn

der dem Server gezeigt wird. Das Session Token und da steht in der Datenbank das Session Token ist in der Datenbank auch eingetragen und dann kann ich genauso in der Datenbank sagen okay wenn ich dieses Token sehe, dann weiß ich das ist der und der User die und die Rechte das und das zu tun. Ist eine Möglichkeit um das jetzt nehm ich was vorweg, was

wir später noch mal haben. Man könnte jetzt schon akademisch auf die Idee kommen, ja cool, das kann ich natürlich so machen, aber ich könnte ja das Token auch cleverer machen und in das Token schon Informationen reinpacken. Zu dessen Laufzeit und zu den Rechten, die der der Nutzer, der sich authentifiziert hat. Dann hat.

Ja das ist auch überhaupt nicht ungewöhnlich und das kommt auch später vor, das wird heute ganz oft gemacht, gerade bei der Authentifizierung, und dann hat man, dann, spricht man von so genannten Jwt oder Jard unter den unter den Nerds heißt das Chart Year WT, das ist ein JSON Web Token und das ist quasi eine ein aufgeblasenes Token, das ist immer noch ein langer String, aber dieser String ist ein baysixty Four Encoding, das kann

ich also dekodieren und dann kann ich da drinne rumlesen und da kommt quasi sowas wie ein Jason raus mit einem Header mit einem Anteil von Daten, die dann relevant sind und mit der

Signatur. So dass das Token in sich auch das kann signiert werden quasi. Dann kann quasi jeder jeder von

außen prüfen. Ist dieses Token manipuliert worden oder nicht, ein bisschen diese Krypto Sachen, die wir vorher hatten mit schonmal Blockchain und so weiter das ist eine andere Art und Weise, das kann man auch machen und es gibt alle Abwandlungen von diesem Graben über die Zeit ist alles passiert, ja man gab Session Token, sie waren einfach plane, dann gab es mal jdok Tokens weil die sich ein bisschen ausgetauscht haben und so weiter alles passiert hat man alles

schon gesehen. Was ist denn jetzt so gängig? Also wo du hast gesagt, früher war so jede Website hat ne eigene Datenbank gleicht ab. Ja. Das impliziert ja, da hat sich irgendwas geändert.

Richtig und hat sich deswegen was ändern sogar auch müssen, weil es kam dann ja, es kam dann ja so große Start UPS damals Startups. Hoch irgendwie, wie Google und Facebook und Yelp. Da gibt es n schönes Beispiel, das wird, wenn man das n bisschen, wenn man in den Google das mal n bisschen reinhaut, ich weiß nicht ob ihr noch Zeit und Lust dazu habt, aber dann findet man oft so n Negativbeispiel von einer jetzt sehr von einem jetzt sehr erfolgreichen Firma gelb

ich glaube die kennt man in Deutschland vielleicht nicht so, aber ich bin noch so erfolgreich, ich weiß nicht, ja ich weiß es nicht also ich hab mal geguckt das sieht noch ganz gut aus auf jeden Fall Silicon Valley und groß und damals also die hatten damals die wollten damals, glaube ich, von Google, also die hatten einen Wert davon, Informationen von dir auf Information zuzugreifen, die du bei Google hast und gegeben dieser Technologie, die ich gerade erzählt hab.

Wenn du warte mal, wenn du sagst bei Google haben meinst du da zum Beispiel deine Kontakte? Ne, ich spreche jetzt mal von den Kontakten, vorausgesetzt ich hab einen Google Account ja vorausgesetzt, dass du Google kaufst weil Google ist ja erstmal suche es gibt suche Google Account wie auch immer. Genau also worauf ich hinaus will. Ich nehme das vorweg, wenn eine Anwendung oder ein Programm eine Webanwendung. Von dir gerne Zugriff hätte auf eine dritte Anwendung, bei der du auch.

Authentifizierbar bist in der du auch einen Account hast. Dann kommst du ja immer in das Problem wie wie gibst du dieser dritten Anwendung das Recht auf einer anderen Anwendung von dir zuzugreifen? Ne, und jetzt kommt es, ohne dass du diese anderen Anwendungen, den Usernamen, das Passwort von einer Dritten gibst und ich nehm dir jetzt mal weg von Yelp, weil das kennt man nicht so gut, aber Spotify ja, jeder kennt Spotify ja und Spotify kann zum Beispiel.

Einen Wert daraus schlagen, deinen Google Contacts zu kennen, um dann in der Google in der Spotify Datenbank zu gucken, ob es Kontakte gibt und in die Spotify auch hat. Kann ja sein, dass deine Google Kontakte davon auch irgendwie paar Leute Spotify hören. Die haben dann ihre Playlist und so weiter und dann könntest du irgendwie coole Vorschläge von deinen Freunden, was sie gerne für Musik hören und so weiter

eingeblendet kriegen. Ja also also es gibt halt 1000 1000 gründe warum das Sinn macht so ja ich glaub das gibt es in ganz vielen Apps und so, also irgendwelche Fitness Apps wo wo du dich dann vielleicht mit deinem Kontakten vergleichen

willst. Das müssen ja nicht zwingend die Google Kontakte leiten, sondern auch die eigene Facebook Kontakte, sein Bruder oder was auch immer ja genau ganz genau so und jetzt aber aber das grundsätzliche Problem was sich daraus ergibt ist jetzt jetzt hab ich und in 2006 hätte ich keine andere Möglichkeit gehabt. Außer dass, weil es gab dieses noch nicht, über das wir sprechen.

Jetzt müsste ich quasi Spotify. Meinen Usernamen und meine Passwort von meinem Google Account hingeben, dann sagen die ja das kann, also mach das bitte, wir machen bestimmt auch nichts Böses damit, wir gucken uns nur die Kontakte an und dann loggen wir uns auch wieder aus und so weiter alles gut. Das wurde tatsächlich auch manchmal gemacht. Ja, zum Beispiel von dieser Firma Yelp, aber als no good.

Ja, ich weiß, ich mein, selbst wenn du, selbst wenn du der Firma vertraust, der du das gibst, du hast ja immer, du gibst ja immer quasi deine Daten weiter, was du ja eigentlich nicht willst. Letzten Endes, oder also Passwort und so n Kram ja vor allen.

Dingen, weil, weil das ist ja die Königs, das ist ja der Königslogin ne, also dann user Namen und dann Passwort autorisieren, ja dann die andere App, nicht nur die Kontakte zu lesen, sondern das ganze Ding. Also du hast ja heute im Google hast du ja nicht nur deine Kontakte drin, sondern vielleicht auch deine Firmendaten wichtige Dokumente,

was weiß ich nicht alles. Also im Grunde kann man sagen, das alte System ist dann an seine Grenzen gelangt oder ist in dem Moment an seine Grenzen gelangt. Wo plötzlich ein Bedarf da war oder das Requirement, dass Apps gezielt verschiedene Informationen miteinander austauschen, um den Nutzern ja im Zweifel ein besseres Nutzererlebnis zu bescheren, oder oder was auch immer zu. Machen, das fand ich im Zweifel auf jeden Fall so.

Ja, und das ist genau du hast völlig recht und das ist aber auch total gesund, weil wir wollen ja eigentlich auch nicht, und jetzt kommen wir wieder zu einer philosophischen philosophiefolge Single Source of Truth. Du willst ja auch verdammt noch mal nicht deine Kontakte 10 mal eingeben in 10 verschiedene Anwendungen, nur damit die irgendwie klarkommen. Du willst ja eigentlich tatsächlich nur, also du suchst dir dein dein Ding aus, wo du

alles mitanagest. Ich hab mir da mal, ich hab mir da Google ausgesucht, ja und dann will ich halt meine Kontakte genau nur im Google pflegen und sonst nirgendwo. Ja und natürlich möchte ich jetzt irgendeine andere Anwendung, wenn Sie die denn braucht darauf zugreifen darf, aber deswegen will ich die nicht hernehmen, Exportieren, importieren, kopieren und so weiter ob das. Jetzt für alle Menschen so ist, sondern hingestellt. Aber jetzt? Ist ja egal, aber.

Es gibt eine kritische Menge von Menschen, die das brauchen. Wir wollen, und deswegen gab es auch eine kritische Menge von Entwicklern, die was Neues haben einfallen lassen. Das ganze Konzept nennt sich, was komme ich, jetzt geht es weiter delegated Authorization ist das Stichwort Delegated Authorization, das heißt also abdilegierte Autorisierung, und das Macht das genau und wenn man sagt Delegated Authorization, dann ist man sofort heute bei Oors 2.

Es gab auch mal ein OAS 1 Alter Gammel kann man vergessen warum man nicht mehr erzählen, jetzt gibt es. Goors 2 Doors 2 OA uth heißt o aus OA UTH slash 20 nicht slash space 20 o. K. 2.0 ganz genau, und das ist die neue Welt. Und aus 2.0 ermöglicht der Delegated Authentication. So hin, außer ihr geht Oh storysation genau ganz ganz wichtig.

Deswegen haben wir am Anfang diese akademische Übung gemacht, 2 sein Autorisierungs. Floh Standard sind Standard also und und und zwar und zwar mittlerweile so so erfolgreich im ganzen Web verbreitet und nutzt eigentlich jeder. Ja, also alle großen, alle Großen sind auf jeden Fall dabei. Ja und wir kennen es von, also wo kennt also wir sehen das natürlich nicht, wo hat wahrscheinlich noch keiner gehört, wenn man sich damit nicht beschäftigt, will man eigentlich auch nicht hören,

weil es wirklich. Der Standard, ich habe da mal reingeguckt, das ist halt richtig langes Zeug, es ist richtig kompliziert, es ist echt heftige Materie, also will man gar nicht wissen, aber man kennt es, wenn man es sieht, irgendwann kann man der Login Button auch von Facebook, ich glaube die waren die ersten 2009 oder irgend so was, da kam es das erste Mal so, da wurde quasi sichtbar weil da stand dann irgendwo mal du kannst dich hier auch einloggen mit Facebook und.

Warst irgendwo anders und kannst auf einmal sagen Login with Facebook und jetzt muss ich n bisschen aufpassen, dass ich euch nicht jetzt jetzt der erfindige Zuhörer sagt, jetzt jetzt hat er Heisen gesagt, das ist n Autorisierungsframework und jetzt spricht er auf einmal Login ist Facebook ja, das ist aber doch Authentifizierung. Der findige Hörer hat genau

richtig zugehört. Das stimmt, aber trotzdem war das quasi der sichtbare Punkt für für ORS und Uros wurde an dieser Stelle schon so weit getrieben, dass man es auch n bisschen gehackt hat, sag ich mal. Und eigentlich. Über die Maßen genutzt hat sogar nicht nur als Autorisierung, sondern sogar als Authentifizierungsframe wirke. Das wurde abgestellt. Das das, das hat man gesehen, aber da hole ich jetzt ein bisschen. Ja, vielleicht erklär es doch erst noch mal kurz dieses. Kurz ist gut.

Ja oder kurz darüber, du sagst es zum Standard, der kommt ja auch nicht irgendwie aus dem Nichts, da Gedanken machen und müssen sich alle drauf einigen. Ist es so ein bisschen was wie ein Open Source Produkt oder ist das eher? Ein Framework? Nee, es ist tatsächlich eine, es ist tatsächlich eigentlich ein Web Standard, der also der basiert, das muss man wissen, also sie basiert erstmal auf dem Http Protokoll. Den sogenannten Rest APIS, so

die setz ich mal voraus, sonst funktioniert es nicht. Und dafür im Prinzip definiert das O aus eine Art Regelwerk, wie wenn ich das habe. Dazu komme, dass sie sicher sehr sicher. Einer einer Anwendung einer dritten Anwendung Rechte geben kann von einer zweiten Anwendung, in der ich schon authentifiziert wurde. Also da kann man sich, da kann man sich stundenlang mit befassen, weil es kompliziert ist.

Ich versuche es mal ganz einfach zu sagen und die ganz schlichten aha Erlebnisse die ich so hatte mal wieder zu spiegeln, wenn man, wenn man sich anguckt, muss man erstmal wissen, man ist quasi immer im Frontend erstmal es findet sich alles im Frontend, also ich bin irgendwie sagen wir mal ich bin bei Spotify auf einer Seite. Und dann sagt mir Spotify, so fängt das alles an. Ich hätte gerne Zugriff auf deine Google contacts. Ja und dann ist.

Im auf der URL wird nicht in Spotify bin das hört also irgendwie auf mit spotify.com oder sowas at Google contacts einen Button. Bei Spotify, Spotify will jetzt auf die Kontakte zugreifen. Wenn ich auf diesen Button drücke, was passiert dann dann passiert dann komme ich nicht auf eine Form die wieder bei Spotify ist, wo ich meinen Usernamen, mein Passwort von Google eingeben muss.

Nein und jetzt kommt was Neues, der Flow fängt jetzt an, jetzt werde ich directed das ist wichtig an Reed Direct, das kann ich ja immer machen wenn ich eine Anwendung habe, die kann ja quasi einen Link aufrufen ganz normal hyperlink zu einer anderen Seite und das tut sie auch und sie ruft auf einen ganz

speziellen Link und zwar. Den und jetzt kommt was Wichtiges. Den Link zum Autorisierungsserver von Google ist ein wichtiges Konzept, um dieses Ganze um diesen ganzen Kram von dieser Autorisierung aufzuräumen, hat man sich erstmal entschieden, dass es einen eigenen Server gibt, denn nichts anderes macht als Autorisierung für alle. Und und der hat ne eigene API. Ja und den ruft Spotify nun auf und gibt ihm bestimmte Informationen mit in diesem ersten Aufruf ja.

Sind im Prinzip 3, wenn man es runter brennt. Alles vereinfacht heute, aber es sind 3 wichtige Informationen bei diesem ersten Aufruf kommt eine sogenannte Redirectury rein, also eine eine URL, also eine Adresse wohin wenn der ganze Kram fertig ist, ob erfolgreich oder nicht, wohin die Reise wieder zurückgeht, der Weg nach Hause und dieser Re Directory ist typischerweise, hört aber auf mit Callback, das ist relativ standardisiert, also spotify.com Callback.

Wäre die Re direct UAI, weil es geht nämlich weiter.

Wir werden quasi immer weitergeleitet im Internet werden nur ein paar Kurven geleitet und ganz zum Schluss wenn das fertig ist dann ich habe quasi das immer mitgenommen, die Adresse nach Hause quasi habe ich mir gemerkt nach Hause telefonieren hier ja und dann komme ich wieder zu Spotify irgendwann zurück und dann wertet Spotify auf auf dem Weg was alles so passiert ist wertet es dann aus das erzähle ich gerade noch wie heißt das You are you unique Resources

Identifier? Das ist nichts anderes als deine URL allgemeiner Begriff dafür so dann gibt es das Nächstwichtigste ist der Scope. Ich hatte schon vorher erklärt das Scope, also die Spotify wird jetzt Anfragen. Nicht ich möchte alles von Google lesen, sondern das Scope ist quasi was möchte ich ja read contacts zum Beispiel ist der Scope ja oder ein bisschen mehr read contact read E-Mail. Oder, oder, oder diese Scopes, da gibt es, je nachdem wie

komplex deine Anwendung ist. Bei Google gibt es lange Listen von Scopes. Ja kann man sich vorstellen, weil die machen so viel. Ja da kannst du Tasks und es gibt milde Apps die erstmal versuchen alles zu kriegen und so weiter spiele. Oder sonst so gerade.

Richtig, richtig. Und wenn man das natürlich ordentlich macht in spotify.com ordentlich ist, dann machen die, dann werden die auch nur den Scope Anfragen, der halt minimal relevant ist um das zu tun was sie tun wollen, vielleicht in diesem Fall Kontakte lesen und nicht löschen oder so.

Vielleicht will man aber auch Kontakte editieren können, weil man dann, weil das auch vielleicht ein Feature ist, dass sich im Spotify auch mit meinen Kontakten quasi so umgehen kann wie bei Google, das gleiche Experience haben möchte. Gut, bleiben wir mal dabei. Aber egal. Lesen. Und dann gibt es noch einen wichtigen Ding sind Response Type. Ich sah sich ein bisschen weg, das ist typischerweise Code,

sage ich nachher was das ist? Ich lass mal kurz offen, also diese 3 Sachen, also wohin geht es wieder zurück, was ist der Scope den ich Anfrage und so eine Art Response Type, das ist ja, das ist dann quasi das Ergebnis, wie soll das Ergebnis aussehen? Dieser Autorisierung, die ich jetzt Abfrage, und jetzt werde ich weitergeleitet, tatsächlich auf accounts.google.com, das kriegt das alles mit. Und wenn ich jetzt nicht eingeloggt bin bei Google.

Meistens ist man ja schon irgendwie eingeloggt. Also wir sind meistens immer eingeloggt, Gerrit und ich, weil weil wir mit Google arbeiten. Wer es jetzt nicht ist, der würde jetzt die Authentifizierungsmaske von Google in ins Gesicht bekommen, ne also Google Login, das kennt man auch manchmal. Ja du drückst dann bei Spotify drauf und dann musst du erstmal bei Google einloggen, Usernamen Passwort aber der Unterschied ist wenn man jetzt oben in die

URL guckt. Ich bin halt jetzt bei Google, ich gebe jetzt nicht Spotify meinen Usernamen und und mein Passwort sondern ich gebe es Google und denen kann ich es geben weil denen gehört es ja auch, die Verwalten das und wenn ich das gemacht habe dann werde ich wieder weitergeleitet weil

Google weiß jetzt ich. Hier von so einem U. Ostweg West die die haben das quasi immer noch alles gespeichert im Hintergrund und jetzt jetzt wird jetzt werde ich gefragt, jetzt muss ich zustimmen, das ist total wichtig dieser Punkt ich ich als Nutzer ich als Resource owner so ist der Fachlingo in diesem OOS ich besitze ja die Resource Kontakte, ich werde jetzt gefragt darf Spotify da steht da man kennt diesen Screen manchmal.

Ich weiß nicht ob ihr es kennt, es wird immer besser Spotify wird immer transparenter, Spotify möchte zugreifen leasend auf deine Kontakte. Stimmst du dem zu? Ja oder Nein? Wer ist das nicht?

Ja, wenn ich jetzt nein sage, dann dann wird es zurückgeschickt, dann komme ich wieder zurück zu Spotify, Spotify liest aus, Nein, der hat das nicht gemacht so, dann läuft es im Sande, so drücke ich jetzt auf, ja dann passiert was Neues, dann wird jetzt quasi von Google dieser sogenannte Response Type Code generiert und Garrett, Du kennst dieses Coating, das passiert alles in der was passiert, du hast es tatsächlich schon gesehen, wir hatten eine App, wir machen das nämlich auch

in OOS. Who aus 2 Flow oben in der URL dieses lange Ding, da stand mal einfach so n Code gleich rüms und so weiter der hat uns schon mal gestört beim Einloggen. Dieses Ding ist quasi der Response Type von einer von einer funktionierenden. Funktionierten Erlaubnis über ein O aus 2 Flower und mit diesem Code komme ich jetzt zu Spotify wieder zurück und das war jetzt alles im Browser. Jetzt haben sich nur Browser Seiten hin und her gelinkt. Ja und jetzt schickt quasi Spotify diesen Code.

Zu deren Server ins Backend. Das ist wichtig, und das ist total sicher und fragt mit diesem Code bei Google nochmal einen Access Token an. Ja, und dann kriegt es das Access Token ist n ist kein Session Token, sondern tatsächliches Zugangstoken. Das ist sowas wie ein temporärer Username Passwort in einem ja auch so n String und hat Spotify dieses Access Token dann darf und und weil das Google ausgestellt hat. Und dann?

Jetzt darf Spotify auf einmal Google Anfragen nach den Kontakten von mir mit diesem Access Token und Google wird sagen ja das Access Token ist gültig, damit darfst du die Kontakte von Gerrit Meyer Anfragen, hier hast du sie. So, jetzt lange. Das war ne lange Rede, aber es war ziemlich kurze Rede. Für 2. Gibt es also das kann man sich auch noch viel länger angucken und es gibt ziemlich viele Variationen davon, dass jetzt mal der Standardweg, ich glaube, dabei belassen wir es auch.

Total nachvollziehbar. Also ich glaube, wichtig ist nur noch mal zu erwähnen, du hast das Beispiel jetzt gemacht mit Spotify als Dienst, der bestimmte Ressourcen eben aus aus Google aus dem Google Account, in dem Fall jetzt einfach haben möchte und zwar hier die Kontakte um dann zum Beispiel Spotify irgendein neues Feature anzubieten, Kontaktlinsen meiner Kontakte, Playlist meiner Kontakte anzeigen, aber das können ja beliebige Dienste sein, die da

miteinander austauschen, die aber beide. Diesen O. Aus Flow quasi unterstützen. Dann, das ist halt wichtig. Ganz genau, ganz genau, ganz genau. Und dann existiert das Access Token. Da habe ich mich gerade noch gefragt, wie lange existiert das dann so lange, bis man es irgendwie wieder löscht oder so was in der Art. Also ich weiß bei ein paar Diensten wie man das machen

kann, da gibt es dann irgendwie in den Optionen so Reiter, wo man dann gucken kann mit welchen anderen. System oder oder Services im Hintergrund so kommuniziert wird. Und dann? Kann ich es dann wieder rauslöschen?

Genau, du kannst also die Hoheit hast, weil du bist ja im Resource Owner, Die Hoheit hast du immer typischerweise kann sagt genau Google zeigt dir genau an, welche Anwendung haben welches Access gerade und du kannst sie einfach löschen und ist weg, aber die sind immer nicht für immer gültig access ich weiß nicht was die Standard Dings ist stundent. Es kommt vielleicht auch drauf an auf, auf welchen Scope könnt mir vorstellen, dass es unterschiedlich ist.

Je nach Scope weiß ich aber nicht aus dem Kopf haben aber also gerade das Beispiel was du gemacht hast mit mit Spotify und den Kontakten. Also es hält schon lange, es hält schon ne Weile ist glaub ich auch. Also bei mir hält das. Ja, vielleicht auch seit immer, seitdem ich das mal gemacht habe.

Ja, kann gut sein, ne, ich sehe tatsächlich freigegebene Playlisten meiner ich weiß ehrlich gesagt nicht, ob dir die ob das dann dabei steht, ich glaube nicht ehrlich gesagt wie lange dieses Access Token dann ausgezeichnet mein persönlicher Tipp an der Stelle ist einfach mal wenn man Google. Benutzt er privat oder beruflich? Sehr egal oder auch bei Facebook oder sowas mal reinzugucken in diese Option mal zu schauen welchen anderen.

Der Servicesurfparty Services Mandat tatsächlich schon welche Daten freigegeben hat. Das ist sehr spannend und dann auch zum Teil sehr überrascht. Sehr guter Tipp und das kann doch auch mal aufräumen zwischendurch. So genau, es sind nicht alles Trusted Partys, so viele Leute treiben auch ganz schön schindluder. Damit also je weniger, desto besser, denke ich mal an der. Stelle auf jeden Fall. Also alles, was du nicht brauchst, wieder raus. Ist auch meine Empfehlung.

Ja, und gerade also ich bin also ich habe es nur gehört, ich bin

wie gesagt selber kein Facebook Nutzer, bei Facebook gab es sowas auch in Omas irgendwie so Service Anbieter für alles die dann aber auch irgendwie dann. An wie gut sind die Rechte formuliert, die dann alles Mögliche, die Rechte an

rechtemäßigen Sachen dehnen? So und dann irgendwie irgendwelche Postings machen für dich und so keine Ahnung, gut, das war die Autorisierung, war die Autorisierung genau und jetzt wenn wenn wir jetzt so n Flow haben, dann kann man sich jetzt vorstellen Facebook waren die ersten. Im Prinzip kann man diesen ganzen Flow ja auch nehmen, um um eine Authentifizierung zu machen. Ja, weil wo ist der Unterschied? Es geht dann eigentlich nur noch darum, dass ich in der ersten Anfrage sage.

Gib mir mal die User ID und die Informationen zum Nutzer.

Ja, als also wenn ich jetzt typischerweise haben wir als scopes autorisierungs scopes, also lese, E-Mail und so weiter und sofort und was die aber gemacht haben, die haben sich quasi ein Scope ausgedacht und das war aber leider nicht standardisiert, weil man es halt quasi gehackt hat, aber so funktioniert es am Anfang und der ausgedachte Scope war halt gibt mir halt die Nutzerinformationen, die ID vom User usw und dann funktioniert das gleich, dann funktioniert es

eigentlich genauso und auf einmal kann ich halt user id s auslesen so aber das war halt das war dann halt nicht kompatibel weil es die da ein bisschen anders gemacht hat und so weiter und das hat dann noch mal. Zurück zu springen, den Login mit Facebook ermöglicht. Richtig, das ist das genau, danke Gerrit. Ja genau, also Login mit Facebook, wenn ich da drauf drücke auch heute noch dann passiert.

Es ist immer noch heute ein O aus 2 Flow, aber aber es gibt noch ein System oben drüber und das will ich auch noch mal namentlich erwähnen. Das heißt Open id connect, das war quasi die Reaktion darauf, dass man gesehen hat, okay die großen wollen. Ist halt die die Pressen das

durch, die können das ja auch. Facebook hat angefangen, Google hat sofort nachgezogen, ein Login ist Microsoft kennt man alles und dann gab es aber eine Standardisierungs ja Bewegung die quasi dieses diesen Wildwuchs gleich wieder eingefangen haben, Gott sei Dank.

Und jetzt? Eingepresst haben das sogenannte Open id Connect, was eine kleine Erweiterung ist auf den Oors 2 Flow, den ich gerade erklärt hat, obendrauf ja der das aber quasi standardisiert und man hat im Prinzip, was ich gerade gesagt hab, wie man es quasi gemacht gehackt hat.

So hat man es halt auch gelöst. Man hat halt quasi einen speziellen Scope zum zur User Authentifizierung erhoben und der heißt Open ID tatsächlich klein geschrieben zusammen Open ID, das ist n spezieller Scope. Ja und wenn der angefragt wird, dann heißt es ich möchte den Typen jetzt hier authentifizieren, authentifizieren und bekomme dann und dann passiert genau das gleiche also ich frag den also ich bin jetzt auf irgendeiner Webseite was weiß ich sogar auf

unserer irgendwie App einloggen und so weiter loggt sich ein mit Google dann geht's rüber nach Google. Der sieht den Open id scope weiß okay ich muss jetzt hier nicht Autorisierung machen, sondern Authentifizierung. Nach Open id Protokoll Lalala und dann passiert aber das gleiche, ich muss mich einloggen bei Google oder bin es schon je nachdem wenn ich nicht bin, dann muss ich mich noch einloggen, das muss. Man sich jetzt nochmal bestätigen. Meistens.

Ist es irgendwie nochmal bestätigen und so weiter das ist irgendwie ordentlich ist und dann werde ich weitergeleitet. Komme wieder zurück zur Anwendung und diese Anwendung bekommt quasi einen Code, mit dem sie die User Informationen

abrufen kann. Also bei Google ist das zum Beispiel alles mit drin, da ist expired Day Date von dieser Information, dass dann Avatar mit drin das wer du bist deine E-Mail alles was du brauchst um dich dann sauber ändert, das ist ja wer saß benutzt das klassische Klassiker du bist voll da. Das ist dieses, da steckt alles in diesem Open ID scope und was man da tatsächlich zurück kriegt, ist kein Access Token und deswegen hab ich jetzt schließen wir den Kreis von ganz Anfang.

Access Token ist ja so n das ist quasi so n Nichtssagendes drin und dieses Open ID Token ist jetzt ein JWUTT Token. Ja dieses JSON Web Token, weil das hat natürlich, das hat ja noch mal eine andere Qualität, sag ich mal, weil da eine Authentifizierungsdaten drin sind, deswegen ist das auch noch mal besonders gesichert und kann auch langfristig dann quasi beim Client gespeichert werden. Weil da die Informationen im Token schon drin stehen. Und das hat einen Header.

Dann stehen die Informationen über dich da drinne und eine Signatur, das heißt es kann auch nicht, es kann auch nicht modifiziert werden, ohne dass keiner mitkriegt, ja das wird ausgestellt, einmal von Google und zertifiziert quasi Siegel drauf wieso ein wieso ein Siegerring drauf gedampft und dann kannst du auch nicht mehr sagen okay ich war jemand anders oder irgendsowas ist Abgesiegelt und im Prinzip funktioniert das alles so ja das genau und zusammen ist das die moderne Art

und Weise. Wie man heute Authentifizierung und Autorisierung macht? Ja, und das, das war jetzt der Sign Prozess, der quasi den du gerade beschrieben hast. Ne, also das Initiale Anlegen eines Accounts unter Nutzung der. Google Nein, das Signup ist noch mal anders. Ich sprech von sign in ah, du sprichst wirklich Signal. Ja ist schon sign in ne also sign in oder Login ist Anonymous, also ist das gleiche ne Signin und Login setzt voraus, dass ich bereits n

Account habe. Ja wir haben diese alles das wir heute besprochen haben hat nichts mit Scientup zu tun ja okay Signal ist ist auch ist unkritisch weil Sign heißt nichts anderes als ich lege irgendwann mal einen Account an das heißt auch nichts anderes nach wie vor, dass bei dem Server wenn ich zum Beispiel das bei Google mache. Dann wird halt im Google Authorization Server mein Username und meine E-Mail tatsächlich verschlüsselt.

Irgendwo muss es ja mal liegen, also das was ich ganz erzählt habe ist am Anfang alt ist. Das passiert ja trotzdem noch, weil irgendwer muss ja das Passwort kennen, es reicht aber wenn es quasi nur noch einer Vertrauenswürdiges kennt und alle anderen sich da quasi ranhängen, das ist das neue aber und und das Initiale erstellen dieses Perchens Username und Passwort, das ist der Sign Prozess, also Account Creation. Ich mal. Ja genau, den haben wir aber heute nicht gar nicht besprochen.

So ja, also. Das heißt, bei jedem Sign in oder Login ja was das Gleiche ist, passiert dieser Flow noch, den du besprochen hast? OK, ja OK, aber jetzt noch mal zum Signup. Also wenn ich jetzt irgendeinen Webdienst das erste Mal benutze und ich wähle zum Beispiel Signup mit Facebook oder ich wähle Signup mit Google oder Signup mit Apple oder mit Microsoft oder was auch immer.

Dann wird eigentlich werden diese Nutzername und Passwort bei einfach bei Google hinterlegt sozusagen und dann beim nächsten Mal beim Sign in. Ne, beim Signal gibt es ja kein neues Passwort. Ein für den Service auch nicht. Beim Signal ist es im Prinzip ist das das Signup wenn du ein Signup mit Google machst auf einer anderen Anwendung, was brauchst du denn, was brauchst du denn in der in der Anwendung

die die jetzt nicht google ist? So wird es irgendwo Signal die braucht nichts anderes als deine id Daten die braucht deine E-Mail und die braucht dann vielleicht noch deinen Avatar mehr ist es ja nicht wenn die zuverlässig auf die braucht gar nicht dein Passwort weil war zuverlässig den den diesen Flow machen kann was die davon geht sie aus, weil die ja schon mal Signal über diesen, über diese, über den Drittanbieter machst.

Ja braucht ihr das gar nicht und das Signup ist nichts anderes, als dass die einmalig der User angelegt wird und quasi in der Anwendung signup Signal hat es nicht so furchtbar, ist nicht so furchtbar spannendes Thema und auch nicht so sicherheitsrelevant, da wird halt quasi für dich ein Account hergestellt und in der Anwendung werden solche Container hochgezogen, irgendwie Ressourcen freigegeben, dass quasi dein Workspace eingerichtet was weiß ich Hallo

Gerrit und so weiter kriegst du mal eine E-Mail geschickt und so weiter Welcome. Wirst du nur gespeichert als User in dem System? Da muss ich mich ja nicht authentifizieren, da bin ich ja, der ist automatisch der der sich anmeldet, quasi ja so. Also insofern ist das ist das n anderes Thema, sage ich. Mal OK, gut kopiert.

Und ich wollte nochmal einen Namen sagen in diesem ganzen Zusammenhang, der mir quasi auch geholfen hat, das noch mal das Dickicht noch mal so ein bisschen zu durchdringen und es, das ist Nate barbetini. Früher Entwickler bei Okta ist die Firma, die hinter zum Beispiel O. Aus. Nicht uros, ich spring es dann aber durcheinander. Hinter Ask Zero steht aus Zero ist quasi ein ein ein ein Ja ein Service Provider, der genau das was wir heute alles besprochen macht als Service macht.

Wenn man das jetzt also man kann das natürlich selbst implementieren. Kann und es kein geschlossenes Geheimnis, aber doch ne ziemliche Herausforderung, würd ich noch sagen für Entwickler und man darf da sich auch keine Fehler leisten, kann man sich verstehen warum. Und wenn man das nicht möchte, dann kann man zum Beispiel ja Rosiro benutzen und einer, der einer der.

Coolen Entwickler da ist Nate Barbetini wie gesagt, der hat im Internet ja n paar Sachen veröffentlicht zu diesem Thema und es gibt viel Trash im Internet und ich würde sagen, wenn ihr was lesen wollt und noch mal tiefer einsteigen wollt, hört euch das an was Nate sagt. Der, der weiß, wovon er spricht. Perfekt. Dann linken wir das Video natürlich wie immer ne, du sag

doch mal was zu Single sign on bitte das richtig Stichwort kommen wir bei denen ganzen Sachen auch noch so im Kopf irgendwie. Ja, also genau Single Sign on. Also das kennt man ja da. Was heißt denn Single sign on? Heißt er eigentlich, dass ich nicht bei jedem Doodle und Dödel irgendwie meine neue Usernames und Passworts eingeben muss?

Also es gab ja mal eine lange Zeit, als dieses UOS noch nicht so etabliert war, ich sag mal so, zwischen dieser ganz anfänglichen Zeit so, Oh, das kennen wir ja, und deswegen gibt es ja auch diese Passwortmanager und so weiter du musst ja, du hast ja zig Services, deine Bank und übrigens die Banken kann auch noch mal sagen, die Banken. Auch nicht so weit, dass sie irgendwie, obwohl sie es schon so lange gibt und überall im Internet Standard ist, haben die Banken das noch nicht

akzeptiert. Ja, was die Bank gewählt haben, hat das aber ne, ja genau, aber also wenn ich sage die Banken, da meine ich so 90% dieser Standards und so weiter ne. Also die diese, die sind dem Ganzen hinterher noch so.

Ja, und die haben manchmal noch so gruselige Sachen, wo wenn da gibt es manchmal so APIS, die dann einsammeln für dich, wenn du mehrere Konten hast, was weiß ich Kommerz und Deutsche und hast du nicht gesehen, da musst du dann tatsächlich noch Usernamen Passwort von jedem einzelnen Dings eingeben, totale

Chaos, aber die das aber egal. Überrascht mich irgendwie auch überhaupt nicht, aber gut, wir waren bei Single Sign on genau und das ist quasi die Antwort auf den Schmerz, dass ich überall, wo ich mich irgendwo einlogge im Internet einlogge, ja meinen eigenen Username und ne andere E-Mail hab ja und wo dann die Leute sagen, ja du darfst auf jeden Fall dann nicht überall das gleiche Passwort nehmen, weil es ja total

unsicher ist. Ja auch total richtig, weil die alle, wenn die alle ihr gammeliges Authentifizierungssystem machen und die Leaken halt die Passwords dahin und du hast halt überall das gleiche so und Single Signal heißt ich will mich halt nicht bei jedem verschieden. Webservice mit einem neuen Username und Passwort Paar einloggen müssen, authentifizieren und autorisieren müssen.

Ich möchte halt es nur einmal tun und da und das könnt ihr euch vorstellen, davon haben wir eigentlich gesprochen, die ganze Folge lang, also wenn wenn wenn ich halt ein ISP habt ihr ihm vertraue ein Identification Service Provider Identification ist der Oberbegriff für Authorization und und und authentification also wenn ich zum Beispiel Google einmal vertrauen möchte oder Facebook. Das heißt Microsoft ja oder sogar vielleicht irgendwie. Und SSO kann man ja auch.

Ne SSO wäre im krassesten Sinne webweit durchs ganze Internet, da muss ich jemandem vertrauen wie Microsoft, Google, Facebook oder Github oder sowas, ja dann funktioniert es genauso und dann mach ich und wenn die Dienste das anbieten, dann hab ich Single Sign on weil geht alles nur noch über meinen Google Account bums aus und ist total easy ich muss mir kein anderes Passwort mehr merken, dann kann ich das machen oder es gibt manchmal auch wenn du große Konzerne hast haben die oft ja

auch schon so Active Directorys und so weiter und die haben ja auch zig Dienste und Abteilungen, das ist dann nicht ganz so OS 2 oder vielleicht sogar doch, kommt drauf an wie sie es implementiert haben, aber das heißt auch Single Sign on du loggst dich einmal morgens ein. Firmennetz und hast halt Zugriff auf die ganzen Services, weil halt da irgendwelche Dienste drüber sind, die quasi dieses Ganze unter authentifizieren auf andere Dienste und so weiter für dich ablösen.

Ich glaub es. Hat einfach irgendwas, macht genau sowas auch ne machen so. Machen sowas auch. Genau das gibt es auch noch. Ich hab jetzt heute ein bisschen, es gibt noch so Protokolle wie Sammel und so weiter es gab natürlich Zwischenstufen bis wir zu diesem wo wir sagen, jetzt ist es eigentlich schon relativ lange so, dass Oors 2 einfach der Platzhirsch ist. Das hat sich erfolgreich etabliert, das scheint so ausgereift zu sein, dass auch nichts mehr fehlt.

Ich mal nicht, weil das ist ja so ne im Internet, die ist ja einfach so ne Evolution der Dinge. Ja, zwischendurch gab es halt sowas wie sammeln noch und so

und diese alte Gammel, der lebt halt noch irgendwo und das haben nicht alle umgestellt und dann gibt es so Firmen wie Okta die da halt drüber bügeln, dass sich da keinen Schmerz hab und dass ich trotzdem das Ding jetzt sign on Erfahrung bekomme als Nutzer. Und die bügeln alles und drunter glatt mit irgendwelchen Bridging

Services und so weiter. Wie ist es jetzt als als sag ich mal als Heisenwert zum Beispiel können wir selbst so einen Flow aus Flow os 20 Flow implementieren oder brauchen wir auch immer einen externen Anbieter um sowas auch nutzen zu können oder sowas? Also wie kann man sich das? Vorstellen. Sehr.

Gute Frage, Es geht. Beides, ja genau, und vor allen Dingen, als ich mich jetzt vorbereitet habe für die Folge, habe ich mir gedacht, okay ist ja doch gar nicht so kompliziert, ich habe es immer nie, also ich habe immer gedacht, so, also pass auf, das ist ja.

Ich mach das jetzt auch, Software nicht seit gestern so, aber das sind ja so Themen bei Authentifizierung und Autorisierung denk ich mir immer so, da darf halt auch nichts schief gehen so ja, also wenn das irgendwie weggedrückt kriegst, drück es halt weg zu irgendjemandem der weiß wie es geht. Ja und so machen wir es gerade. Es ist aber tatsächlich kein Hexenwerk und wenn du diesem Framework folgst, diesem Ohaus 2, da kannst du auch gar nicht

so viel falsch machen. Man könnte es auch selber machen. Ja, wir. Wir haben natürlich jetzt im Moment 2 Anbieter, sogar die wir, die wir benutzen. Tatsächlich sind wir mit mit Ossiro dabei, jetzt haben wir ne neue Firma vielleicht, die kommt jetzt rein, ich sag das einfach mal. Member Stack sieht auch ganz gut aus und die die machen das quasi auch nebenbei als Dienst. Weißt auch kein es kann Voodoo ja also. Und dann kann man sich einfach mit dranhängen an diesen Dienst und musst.

Und im Prinzip macht man es, man implementiert es, aber es gibt quasi ne Art SDK Software Development Kit, das klebst du halt in dein React rein, das heißt dann irgendwie React Member Stack so und dann sage ich halt, dann habe ich da so ein Hook wie das heißt, also hochliegende Funktionen sage ich ist der authentifiziert und gibt die Funktionen Zeilen ab, gibt es tatsächlich so einfach gab es die Vorsign Sign in und ist authenticated da so weil ich als Entwickler in meiner App brauche

ich gar nicht so viel mehr als das und ich kann irgendwie die user Daten abrufen und das gibt dir das Ding halt for free ja was soll ich dann jetzt noch muss ich mir nicht selber mit dem o aus 2 geraffel da irgendwie an die Haare schmeißen so. Jaja, das ist total wichtig. Ja, aber mein kleines Team hat, muss man sich ja auf die Kompetenz. Ja, genau deswegen machen wir das so, ja. Dann war es das zum Thema Authorization und Authentication.

Oder? Ja, ich hoffe ich hab es mitsamt mit genügend Samthandschuhen angefasst und nicht nicht viel Quatsch erzählt, aber ich ich hab es auch hoffentlich auf einem Level gehalten wo wir das irgendwie einigermaßen durchgestiegen sind. Ja, und du hast es vor allem immer richtig rumgesagt. Ich habe es öfter mal verwechselt, Autorisierung und. Authentifizierung aber es ist klar, das müssen wir nochmal zurückspulen zum Anfang. Ja, ich fand, das war doch eine würdige Folge. 50.

Auf jeden Fall würde mich freuen, wenn ihr uns treu bleibt für die nächsten 50 folgen. Ja gut, ja, das wäre natürlich schön, ihr merkt. Schon wir machen jetzt ab und zu mal Gäste und dann wieder eine Folge ohne Gäste. Sozusagen, versuchen jetzt diesen Rhythmus so Beizubeimen, aber mal sehen. Ja, ich hoffe, es hat euch Spaß gemacht und es war auf einem verdaulichen Level.

Ja schauen wir mal. Es kommt auf jeden Fall nochmal eine Folge, die ist schwerer verdaulich, das kann ich jetzt schon mal sagen, freue mich aber auch drauf, ich glaube wir haben noch mal eine Blockchain Blockchain Folge schon im petto. Ach so, ja auch ob die so schwer, ja. Die ist schön, da könnt ihr euch schon drauf freuen. Wer nochmal Blockchain in die Deep hören will. Darf da gerne noch mal zuhören, mit Experten, mit Experten? Ja, auf jeden Fall, das hätte ich nicht alleine gemacht.

Prima also das war es für heute. Danke fürs Zuhören und Danke Burkhard, bis nächste Woche Tschüss aus Hamburg. Einfach komplex wird produziert und präsentiert von Heisenware. Weitere Informationen findest du unterheizenware.com. Vielen Dank fürs Hören dieser Folge und bis nächste Woche Tschüss aus Hamburg.