User Management und Authentifizierung im Web #64

Moin liebe Zuhörerinnen und Hallo und herzlich willkommen zu Folge 64 von Einfachkomplex heute wieder in der gewohnten Konstellation. Ich lass mir ein bisschen die Welt erklären der Software und Burkhard wird seinem Ruf als Experte gerecht. Schauen wir mal. Moin, hier aus Hamburg. Schauen wir mal.

Und es ist ja noch immer Sommerpause und wir haben uns jetzt trotzdem ein Thema rausgesucht, was gar nicht so super einfach ist, aber extrem spannend und für viele aus Entwicklerperspektive wie auch aus Nutzerperspektive ein Thema ist, mit dem man oft in Kontakt kommt und dass das User Management, da gibt es ja auch viel zu wahrscheinlich viel falsch zu machen, viel was man beachten muss, wenn man das mal selber implementiert und wenn man von außen drauf guckt, ist

mein Gefühl, dass das ist eigentlich. Je besser es läuft, desto weniger denkt man drüber nach. Das ist total richtig. Weil es einfach so diese ganzen Flows sind da. Ich stelle mir ein Passwort, ich erstelle einen Account mit Google, den ganzen Kram, was alles dazu gehört und dem Thema wollen wir heute auf den Grund gehen, ein bisschen aufräumen, was da alles gibt und dass es euch näher bringen. Hast das, so Burkhardt.

Passt ja genau, ist also quasi ne Software architekturthema User Management. Und, Na ja, so wie du sagst Gerrit ne man. Man denkt immer so es fällt wo

kommt das vor? Ja also ich mach irgendwie mal so n sign in oder sign oder irgendwie und dann war es das ja Pustekuchen ne hast du mich wenn man es bald tatsächlich umsetzen muss doch ziemlich gewaltig und ziemlich groß ja wir versuchen es aber trotzdem in der Kürze der Zeit irgendwie zu verhandeln ich sag auch noch was vorweg ums Einzunorden Wir bleiben im Fokus wieder. Mal Webtechnologie und wir bleiben auch so ein bisschen im Fokus.

Spa, also Single Page Applications, die moderne Art und Weise, wie ich halt heute Frontend mache, das ist ein bisschen, das hat einen Einfluss darauf, wie ich das Management nachher kommt nachher noch raus und noch ein Disclaimer vorweg, ich möchte es so ein bisschen so machen, dass wir ja uns die Software Architektur angucken sowie so ein bisschen in der Brille, wie wenn ich jetzt quasi das umzusetzen hätte mit meinem eigenen Produkt wäre ich quasi Software Architekt oder

Entwickler oder irgend sowas ja also. Das wäre auch mal so ein bisschen, wie wir es ja immer machen wollen. So ein bisschen unter die technische. Gucken und mal schauen, was da drunter so für n Staub ist. Ja, ist doch super. Du musst ja nicht nur so tun, als würdest du es machen, du hast es ja schon gemacht, richtig, in verschiedenen

Ausprägungen und deswegen. Genau, ich kann da n bisschen aus dem Nähkästchen erzählen, deswegen machen wir auch die Folge. Ich bin gerade frisch aufgegleist, was das alles angeht, vielleicht ist das ganz hilfreich für die Frisörende. Gut, dann trink du nen Schluck

Kaffee. Wir haben genug der Anleitung jetzt gemacht worden, rein starten ins Thema und als erstes Mal klären was ist so ein User eigentlich, was bedeutet das wenn man über User Management redet? Ja, ganz genau. Also wenn man es naiv denkt, dann gibt es eigentlich nur die User, die man halt sehr user, der halt quasi in die Applikation rein möchte. Also, wovon sprechen wir denn überhaupt?

Wir wollen ja erstmal user Management, heißt ich muss erstmal überhaupt wissen, was bei User ja und wenn ich überhaupt user haben will, muss ich erstmal eine Applikation haben, das setzen wir jetzt mal kurz voraus. Also ich habe irgendwie eine App.

Was auch immer, ist ja auch Wurst da und jemand klickt dahin, der das benutzen möchte und der kann das aber nicht einfach nur benutzen, das gibt es auch, das ist halt public public und ich weiß nicht wer es geklickt hat, nein, wir sprechen heute darüber, dass jemand sich da anmelden muss, also ein Mensch, ein User, so wie du Garrett ja oder wie ich und wir machen das, indem wir entweder unter unsere E-Mail eintippen und unten ein Passwort oder aber vielleicht noch cooler irgendwie

über Google Login und so weiter kommen wir später zu, aber das ist quasi die eine Kategorie User das versteht.

Jeder. Es gibt aber noch und ja, ich hab ja gesagt, technisch, es gibt noch viele andere User, mindestens eine Gruppe von Usern will ich jetzt noch mal ganz kurz erwähnen, denn wir haben ja, wenn wir ne Anwendung haben, gibt es ja Business Logik in der Anwendung, das ist ja irgendwo implementiert, also wenn wir nicht gerade nur eine statische Webseite anzeigen, unsere Anwendung haben wir noch ein bisschen mehr zu tun und wir haben ja auch schon mal bei

Docker zum Beispiel gesprochen über Microservices und so weiter dass ich würde jetzt einfach mal voraussetzen, dass wenn wir jetzt hier über eine moderne Anwendung sprechen, dass wir modernes Backend auch haben und dann haben.

Wirklich irgendwie sowas wie Docker Container und die haben ihre verschiedenen Aufgaben und die lesen dann aus einer Datenbank und so weiter und sofort diese Docker Container, wenn die miteinander sprechen oder wenn die ne Datenbank aufrufen wollen ne die Datenbank selber ist auch n dockercontainer das hab ich n anderen Docker Container der wir mit der Datenbank sprechen, der muss sich auch authentifizieren, der muss ja die Datenbank hat verdammt noch mal auch einen

Usernamen und ein Passwort und sollte sie ja das sag ich jetzt mal ganz ganz klar es. Ja, es gibt ja auch Leute, die haben im Backend ist alles wurscht und alles offen, ist

aber gefährlich. Ja, also die Datenbank muss auch, dagegen muss ich auch authentifiziert werden und so weiter das heißt, ich habe sowas wie Klienten, technische User, die tauchen nie auf außen, aber die gibt es sehr wohl und je komplexer mein System ist je mehr microservice ich habe und je mehr Kommunikationskanäle ich zum Beispiel habe, weil ich vielleicht noch mit Maschinen kommuniziere oder mit.

Mit der Blockchain, die irgendwie noch geschützt ist, oder oder, oder, oder ja, desto mehr user kriege ich da noch rein, die, die sich an bestimmten anderen Dingen authentifizieren müssen. Ja, und die muss ich auch alle managen, ja und das muss auch in das System mit rein gedacht werden, im besten falle ja und wenn ich das als Ganzes

einheitlich System haben. Will ja, und diese 2 Parteien jetzt sagst du also klar der menschliche Nutzer plus diese Klienten die sich irgendwie authentifizieren sollen. Die Erschlage ich im besten Fall mit einem Authentifizierungssystem, ja. Genau, ist natürlich Geschmackssache, so aber also genau, wir haben es halt hinter uns. Tatsächlich war die High Sinware mit mehreren Authentifizierungssystemen unterwegs für verschiedene Sachen, das geht, das ist aber

irgendwie. Also wenn ich schon sage, es ist nicht schön, also es ist immer immer wenn du wenn du den Kuchen zerstreuselst für die für das Gleiche, für die gleiche Logik. Dann macht es eigentlich keinen Sinn, also in der idealen Welt hast du ein System, was alles kann und da da speist du alle deine User ein und kannst nach den einen Suchen und Filtern und Anzeigen und so weiter. Egal. Willst du die jetzt nach außen in die App, willst du jetzt nicht diese Klienten nach vorne bringen.

Das soll ja keiner sehen. Ja musst du ja aber auch nicht, das kann ja dein System leisten, ne? Ähm, ich finde es einfacher, wenn man alles an einer Stelle hat und es ist sauber und es ist glasklar. Und ja, du hast da weniger, auch managementschmerzen weniger am Ende weniger Code, das ist das Wichtigste. Ja, also als softwarearchitekt, wir wollen dazu hin, dass wir große Systeme haben mit ganz wenig eigengeschriebenen zeilencode, ansonsten können wir es nicht verwalten.

Prima, das setzt uns schon die Brücke.

