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.