Dann jetzt zum zweiten Thema, was du vorbereitet hast. Also wie kann ich das realisieren und du hast es schon gesagt, wir hatten es in der Vergangenheit mit 2 verschiedenen Systemen realisiert, jetzt ist es unter einem Dach, also bei der heißen wir jetzt wieder gesprochen, ich würde es mal ein Beispiel, ich glaube das ist auch okay, aber was kann ich denn grundsätzlich machen, was für Möglichkeiten gibt es so eine Authentifizierungssystem oder user Management eigentlich umzusetzen?

Also ich glaube, jeder Softwareentwickler hat es einmal selbst programmiert und wenn er es nicht hatte, sollte. Er es einmal tun, vielleicht dann nicht für die komplette Produktivität produktionslösung, aber es hilft total. Ist einmal ein bisschen gemacht zu haben.

Früher war das der Klassiker. Also als wir noch hier Lamp hatten, also Linux, Apache My SQLPHP und so weiter diese klassischen Dinger mein Gott, da hab ich halt ne Datenbank gehabt ne ich war User gehabt, das ist auch kein Raketenwissenschaft, da hab ich mir halt selber ne Datenbank geschrieben und so weiter kurzum ich hab es selbst programmiert, ja.

War damals auch noch völlig möglich und easy heutzutage, wenn wir drüber nachdenken, was wir in einem saßen, da sprechen wir im nächsten Ordnungspunkt drüber, was wir alles so für Anforderungen haben an das User Management, dann sind die krass gestiegen und ich rate jetzt nur noch jedem davon ab selbst zu tun. Ich habe tatsächlich das auch noch mal selber implementiert, aber auch nicht alles nur ein Teil von unserem User Management. Und ich habe alles, sag ich jetzt einfach mal.

Ich hab es alles einfach platt gemacht, weggeschmissen, ausgetauscht. Ja, und wenn man, und das ist gut, ja, es fühlt sich also am ersten Moment, denkt man so verflixt, ja, die schlaflosen Nächte und die ganzen Code, und was habe ich alles geschrieben. Ungebremst in die Tonne geschmissen und danach mit dem Juchi irgendwie aufgestanden.

Gesagt. Ja, das war alles richtig so, ja, aber das ist glaube ich auch was, das wird jeder, der ein bisschen länger in der Software ist, irgendwie auch schon mal erlebt haben, das das ist halt so. Ja und noch mal je weniger selbstgemachter Code, desto weniger. Probleme habe ich weniger Maintenance ja, es gibt so viele tolle Produkte außen, ja und die kann ich entweder einkaufen oder sogar open Source.

Ja, und da gibt es Teams, die testen das alles und so weiter die machen das für mich, also muss ich mir das nicht selber an die Jacke schmieren. Wo ich auch gleich zum nächsten Punkt komme. Was kann man denn dann machen, wenn man es nicht selbst macht? Und da gibt es, bin ich jetzt hier im Saas und Web Business spreche, Gerrit gibt es nämlich 2 Möglichkeiten, es gibt das komplett als Service wie es so

alles Mögliche als Service gibt. Ja SL Service sag ich mal und hier würde man sagen können Authentication und Authorization SA Service das kann man los googeln, da gibt es zig Firmen und die unterscheiden sich mit minimalen Ausprägungen. Und die haben aber auch Pricing Modelle unterschiedlich und so weiter ich nenne mal 1 mit dem wir nämlich auch unterwegs waren. Ist so ein Dinosaurier von früher ist ein großes System, funktioniert einfach Zero. Das ist aber nen Service n Dienst.

Ja was heißt das was ich quasi ich lagere mein gesamtes User Management aus von meiner App, das heißt die ganzen Datenbanken, alles das was ich tatsächlich die ganzen das ganze die ganze userverwaltung ist halt nicht mehr in meiner Hemisphäre in meiner App sondern. Unter der unter den Servern verwaltet von diesen Dienstleistern, in diesem Fall in Ost Zero ja, wo immer die auch stehen, da muss ich natürlich auch aufpassen, DSGDSGVO konform, wenn wir in Deutschland sind und so weiter

darf ich das alles? Passt das alles ne mit den Usern und so weiter Datenschutz ist da ja ne wenn wir user Management sprechen, dann sprechen wir hier immer ganz ganz ganz wichtig über Datenschutz und so weiter das muss natürlich garantiert sein. Das ist eine völlig. Es ist völlig okay, das auszulagern.

In meinem Kopf wird das schon ein bisschen schwieriger, wenn ich da meine Klienten mit auslager, also weißt du die die inneren User, die da machen, die würde ich dann glaube ich schon fast wieder trennen, wenn ich so als Service mache, das fühlt sich jetzt in meinem Bauch erst mal komisch an.

Würde ja bedeuten, wenn ich jetzt so einen Klienten, so eine Datenbank zum Beispiel, die sich irgendwo authentifizieren muss, dann über einen externen Service nochmal gehen muss, um sich intern in der Software. Zu authentifizieren oder so merkst. Du auch schon. Das klingt komisch und vor allem das hat auch was mit Performance zu tun und so weiter extern heißt ja auch immer. Ich hab halt nen HTTP request. Ja und vielleicht nicht nur

einen, sondern viele. Ja, das und und dieser Dienst muss ja auch erstmal available sein, vielleicht haben die mal n schluckauf und so weiter. Also ihr merkt schon, hat Vorteile. Also der Vorteil ist ganz klar,

ich bin sofort fertig. Ja ich hab quasi nen Service, ich hab ne API ich bin ich schreib das ziemlich schnell hin, ich Krieg auch typischerweise, das machen wir auch noch mal im im später im Nachgang, ich krieg typischerweise auch so diese E-Mails und diese ganzen Login forms und so weiter auch alle geschenkt weil es halt weil ich gar nicht mehr auf meinem Server das mache, ich mache das quasi in dem in den Servern dieses Dienstleisters und wenn die gut

sind, dann kann ich sogar meine forms customizen gerät du hast das auch ein paar Mal gemacht. Slowcoat dann am Ende. Das ist auch cool und das sieht auch super aus. Da gibt es überhaupt gar keine Frage. Also und wenn das einem reicht, dann ist das die richtige Wahl, vielleicht schon hier kommt der Disclaimer, warum ist das vielleicht nicht die richtige Wahl und für uns war es auf jeden Fall nicht die richtige Wahl, weil. Oder ich hab jetzt halt nen Internetdienstleister.

Ja und wenn ich aber meinen wenn ich nen SARS Produkt habe, was ich aber auch jetzt kurz kurz kompliziert das aber auch um Premis mal installieren möchte. Was heißt denn jetzt hier on premise, also in einem privaten, in einer privaten Cloud oder sowas im privaten Netzwerk, wo der Kunde, bei dem ich das installiere, keinen Bock drauf hat, dass sie irgendwie noch Ports und irgendwelche Services angefragt werden, dann kann ich das schon nicht mehr machen. Weil es halt einfach nicht in in

meiner Software mit drin ist. So. Ja, das ist zum Beispiel ein, das war für uns n nasser Grund ist nicht ist nicht zu tun. Wir haben lange überlegt, wie machen wir es hin und her, machen wir einen externen Dienstleister oder so. Wir haben jetzt, und jetzt kommt ich, komm ich zur dritten Variante, also erster Punkt.

Wir selbst machen. Klar müssen wir mal gemacht haben, aus Spaß kannst du mal n Projekt machen, so sag ich immer ja dann wegschmeißen und nimm wie es wie es die Experten machen, also zweitens einfach als Service voll aus voll auslagern die dritte Variante ist und die finde ich die allercoolste ich möchte auch ein bisschen hier heute ein bisschen Werbung machen dafür für vielleicht Start ups die auch User Management machen wollen ich sage euch nehmt sowas und

jetzt sage ich auch einfach den Begriff Fusion Alls nehmt sowas wie Fusion aus, da gibt es noch andere. Aber das ist quasi so eine Art ja Open Source Bibliothek. Aber aber auf einem Viertel höheren Level. Also es ist quasi auf Docker Container gelöst.

Ich habe quasi auch den gesamten Service, aber den kann ich quasi und auch ein Frontend und so weiter das ist alles vorbereitet und auch E-Mail Management und Fonds und alles und auch Datenbank Integration, aber die Datenbank die Managed selber. Ich habe meine eigene Datenbank in meinem eigenen Container und dann habe ich dieses Fusion, das kann ich installieren als Docker Container. Und auf einmal habe ich von beiden das Beste. Ich habe nämlich.

Sehr vieles vorbereitetes Krams, diese ganze Datenbanklogik wie ich das aufbauen, alles fertig, muss ich mir keine Gedanken machen, hab ne API, aber die lebt quasi in innerhalb meiner microservice Architektur. Weiß nicht, ob das jetzt so schnell verständlich ist, aber ich hab im Prinzip diesen Service genommen, der Webservice, aber ich zieh den quasi in mein eigenes SARS Produkt mit rein, ist halt ultra Ultra cool. Ja, also du hast.

Quasi Code eingekauft oder bis zu einem gewissen Punkt ist es jetzt bei Fusion auch so, dass man sogar den gar nicht einkaufen muss, sondern gratis erhält. Ja. Genau, weil es auch ne relativ hohe, also es sind auch nicht ganz trivial. Man muss komplett dieses System inhalieren bis man versteht wie man es integriert in sich selbst. So aber genau. Ich denke mal, dass da Fusion jetzt zum Beispiel Fusion aus oder andere Anbieter wahrscheinlich auch Geld über Support nehmen.

Auf jeden Fall verdienen würden, wenn jetzt. Wir haben uns da jetzt tief rein gefuchst, insbesondere das ging ja auch ein bisschen länger das Projekt, aber wenn man das jetzt, man kann natürlich auch als Firma Support dann Anfragen, denke ich mal, und dann kriegt man Hilfe bei der Integration eines solchen, ja. Auf jeden Fall. Und die haben auch noch so pro Features, wenn es an Two Factor geht und hier mit Mobiltelefonen und so weiter und sofort dann

okay. Also noch mal ganz kurz, erste Option selber machen, allen Codes selber schreiben, hast aber festgestellt ja kann man, also sollen wir mal gemacht haben, man kennt sich dann besser aus, aber dann auch den den Darlehen killen. Darlings und dann zweite Variante. Ich mache es über wenn ich wenn ich wenn ich rein im Web unterwegs bin und wirklich schnell sein will, mache ich es über eine API über einen anderes

SARS Tool letzten Endes auch. Was auch cool sein kann, hat aber seine Einschränkung. Wenn ich on premise gehen möchte und wenn ich vielleicht dann doch noch mehr customizen will oder so gerade noch so diese diese Clients, also Datenbanken et cetera mit authentifizieren lassen möchte, dann gehe ich auf die dritte Option. Ich nehme also ein fertiges, mehr oder weniger fertiges Produkt, was ich noch customizen kann, was ich aber als so als Container in meine ganze

Applikation mit rein bauen kann. Richtig. Und ich saß auch immer ganz klar. Also erstens, dass du es halt mit One Premise nimmst und zweitens wenn du also wir haben sind ja im Io t Business unterwegs. Ja also für alle, für alle Startups oder für alle Leute die jetzt hier Plattformen denken und so weiter die auch mit Io t und den Dingen zu tun haben, da habe ich auch Nummer 3 empfehlen, weil du dann halt

noch eine Sorte mehr User hast. Diese ganze Connectivity zu den ganzen Io t Geräten dieses ganze Fleet Management und Gedöns also das das wird komplex wenn du das voll auslagerst in den Service und es wird wahrscheinlich auch ziemlich teuer man muss. Nämlich auch mal sagen, dass die einfach, die nehmen es auch gerne von den lebendigen, vor allem wenn du komplexe. Komplexe Anforderungen hast, dann ist User Management mit mit Hierarchien und Rollen und so weiter und sofort ja.

Alles klar, OK, cool, dann haben wir die Möglichkeiten verstanden, dann wolltest du wahrscheinlich über die Komponenten sprechen, die zu so einem. Dazu gehören, ich versuche es wie immer, so ein bisschen von wir, wir kommen von der höchsten flugl Ebene und kommen ein bisschen tiefer. Jetzt haben wir quasi uns vorgearbeitet und sich jetzt eigentlich auch wurscht, wie wir es gemacht haben, aber ich habe erkannt, muss ich auch sagen, ich habe es ja selber implementiert.

Habe eine neue Erkenntnis gewonnen, auch durch die Art und

Weise, wie aufgeräumt Fusion ist und wie die denke ist und auch der Rest der Erfolge ist so ein bisschen angelehnt an deren technische Architektur, wie man sowas zu verstehen hat. Ich finde die ist aber allgemeingültig und einfach und richtig würde in Zukunft immer nur noch user Management so denken wollen und das wollte ich teilen hier und es gibt nämlich logische Komponenten wenn ich jetzt über das User Management

nachdenke und. Die allerwichtigste Komponente ist der sogenannte Tenant der Tendenz. Das ist, das ist ein besonderes Wort, was immer vorkommt, vor allem, wenn wir mit dem User Management sprechen, heißt es immer tennent anders. Leute würden sagen, Account ja, Intendant ist meistens ne Firma oder Irgendsowas ja dein Kunde ja irgendwie was weiß ich Siemens oder oder ich mir fällt immer Siemens an, ich weiß gar nicht warum.

Es gibt so viele andere Firmen ja Bäckerei backt das Brötchen irgendwas ja das ist ein Tenant ja und als SARS Provider sage ich mal hast du ja verschiedene Kunden das sind alles deine tendencer und was jetzt wichtig ist innerhalb eines also die Tendenz müssen halt alle isoliert voneinander.

Verhandelt werden, was das User Management ausgeht, denn dass ihr jetzt sag ich mal was, wenn du nämlich wenn du den Account oder den Tenant als Firma Wahrnimmst, dann hast du ja im Notfallgerät mehrere Leute die in dieser Firma sind. Die User sind ja nicht, also das ist wichtig.

Es gibt nicht den User, der der Tenant ist, der Tennant identifiziert die Bäckerei und und die User sind die Leute, die in der Bäckerei arbeiten und davon gibt es ein oder viele, ja, und die können zum Beispiel einer davon oder mehrere gleichzeitig oder sowas, sind vielleicht Kunden in Deinem in deiner Anwendung, ja weil du irgendwie eine Bäckerei geschrieben hast oder irgendwas. So, und die wechseln sich ja

auch. Das heißt aber, was ich sagen will ist, dass und wenn der nächste Kunde halt dein dein Handwerkerbetrieb ist, ja dann haben die halt genau nichts mit dem mit der Bäckerei zu tun. Ja und da soll sich nichts mischen, das heißt, die Tendenz sind die Oberste. Hierarchiestufe und Gliederungsebene ja, deshalb.

Deswegen denkt man intenance ja, also jeder Kunde ist in Tenant und da drunter, es kommt jetzt, was ich jetzt sage, Dadrunter haben wir dann als nächstes Mal ganz wichtig die Applications. Also die Anwendung im ganz einfachen Fall hast du genau eine Anwendung. Ja was weiß ich. Die smarte, die smarte Brötchen Ofenstoppuhr im Internet oder was ja keine Ahnung ist, halt eine Anwendung. Aber wenn wir, wenn wir im Saal im Business denken, haben wir

vielleicht auch mehrere. Anwendungen, dass wir vielleicht noch eine Sache zum Tennis sagen. Ich glaube, das deutsche Wort dafür ist letzten Endes Mandant, Mandant, ja genau, wir haben hier tatsächlich einfach Mandanten, und wenn du das so aufteilt, bist du dann auch wieder mandantenfähig und kannst teilen trennen zwischen Mandanten. Was mir bald wichtig war, ist, dass der Mandant halt keine Person ist.

Mandant ist halt eine Firma oder ein Kunde oder irgend sowas, aber keine kein human being sage ich mal. Das ist dann später der User. Naja gut, aber wenn du jetzt ein Softwareprodukt hättest, was nur für Einzelpersonen da ist, dann würdest. Du die Internet weglassen, dann hast du den Default tenant und würdest auf die Users gehen.

Das ist ganz wichtig. Ja das darf man nicht verwechseln, deswegen mache ich diesen Punkt der Tendenz ist nie ein eine Nase, der hat keine Nase, das ist irgendwie eine Institution Institution. Irgendsowas ja, und wenn du, wenn du nicht mal die Talentfähig bist, weil du das nicht brauchst, ja dann hast du, dann nennst du den irgendwie so wie deine Firma, dann bist du halt, der kommt dann nicht vor.

Ja dann managst du halt da drin die Applications und die Users da drinne managst du da drinne, da haben wir nämlich die Users und das sind die normalen Users wie du und ich ja und die Clients auch, die heißen alle User, also die ganzen alles was irgendwie eine Authentifizierung und eine Autorisierung braucht ist ein User und dann haben wir die Applications. Eine oder mehrere, je nachdem wie komplex ein System ist.

Wir haben zum Beispiel, wir haben es ganz besonders komplex, weil wir ja quasi ein Produkt haben, wo wir Anwendungen bauen, das heißt, da entstehen sogar auch dynamisch welche dazu, und dann haben wir quasi den App Manager, der ist neu, wo man das quasi verwalten kann, das ist mal die erste App, die es da gibt, so, also je nachdem was du halt so hast, kannst du halt mehrere Anwendungen haben, so, und das ist jetzt auch wichtig zu verstehen, und das ist so schön, man muss das trennen, es

gibt die Anwendung, und die sind für sich und die Anwendung die Applications. In denen definierst du quasi schon rollen. Ne, was später die Users da machen dürfen und die Users, die sind auch für sich. Ja die legst du erstmal an, aber die haben erstmal beide miteinander nichts zu tun, das sind 2 einzelne stapel Anwendungen und User. Ja und wenn du und das ist wichtig, das hat Fusion auch gut gelöst.

Und wenn du jetzt sagen willst dieser User hat irgendwas in der Anwendung zu tun, dann registrierst du ihn für eine Anwendung und das nennt sich Registration das ist die nächste Komponente. Registration assoziiert einen User in einer Anwendung oder in mehrere oder umgekehrt. Da kannst du also End zu n machen.

Das Wichtige ist, dass du nämlich aber innerhalb des Tennens, in dem wir jetzt sind, sind die User und die Anwendung unique, davon gibt es nicht 2 gleiche also den Gerrit Meyer gibt es unter dem tenet Bäckerei genau ein einziges Mal. Aber das könnte so sein, dass du 2 Jobs hast. Gerrit, du bist bei der morgens frühs von 4 bis 6 backst du Brötchen in der Bäckerei, dann bist du User im Tenant Bäckerei und danach gehst du zum Handwerksbetrieb rüber und

schleifst da irgendwie ein. Rohre glatt, irgendwie. Ja, dann bist du, dann kommst du dann noch mal vor und sogar mit dem gleichen, eventuell mit dem gleichen Username, was du wahrscheinlich nicht hast, weil du dann deinen Firmennamen ne andere E-Mail ist so, aber dann bist du separiert so ja. Aber innerhalb des gleichen Tennens, wenn da mehrere Anwendungen sind, bleibst du der gleiche User und wirst quasi über die Registration quasi nur zugeordneter.

So und der letzte Punkt hab ich auch schon kurz angewählt, die Rouls ja das ist das, das ist das Wichtigste, das eine ist ja Authentifizierung, also festzustellen ist, dass derjenige, mit dem ich spreche ist wirklich das Gerrit, das machst du indem du User namens Passwort am Anfang gibst und das zweite ist. Welche Rechte hast du denn dann wenn du da bist in der App und die Rollen das ist auch wichtig, die muss man pro Applikation denken.

Also jede Anwendung, jede Application hinterlegt die möglichst verfügbaren Rollen, die gesamte Dimension aller Rollen. Was gibt es da drin und in der Registrierung? Wenn ich dich registriere auf diese Anwendung, dann bekommst du einen Untersatz dieser Rollen oder alle, je nachdem Admin Viewer was weiß ich Editor und so weiter und sofort die Registrierung speichert, also quasi die erstens mal die Zugehörigkeit zur Anwendung und

zweitens deine Rolle innerhalb. Der Applikation, das sind jetzt 12345. So tenant application User Registration und Rolls 5 Komponenten relativ einfach und wenn du die im Kopf hast und einmal verstanden hast, da gibt es n cooles Bild. Auch das kann ich euch leider nicht zeigen, aber über Text sprechen hier, dann hast du, dann kommst du klar, da kriegst du die komplexesten Probleme gelöst. Wenn du das ineinander gut steckst. Das war eine krasse Erkenntnis

für mich. Jetzt gibt es vielleicht die Leute die sagen ja was ist mit dem Permissions, also dem Rechten. Kann man erstmal weglassen. Du kannst auch rollen. Kannst du ja sehr granular aufbauen und dann bildest du letzten Endes permissions ab durch eine Rolle, die ganz spezifisch ist, weil ein User kann ja auch mehrere Rollen haben denke ich mal dann pro. App das ist so genau du hast. Das ist immer so.

Ja, das ist das ist das im Rabak Role Based System ist es so, dass du mehrere Rollen gleichzeitig haben kannst? Genau, und damit also die permissions kann man. Die einfach weggelassen so und ich merke du kommst da völlig gut klar mit Rollen, weil es ist nämlich auch ich, mein Kopf und auch der von vielen anderen Entwicklern ist halt komplett

geflogen. Mit so vielen Begriffen und so viel Zeus. Es wird Überengeniert und aufgeblasen im Netz und du kommst überhaupt nicht mehr auf den grünen Grund alleine von deiner logischen denke her. Und wenn man jetzt und und Fusion aus da steht so schön in einem so einem in einem Artikel so Pass auf wir machen Back to the roots. Reset ja resette dein Kopf. Alles was du weißt hier diese 5 Komponenten gibt es mit denen denkst du. Ist cool.

Es dauert n Moment und wenn man es aber erstmal hat, dann kommt man sehr sehr sehr weit kann ich sagen, weil wir sind nämlich fertig und ruhig, es funktioniert aber. Bestimmt gibt es auch noch andere tolle Tools da draußen. Ja klar, ich, ich sag das ja nur, weil ich, also ich will jetzt auch genau ich, ich fand, ich find es halt schön, weil die Leute. Sich ein paar Gedanken gemacht haben, es auch ordentlich aufzuschreiben, so ist klar.

Es gibt viele andere Tools und die haben wahrscheinlich auch mal irgendwo geguckt und waren vielleicht auch nicht die initialen Autoren, ich will es nur mal, wollte ich nur mal so sagen. Okay cool du das waren die Komponenten auch zu dem Thema. Dann kommt jetzt das Thema, was du vorhin auch schon mal angerissen hast. Also es gibt diese ganzen Flows und Prozesse, also also insbesondere dann auch in der in der Interaktion mit den eigentlichen Usern, angefangen mit dem mit dem Signup.

Also was man natürlich heutzutage kennt ist, wenn man auf modernes Webtool geht und ins ask Tool, dann nehme ich eigentlich nur noch Sinner mit Google. Ich kann mich aber natürlich auch klassisch mit E-Mail Adresse und. Also weil ich natürlich Kugel benutze, privat wie auch in der Firma so. Hat natürlich nicht jeder das Glück, aber welche gibt es noch und was gibt es dazu zu wissen? Ja, ich wollte technisch nur mal

genau. Ich wollte eigentlich nur mal durchgehen, was was müssen wir alles bedenken, wenn wir user Management machen, was gibt es alles für Prozesse und für Flows, also den ersten den man kennt hast du schon gesagt Signup das heißt wenn ich ganz neu irgendwo in eine Anwendung reinkomme und es gab mich noch nie, die Anwendung kennt mich noch nicht, dann muss ich ein Signup machen, so viel wie eine Registrierung, eine initiale Registrierung, das mache ich

auch nur genau ein einziges Mal. Warum ist das anders als einen

Login? Weil ich muss ja dem der Anwendung mitgeben, wer ich bin, genau, also nicht nur Username und Passwort, sondern ich will vielleicht noch den First Name und den last Name zu deutschen Vornamen und Nachnamen wissen, manchmal muss ich da auch schon einen Account angeben, je nachdem wie das System gestrickt ist oder noch XY Informationen, das ist sehr unterschiedlich, andere brauchen irgendwie ganz dringend Telefonnummer von dir oder was weiß ich so ja.

Genau. Und dann wirst du quasi, dann wirst du quasi initial angelegt und auch das ist auch deswegen noch unterschiedlich dieser Registrierungsprozess, weil bei vielen SARS Anwendungen müssen dann initial Ressourcen für dich angelegt werden, vielleicht irgendwelche Docker Container hochgefahren werden, Datenbanken vorher logiert werden oder irgendwie was, ja weil nach der Registrierung bist du ja quasi in so einer Art, ja hast du so eine Art Finanz workspace oder

wie auch immer, aber du bist natürlich irgendwie ein in dem System drin und willst damit arbeiten, das heißt sie brauchen irgendwie. Gewisse Art von Speicher, Cloud oder irgendwas für dich, ja. Jetzt lass noch mal bleiben bei dem Beispiel, was du jetzt gesagt hast. Also ne wie bei uns ne Applikation wo es Tendenz gibt. Ja grundsätzlich und also Mandanten und das heißt wenn ich jetzt als Erster. Oder wenn ich mich jetzt da anmelde, ja und parallel den Tenant erstelle.

Also wird User und Kennet erstellt, richtig, dann ist das so, dass da Ressourcen hochkommen et cetera, oder? Du sagst es also das hab ich jetzt, das hast du noch besser formuliert als ich hab es gerade vergessen. Genau wenn du mich als erstes, du bist ja quasi ne Nase, also nicht human User, aber du legst quasi in dem Registrierprozess gleichzeitig den Tenant an für. Dich, ob jetzt bewusst oder

unbewusst wie der. Bäckereimitarbeiter und wirst du da unbewusst so aber den quasi wenn es die Bäckerei noch nicht gab, in der du arbeitest. Und du dich jetzt aber als Mitarbeiter als Nase der Bäckerei anmeldest, dann wirst du quasi Ersteller dieser dieses Tendenz Bäckerei am Anfang.

Genau das ist der Punkt, ja und das ist und und und das unterscheidet quasi die Registrierung wie wie man und im Englischen heißt es mal signup ich finde es immer sehr verwirrend und das andere heißt sign in Sign als ich glaube, als deutscher Staatsbürger ist man immer verwirrt, was jetzt was ist. Also ich war es jedenfalls länglich. Ja, ich finde auch sign und Login besser als Unterscheidung tatsächlich. Manche nennen es auch Registration und Login.

Dann wird es noch klarer. Ja, genau, ja ist Geschmackssache. Ich hab mich jetzt dran gewöhnt, dass signeup halt quasi hat. Die initiale Registrierung ist und genau und der Unterschied danach zum Login oder Sign in ja ist dann es gibt den ja und es gibt die Nasen und ich war schon mal im System, ich bin irgendwie nur rausgeflogen weil ich lange

nicht mehr drinne bin. Ja und jetzt muss ich mich quasi einloggen, authentifizieren, das ist der Authentifizierungsprozess. Und melde mich beim System an.

Und was dann passiert ist auch ich muss quasi das System muss dann quasi auflösen okay da hat sich Gerrit Mayer angemeldet und der hat jetzt sich in dieser Applikation angemeldet und da drin hat er folgende Rollen und das weiß das System sofort nach der Anmeldung. Ja deswegen das ist wichtig ja also wenn du dieses dieses Formen, ob das jetzt mit ob du klickst mit Google oder Usernamen und Passwort ist Wurst danach weiß das System schon ganz genau welche Rollen du hast

im nächsten Moment, weil jetzt ist es wichtig, jetzt geht die Webseite quasi auf. Soll ja schon quasi gefiltert sein zu dem was du siehst oder nicht? Ja, je nachdem was du für ne Rolle hast. Ja bist du Admin, siehst du für sie irgendwie alles, bist du irgendwie was weiß ich Operator oder sowas kannst du halt bestimmte Sachen nicht sehen, ganz klassisch.

Ja, musst du auch. Wahrscheinlich gleich alles da sein, weil wir ja über Single Page Applications reden, ne, dass dann alles für mich mit meinen Rechten entsprechend vorbereitet. Ist ganz genau, ganz genau. Das ist dann quasi die Logik, die steht dann im Frontend, das muss man also, wenn man Single Page Application hat, da muss man quasi im Frontend wissen. Diese Rolle, ja, und dann kann man quasi Sachen ein oder ausblenden.

Gemanaged wird das alles übers Backend, also sage ich gleich, aber noch, was kann man am nächsten Punkt? Ich wollte jetzt einmal kurz die Flows gehen, also wir hatten jetzt Registrierung, Login, dann haben wir typischerweise vergisst man immer wenn man es wenn man es selber implementiert, dann denkt man so OK Registrierung Login fertig ja. Ach nee, der hat ja dein

Passwort vergessen. Ja, das muss ja auch noch irgendwie vor Gott, Passwort, Flow ja ganz klassisch, ja, und das ist gar nicht so einfach, weil da musste irgendwie ne Mail schicken, da brauchst ne Verification ID, technisch ist das auch schon wieder ein bisschen aufwendig so ja so und dann haben wir noch was wenn wir einen Sign haben, dann haben wir immer eine App die eigentlich publicly available ist, wo ich quasi nicht sage, also dann darf ja jeder jede Bäckerei, jeder

jeder Hansel und pamsel kann halt einen Account erstellen.

Wenn er dann noch nicht weg ist. Das kann ich vielleicht nicht wollen, weil ich nur sage, NÖ, die App ist nur für ganz bestimmte Leute, die ich vorausgewählt habe und dann komme ich zu einem dritten Flow. Das ist typisch Invite Flow, das heißt, den kann man abbilden über verschiedene Dinge, aber ganz typisch ist, ich kenne halt eine E-Mail, ich nehme jetzt nochmal den Garrett, weil er hier gerade bei mir gegen gegenüber sitzt, hätte ich beinahe gesagt, wir sind aber

Remote weiter, aber der Gerrit, Ich kann jetzt sagen, nur der Gerrit darf jetzt hier in meiner App, dann schicke ich dem Gerrit Halt so eine Art invitation E-Mail, dass er gerne sich ein. Einloggen dürfte. Ich erstelle quasi schon den den Garrett, ich mach quasi den Tennen schon fertig und registriere ihn vor. Aber die Komplexität hier ist, ich kann ihn mir noch nicht vorgeben, was dein Passwort sein wird, ja oder ob er sich mit Google danach einloggt.

Ja, das kann nicht so trivial. Ja, ich sag Ihnen nur Pia, komm mach das fertig, ja und dann sucht sich der Gerrit später noch n Passwort aus oder loggt sich per Google ein und dann ist er im System ne. Aber aber jemand anders kann halt nicht einfach ins System rein, weil er erst ne invitation. Also in meinem Kopf ist da einfach schon ne Datenbankeintrag dann vorhanden halt mit einem mit einer User ID.

Letzten Endes also meine E-Mail-Adresse zum Beispiel und ich fülle dann nachher das Datenbankfeld. Passwort noch ja auf den auf der richtigen Art und Weise. Eben richtig. So ist es, sogenannte ne so tatsächlich so trivial. Und dann und jetzt, ich sag es noch mal ne kurze zum echten Leben und so funktioniert schon wieder nicht. Wenn du dann nach dem Google Login machst weil. Das kennen wir vielleicht auch.

Es gibt ja Leute, die haben mehrere Google Logins, ja mehrere Konten, konten ja Content bei bei Google so und ich lade dich jetzt ein auf garrett.garrett@heißenwehr.com was dein Google Account ist. Du gehst auf den Link, drückst auf Login mit Google, nimmst aber deinen privaten Google Login. Ne, schon ist mein Datenbankeintrag finden für die Katze gewesen. Ja und auf einmal kommst du mit einer anderen E-Mail rein als also davon muss ich mich auch schützen, ne also.

Der Teufel ist im Detail User Management ist wirklich nichts was was man eben mal gerade so schnell absteckt. So, das muss man alles checken, prüfen und man ist froh wenn es, wenn es wirklich ne gute Bibliothek gibt, die einem da n bisschen hilft. OK, dann haben wir es. Ich würd sagen, das sind die wichtigsten Flows.

Nee, es gibt noch einen so n One Time Access, das hat man ganz oft, wenn man jemanden irgendwie so n Download Download anbietet ja wo man sagt so hier hier auf unserer Plattform gibt es irgendwas geschütztes im geschützten Bereich kannst du Grad runterladen ne und das ist vielleicht sogar jemand ganz extern oder irgendsowas kann man ja manchmal kennt man das so von Microsoft 365 oder irgendsowas ich share halt irgendwie so ein Dokumenten oder Irgendsowas ja das kann ich ja nicht einfach

offen sharen, dann braucht jemand und ich will auch nicht deswegen nur weil der einmal was runterlädt den jetzt als User unter dem Nintendo anlegen und und und da brauchst du ne Art Runtime. Besser, und das gibt, das gibt es halt auch, dann kann ich halt so One Time, Magiclinks und so weiter wie das heißt irgendwie erstellen und dann darf man sich da einmal was runterladen, dann muss es auch mit getrackt werden und so weiter ja das sind so typische Flows.

Ja, also sign in Signal, Forget, Passwort invite und so Runtime Dinger jetzt. Habe ich noch eine Frage, die mir da jetzt gerade ein Film ist. Ich kann ja zum Beispiel auch bei uns im Google Drive oder ich könnte es wahrscheinlich auch in Dropbox oder Microsoft. Onedrive kann ich ja einzelne Dateien wie auch Ordner also

freigeben. Ich habe ja die Möglichkeit da auf auf auf Dateiebene eine Freigabe zu machen und entweder an den bestehenden User aus meinem Tennant auszuwählen, indem ich das jetzt speziell nochmal freigebe oder eben nicht auch wieder mit Rollen oder ich kann auch sagen, also shared oder public. Also. So. Und dann der Public auch wieder zuordnen. Ist das jetzt bearbeitungszugriff Kommentarzugriff oder?

Nur Ansicht, also Ansichtskommentar oder Bearbeitung. Was passiert da Speicher ich dann mit mit der Datei oder mit dem Ordner Rechte oder ist es gibt es dann sowas wie ein Public User der dann wieder rollen hat? Kann dir nicht genau sagen, wie Google das gemacht hat, aber du also allein, dass du philosophierst drüber siehst du schon, wie komplex das ist. Und man kann manche Sachen auch auf verschiedene Sachen angehen.

Ne. Also man kann ne Ressourcenrolle geben oder dann user und so weiter das man muss sich das, man muss sich da jeden Flow. In diesen und deswegen hatte ich jetzt am Anfang gesagt, in diesen Komponenten, die ich arbeiten und application User Registration und Rules muss man sich hinlegen. Ja und vielleicht mal auf dem Blatt Papier sogar aufzeichnen. Ja und dann sich überlegen was

macht das Sinn ne? Also das ist ich und also, und um das noch mal zu sagen, was da Google macht und so weiter das ist halt wirklich komplexe Materie.

Ja und es ist auch sehr tatsächlich, wenn man jetzt Microsoft, ich weiß das gerade weil ich, ich bin halt tief im Thema drin, weil ich es gerade mache seit 3 Monaten, wenn man sich zum Beispiel anguckt, wie Microsoft intern ihre Authentifizierung macht und Google könnte meinen, da gibt es ein Standardrezept, ist aber auch nicht so auch komplett unterschiedlich. Also auch architektonisch.

Da gibt es schon. Es gibt mehrere Wege, die nach Rom führen, ne und auch manchmal nicht ganz klar welcher der Beste ist. Oder es bleibt ein komplexes Thema. Ja, umso spannender, dass du einfach jetzt auch diese Erfahrung berichtest. Da muss man auch sagen, es gibt ja auch hier wieder andere Wege und und. Auf jeden Fall soll auch jeder so machen, wie es soll. Ich also unser Podcast ist sowieso nur, man kann ja abschalten, wenn es einem nicht passt. Also wir sind durch die Flows

durch. Wir gehen noch ein bisschen technischer runter, ich wollte eine Sache noch mal sagen für dieses Google Login, das ist ein bisschen magisch, oder Microsoft Login. Das wollte ich.

Einmal kurz sagen, Apple gibt es auch jetzt hier bei der Aufnahmeplattform geht es mit Spotify. Es bieten viele an. Ja, genau, genau, genau das ist so. Man nennt das im Fach Chinesisch Itp Login über Idp über Identity Provider.

Und es ist tatsächlich, also ich muss sagen, es ist unglaublich cool, weil die User experience, ich, ich mag überhaupt nicht mehr, also es ist ja furchtbar, dass man überhaupt diese ganzen Passwörter hat und und dann muss n passworttresor haben und ständig sich das merken, ja und wie einfach ist das Leben, wenn ich einfach überall mein Google Login nehmen kann? Ich bevorzuge das schwer, ich glaube.

Dass in Zukunft das noch viel stärker kommt und man sieht es an den Saaten, du hast das sehr gerettet, jeder, jeder bietet das quasi schon an. Es gibt ja auch Bestrebungen glaub ich vom vom Bund, also zum Beispiel in Deutschland irgendwie nen so ne Art Identity Provider Service auch auch auch zu bauen und zu machen. Da gibt es ja alles mögliche, aber auch da wahrscheinlich setzen sich am Ende einfach die Big Text da durch, aber die. Eh schon.

Die Accounts haben von also die Apples und Googles und so. Und tatsächlich ist das aber noch, ich muss sagen das, das

kriegst du nicht geschenkt. Also Login mit Google und so weiter das ist und vor allen Dingen nicht in SPAS Single Page Applications. Und auch da können, also das ist vorbereitet in jetzt, ich sag es nur mal kurz bei Fusion aus und auch bei Austhero und so weiter also alle alle Dienstleister in der Authentifizierungsbranche, die bereiten dir das schon vor, ja. Und die können das nur bis zum

gewissen Maße vorbereiten. Zwar aus sicherheitstechnischen Gründen ja, und den Rest musst du selber machen und das, was wir selber machen müssen, das will ich jetzt einmal kurz sagen, das weiß man nämlich typischerweise nicht, also ich wusste es jedenfalls auch nicht so ganz genau, das hat nämlich mit O aus 2 zu tun und so weiter da wo hat man ne Folge, das will ich gar nicht ansprechen, aber was?

Was du außerhalb deiner ganzen Software, Architektur und dieses Einbindens von deinen, von was auch immer du da nimmst, von einem Authentifizierungsdienstleister oder sowas noch machen musst, ist. Wenn du jetzt als Firma selbst, ich sprech mal von uns, als heißen du eher nen Google Login zum Beispiel anbieten möchtest. Dann musst du selber erst mal nen Account haben bei Google. Google Cloud Account das ist Voraussetzung, warum?

Weil du musst nämlich sowas, das heißt sogenannten O aus Client, den musst du anlegen, ja, und zwar und im Notfall ist das sogar richtig krass, den musst du, wenn du, wenn du damit noch mehr Sachen machen willst, quasi von Google aus, dann muss das auch verifiziert werden von Google usw das heißt? Der Softwareentwickler, der das machen will, der muss zu Google Cloud gehen und da die richtigen Knöpfe drücken und nen so ne Art an so ne Art O aus Client anlegen.

Ja mit und auch da die ganzen Sachen hinterlegen Privacy Policy dann ihr kennt das so n bisschen wenn ihr mit Login mit Google mal. Besten Falle kommt dann so ne. Kommt dann so ne nächstes Pop up?

Das ist dann schon von Google das ist der Punkt, man macht das ja nicht mehr bei sich, sondern wir und das haben wir in der Folge langwierig Auseinandergelegt in der O. Aus 2 Folge könnt ihr euch doch irgendwo anhören, aber man ist quasi auf dem Server von Google. Aber im coolsten Falle will ich da trotzdem mein Logo anzeigen. Ja, weil was mach ich denn

jetzt? Ich möchte mich einloggen bei Heisenware, also will ich da heißen wer Logo sehen und dann steht da irgendwie hier willkommen sie loggt sich jetzt einfach, heißen wir übrigens hier sind die Privies, die Terms und die die Data Policy Terms und so weiter die musst du auch lesen, das ist rechtlich verbindlich und so weiter das muss halt richtig hinterlinkt sein und dann muss das auf einen Link zeigen der auf heisenwehr.com zeigt und nicht

bei Google irgendwo und so weiter und sofort jetzt kann man sich schon vorstellen, das kann ja nicht irgendwie magisch passieren, das heißt ich muss das tatsächlich bei Google hin konfigurieren und machen und so weiter und da gibt es. Secret Tokens und so weiter und und leider ist es so, dass das Halt bei jedem unterschiedlich ist. Bei Google geht es halt so und bei Microsoft halt anders.

Ja und wenn ich jetzt n Microsoft Login haben will, die wenn ich den erstmal hab wenn ich da das mache ich über die Azure das Azure Portal. Dann hab ich gleich ganz viele Abgefrühstückt, weil nun die Halbe die halbe Welt gehört.

Ja, Microsoft, also ich weiß nicht, was da alles zugehört, dann hab ich die gleich mit drin, ne da krieg ich dann so, aber das muss ich jetzt auch erstmal machen, dann muss ich mich also erstmal n Azure mit Azure beschaffen und n Portal da aufziehen und meine Firma da registrieren und und und und und und ja. Also das mal. Also wenn man das wenn ihr plant das zu tun, bisschen Zeit einplanen, weil das ist tatsächlich nicht ganz trivial.

Ich könnte mir fast vorstellen, dass es auch schon wieder SARS Provider gibt oder Dienstleister, die das wieder alles bündeln. Diese ganzen Social Finance und Signups. Hab ich noch nicht gesehen, weil das ist. Also ja, wär vielleicht ne Marktlücke, aber ich hab es noch nicht gesehen.

Das ist weil weil das halt echt du musst auch verifiziert werden dann von Google. Also wir haben jetzt auch so, bei uns läuft dann so n Verification Ding die gucken ist bist du dann bist du gibt es die Firma Adresse und so. Weiter und sofort scheint, ja, könnte, scheint ja, als könnte man das einfacher machen und benutzen alle. Also ich wette da gibt es was aber. Ich bin ja auch ein bisschen blöde und habe das irgendwie genau. Vielleicht gibt es ein Tool.

Glaube ich nicht. Aber es gibt bestimmt Sachen, die es dir Bündel, aber er hat wieder dann andere wie immer hat dann wieder andere Nachteile, hast extra kosten was auch immer, musst halt abwägen. Musst abwägen. Genau, also, es geht. Was dann passiert, ist auch

total elegant. Es gibt es gibt dann quasi, also wenn ich jetzt die es gibt in den Nutzerdatenbank und wenn ich ein User über über E-Mail und Passwort habe, dann lebt er in meiner Datenbank und wenn ich das nicht hab über Google oder Microsoft oder wie auch immer, ja dann lebt quasi von dem nur so eine Art Id und tatsächlich die ganze Passwortverwaltung ist Outgesourct zu Google, das heißt du kannst ja auch dein Google Passwort ändern, das interessiert mich gar nicht wenn

du Über Google bei mir eingeteilt ist. Also hat das deine Vorteile. Gut so, jetzt einmal noch verstanden, verstehen wir noch einmal kurz, was wir für technische Komponenten brauchen, wenn wir sowas umsetzen und das ist ganz klar, wir brauchen eine Datenbank, wir brauchen immer irgendwie eine Datenbank, im besten Fall eine relationale ich nehme gerne Post Respekt wo halt irgendwie die ganzen Nutzer Dinger drin stehen, ob das JETZT id PS oder nicht muss das

irgendwie verwalten. Dann brauchen wir, das ist wichtig, einen ein logisches Backend. Also selbst wenn du nen Dienstleister hast und hast da irgendwie APIS und so weiter wir müssen dran denken, wenn wir in einem Frontend sind in einem SPA, dann läuft der der Code in dem Browser des Klienten, das heißt? Ich darf aber nicht auch ein einziges Token haben, was total sicherheitsrelevant ist. Ja, weil das ist alles potentiell hackbar, ja. Das darf nicht im Frontend sein.

Man. Darf nicht im Frontend sein, genau ich, ich muss halt alles was der der der der wirkliche

Zugriff auf die Datenbank ja um die Einträge zu machen, Passwort gewechselt und so weiter und sofort, das muss alles über einen Backend gekapselt werden, das klingt mega aufwendig, man denkt so Scheiße wieso? Ich hab doch jetzt hier zum Beispiel auch Fusion aus hatten API und so weiter ihr könnt ja direkt vom Frontend aufrufen, so könnte man erst denken.

Ich warne alle davor, das überhaupt erst mal zu versuchen, weil dann brauche ich ja den, wenn ich was vom Frontend aufrufen will, eine API, dann brauche ich da ja auch ein Token Führer, sonst kommen ja nicht Abi nicht ran und wenn ich das vom Frontend direkt ausmachen will, dann heißt das Token irgendwo im Frontend. Also ihr müsst es Kapseln über es muss quasi ein logisches Backend geben, was das was das Kapselt und da drin noch mal die Datenbank abrufen macht.

Im Frontend gibt es gefälligst nichts.

Dann habe ich noch weitere Komponenten, dann muss ich, wenn ich sowas implantieren muss, muss ich über webforms nachdenken, weil ich also ich brauche auf jeden Fall ein paar Fans für zum einen geben von wenn da nur ein Google Knopf drauf ist und so weiter und zum Passieren Passwort changen und so weiter das kann ich mir überlegen ob ich die also wenn ich das integriert habe dann kann ich diese forms selber machen hoch customized so wie ich es Bock habe so machen wir

zum Beispiel zum Beispiel oder aber ganz viele Lösungen wie gesagt bieten vorgefertigte Komponenten an auch für Rect und so weiter nehme ich halt die und kann die Halt modifizieren, modifizieren, modifizieren per Logo oder wie auch immer, lass die so aussehen wie es passt. Kann ich mir überlegen und dann

ganz wichtig. Bei diesem ganzen Authentication Krams E-Mails heute noch das die Standard Kommunikation für die ganzen Invites forgot Passwort, Flows und und und und ich brauch halt E-Mail und E-Mail verification weil die E-Mail ist mein Nutzername Punkt. Ja E-Mail ist also für für normale Leute ist die E-Mail der Nutzername würde ich auch gar nichts anderes machen. Und dann brauche ich halt eine Art und Weise, das kann ich auch hinterlegen.

Ich brauche halt einen E-Mail smtp Server, der in der Lage ist. Sehr, wie soll ich sagen, immer Funktionierend quasi E-Mails rauszuschicken, so ja essentiell sonst. Was hat die User abgehängt?

Ja und jetzt nehme ich kurz noch auf und dann habe ich so von meinem Specialist eigentlich alles runter gebetet, wir haben ja was wichtig ist ist wir wollen ja die Nutzer auch nicht nerven mit ihrer Eingabe vom Usernamen und Passwort, außerdem ist das ein kritischer Prozess wenn ich ein Passwort eintippe, das will ich so wenig wie möglich machen, ich will eigentlich mit dem Passwort nicht. Arbeiten, weil das ist ein kritischer Prozess, weil potenziell immer. Sind gelauscht werden könnte

oder sowas oder? Ja, einfach bald? Nee, einfach weil der, weil das Datum, was ich eingebe, nämlich das Passwort, das Kritischste ist ja was du hast, ja. Und weil Leute, wir, weil wir wissen, dass viele Nutzer ihr Passwort vielleicht an mehreren Stellen das Gleiche benutzen und

so weiter und sofort ja. Ist einfach n Kritisches einfach einfach nen sensitives Stück Information. Ja was du so wenig wie möglich anfasst, Punkt ja. Einfach am Sicherheitssprech so. Ja je weniger du das eintippen musst und damit verhandeln musst, desto sicherer. Ja, so und deswegen gibt es Tokens, ja, und das will ich einfach noch mal sagen, weil das war für mich auch noch ne Erkenntnis, welche Tokens gibt es eigentlich in der modernen,

in der modernen Welt, ja? Also wenn du einmal dein dein klar initial musst du irgendwo mal n Usernamen Passwort eingeben. Ja und dann wird dieses Username Passwort getauscht gegen den Access Token. Access Token, so heißt es ja. Das Access Token ist ein sogenanntes J Double UT TOKEN, EIN JSON Web Token.

Was das ist, könnt ihr euch später angucken, haben wir vielleicht immer ne Folge, ja. Dieses Access Token hat ne kurze Lebensdauer. Kurz heißt zwischen sowas wie 30 Minuten oder 3 Stunden. Das ist typischerweise so dieses Session ja. Dann läuft das ab. Dann wirst du rausgeschmissen und musst dich quasi wieder dein Passwort eintippen. Ist die eine Variante, oder?

Aber, und jetzt gibt es ein zweites Token, das sogenannte Refresh Token, ne das Refresh Token kann man sich vorstellen wie ein anderes Passwort, das ist schon fast auf der Ebene, es passt ist auch kein J Double UT Token das Refresh Drucken ist einfach ein langer generierter String. So, der lebt nicht 30 Minuten und auch nicht 3 Stunden, der hat typischerweise ne Lebenszeit von viel länger irgendwie ne Woche n Monat ein Jahr kann man sich aussuchen, so ja.

So und das Refreshtoken, das darf auch im, das darf sogar auch im Browser gespeichert werden. Ne das das würd ich sagen damit ne also die das Passwort nicht ja das Passwort auch verschlüsselt, das ist wichtig ja das liegt, das kennt keiner, ja außer der Nutzer ja ne Datenbank wird das verschlüsselt abgelegt. Und dann arbeitest du mit dem Access Token für den kurzfristigen Zugriff. Und wenn der alle ist, dann holst du dir mit dem Refresh Token ein neues Access Token.

Klingt irre, ist aber Standard. Und dann muss ich mich zwischendurch, also was, was ist für den Nutzer, muss ich mich nicht wieder, also muss ich nicht wieder mein Passwort und Usern eingeben. Nein, wenn du. Einfach eingeloggt, aber im Hintergrund passieren diese Prozesse. Passieren wilde Dinge? Genau das kriegst du alles nicht mit.

Ja, deswegen sage ich immer Authentication, das sieht einfach, wenn es gut läuft, hast du selber gesagt, Gerrit, dann ist das irgendwie kommt es nicht vor, aber. Im Hintergrund werden Refresh Stokes gegen Access Tokens getauscht und so weiter und sofort. Ja, ich könnte Buch schreiben, Refresh Tokens machen wir aber nicht. Jetzt gibt es ja noch die Möglichkeit, beim Login bei vielen Seiten zu sagen, Remember Me oder Remember Me on this device oder in this Browser.

So, da kann ich dann quasi bestimmen, ob ich mich beim nächsten Mal noch wieder authentifizieren muss oder beziehungsweise authentifizieren muss ich mich immer. Die Frage ist nur wie ob ich wieder mein Passwort. Brauche das Remember me würde ich sagen. Ich weiß nicht wie die Leute das machen, weil es gibt halt wirklich viel Authentication. Gesagt, aber das Remember Me ist genau das benutze ich refreshtalkings oder nicht.

Wenn ich Remember me anmache und dann sage ich, OK, ich mache eigentlich also in der modernen O. Aus 2 Welt, sage ich dann, OK, ich benutze refresh Tokens und dann kann das sein, dass du n Jahr lang eingeloggt bist. Ja, je nachdem wie die Policy von der Firma ist und ich ehrlich gesagt ich bin n Fan davon, weil zum Beispiel wenn wir mobile Apps haben, es ist ja nichts gruseliges.

Du willst jetzt gerade dein Fahrrad ausleihen und du hast es eilig und dann sagt dir die blöde App, jetzt muss ich erstmal dein Passwort eingeben. Ja, das hast du erstens nicht im Kopf, weil das solltest du auch nicht im Kopf haben und dann musst du dein Passwort Manager haben, den musst du erstmal auf dem Telefon haben, dann musst du den sich einloggen, dann will der auch wieder dein Passwort haben und und und. Da sind schon die halbe Stunde rum bis du dich da angemeldet

hast. Ja, deswegen sage ich immer, lass die Leute doch eingeloggt so ja von der UX. Aber es gibt halt mit diesen Refresh Tokens einen sauberen Weg um festzustellen, dass es auch sauber ist. Denn vor allen Dingen man kann. Mittracken das ist wichtig. Das Refresh Tocken ist ja ein bestimmtes Token und das kennt man in der quasi in der hinteren liegenden Welt.

Und wenn jetzt das Refresh Token zweimal benutzt würde oder von einem anderen gleichzeitig, dann kann man schon gleich die Hände hoch sagen und hier ist irgendwas gequietscht, so ist irgendwas komisch. Jetzt muss man vielleicht sagen, musste ich gerade daran denken. Es gibt natürlich Apps und Anwendungen, da will ich das auf keinen Fall, also mein Banking oder mein Broker auf dem Telefon oder auch als Webanwendung, da läuft auch meist ein Countdown runter, dass man.

Ausgeloggt wird. Und wenn ich jetzt sich mehr bewegt oder so. Genau, ja, das muss man dann halt abschätzen, dass man so gegen gegen verschiedene Sachen ne, aber im Prinzip alles was ich heute erzählt hab, auch diese, also diese Access Tokens und die Refresh Tokens und dieses ganze Zusammenspiele, das ist Moderne aus 2 Methodologie und das ist stand der Technik und das ist auch sicher zu dem was man bis heute verstanden hat.

Jetzt gibt es noch einen Token das ich noch erwähnen, das ist nämlich wichtig, da muss man auch einmal kurz drüber nachdenken wie Fresh und Access Tokens sind halt für unsere Humanus. Ich hatte ganz am Anfang gesagt, es gibt ja auch diese kleinen Users, die haben davon nichts, weil die können sich ne, also die loggen sich ja so nicht ein, die haben dann sogenanntes Authentication Token, also die können auch n Passwort haben, aber dann sage ich ich geb es

gibt nen Authentication Token, das ist noch mal anders, ist aber auch ist kein JW Token ist auch einfach nur ein langer String der aber nicht verschlüsselt abgespeichert wird, das ist der Unterschied und die können halt quasi mit so einem Authentication Token in die Systeme rein, das hat auch einen Vorteil bei Authentication Tokens können viel schneller. Also der ganze Validierungsprozess und so weiter ist viel schneller, weil das nicht encrypted ist.

Encryption und so weiter dauert immer Zeit und bei den Klienten will ich Speed haben, hinten drin ne, da arbeite ich mit Authentication Token so. Also es gibt diese 3 Arten von Tokens, typischerweise Access Refresh und Authentication Authentication ist quasi sowas wie ein Passwort. Und damit würde man auch zum Beispiel, es gibt ja bei ganz vielen Web Diensten auch die Möglichkeit, andere Tools zu

integrieren. Also zum Beispiel kann ich bei unserem aus unserem Firmenkonto die Transaktionen in Google Sheets reinschreiben lassen in so eine Tabelle.

Um die, um dann daraus was auch immer zu machen, ja Auswertung oder so. Ja hab ich dann auch so ne Authentication Token. Ne, da hast du Access Tokens, das geht alles über jw. Typischerweise Access Tongue, weil das also das ist der Austausch zwischen Systemen, das ist das Schöne, also man hat sich, man hat n Standard gefunden im O aus 2 und dieses dieses Access Token, dieses JW Token hat einen standardisierten Aufbau und da sind auch das

standardisiert beschrieben, wer bist du, was ist dein Tenant und was sind deine Rollen, das ist da quasi alles lokal abgelegt und normalerweise wird die Verbindung zwischen verschiedenen Systemen über dieses Access Token gemacht, über das JW Token ok, dann kriegst du auch sowas wie Single Sign on hin SSO. Verschiedene Dinge hinweg basieren alle auf diesem JW Token, auf dem Access Token ne. Cool, Booker, danke, dann würde ich sagen, kommen wir zum Ende.

Hast du noch? Was letztes zu sagen. Nö, eigentlich nicht. Man cool ist es, wenn dein System noch anbietet, dass du beliebige private extra Informationen, die du vielleicht die irgendwie was mit Applikationen und Usern haben, noch einfach dazu speichern

kannst. Das gibt es bei Fusion Ows auch, das fand ich richtig cool, weil dann kannst du noch sowas machen wie im SARS, kennen wir das auch, Gerrit Pläne also hier Basic, Enterprise und so weiter und sofort, das willst du ja auch, typischerweise vielleicht zum Beispiel Antennen dran klatschen und so weiter da kann man sich genau überlegen und dann ist es schön, wenn das System flexibel genug ist. Ja, um da ne sehr speziellen Anforderungen auch noch

irgendwie zu hinterlegen. Ja und das kann man da auch und das das bei der Auswahl von so einem System glaub ich sollte man da auch n Auge drauf halten und ansonsten hab ich mir das hab ich mir die Seele vom Leib gesprochen und kurz mal alles raus erzählt. Gefühlt einer wieder bisschen länger geworden als geplant. Ist doch gut. Gute gute Länge, prima, OK, dann machen wir hier n Deckel drauf dank dir für den Einblick ins User Management.

Ich fand es richtig spannend heute viel gelernt, dann bis in 2 Wochen ja macht es gut. Macht es gut. Tschüss aus Hamburg. Einfach komplex wird präsentiert und produziert von Highsow. Wir freuen uns auf deine Fragen und deinfeedbackanpodcast@heiseweb.com vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.