 Hallo und herzlich willkommen und ich würde mal sagen noch guten Morgen kann man glaube ich noch sagen auf einer Hacker Konferenz zum Tag 3 der GPN. Wir haben jetzt hier den Vortrag Ohr auf vor Beginn. Wir haben auch schon eine kleine Umfrage im Publikum gemacht. Sind ein paar Leute dabei die einfach nur hinter die Kulissen schauen wollen. Nicht ganz so viele Systemadministratoren die das am Ende auch konfigurieren müssen. Vielleicht ein kleiner Hinweis für den Stream. Es wird kein Bild vom Vortragenden geben. Dementsprechend nicht wundern, aber der Ton wird hoffentlich gut genug sein und die Slides werden auch gezeigt. Genau, aber without further ado ein hoffentlich tomen Applaus für Psy. Hallo, wie gerade schon gesagt, ich bin Psy und ich möchte euch heute was über Ohr auf Beginn. Schön, dass zu dieser doch relativ frühen Zeit für eine GPN so viele Leute da sind. Falls ihr Fragen während des Vortrags habt, gerne einfach zwischen rein. Ansonsten auch am Ende später noch draußen an der Bar oder Asynchon via E-Mail oder Mastodon. Kleiner Disclaimer vorab. Ich bin kein Ohr auf Experte. Ich habe mich da auch von der Weile einfach mal mit beschäftigt. Und dachte mir, ich erzähle euch mal was ich währenddessen gelernt habe. Und Ohr auf an sich ist kein Hexenwerk, aber wahnsinnig vielfältig. Bietet wahnsinnig viele Konfigurationsmöglichkeiten und kleine Details an. Also schaut beim Implementieren bitte einfach nochmal in die Specs. So, wir hatten vorhin schon die Frage, wer Ohr aufs schon kennt. Das heißt, wahrscheinlich haben alle von euch schon mal so einen Authorization-Screen gesehen. Wenn ihr euch irgendwo einloggt, wenn ihr irgendwo Zugriffe für eine Anwendung geben wollt, wenn ihr zum Beispiel auf dem Telefon eine mobile App benutzt etc. Sieht manchmal auch so aus, also Bloginwith und dann habt ihr einen dieser vielen großen Provider da. Kann auch zum Beispiel ein zentrales Firmen, Single-Sign-On oder ähnliches sein. Aber was ist Ohr auf eigentlich? Das RFC habe ich da mal angeworfen, das ist das Abstract davon. Und eigentlich sind davon primär drei Dinge relevant. Ohr auf ist ein Authorization-Framework. Authorization ist an der Stelle sehr, sehr wichtig, da kommen wir gleich nochmal drauf. Aber insgesamt ist es ein Framework, das euch viele verschiedene Dinge an die Hand gibt, um Zugriff auf Ressourcen oder auch Identifikation von Nutzern zu ermöglichen. Das steht hier eben auch nochmal, wir erlauben einer Third-Party-Applikation limitierten Zugriff auf HTTP Services oder ich ergänze da jetzt an der Stelle mal auch Ressourcen. Entweder im Namen und Auftrag eines Nutzers, das was meistens passiert, oder aber auch für die Anwendung selbst. Wir werden heute auf den vorherigen Fall genauer eingehen, weil für die Anwendung selbst relativ langweilig ist. Wie wir gerade schon gelesen haben, ist es ein Authorization-Framework und kein Authentifizierungs-Framework. Der wichtige Unterschied an der Stelle ist, wer erinnert an uns, Authorisierung ist jemandem Zugriff auf etwas oder eine Ressource zuzugeben und Authentifizierung ist sicherzustellen, dass die Person oder der Dienst, der sich mir da gegenüber gerade als jemand ausgibt, auch wirklich diese Person oder dieser Dienst ist. Das heißt, Ohr auf alleine kann erstmal keine Authentifizierung, ist aber gar kein Problem, gibt da noch mal eine kleine Schicht obendrauf, die nennt sich dann OpenID Connect und mit der wiederum ist es auch möglich, Authentifizierung zu machen. Das heißt, in den meisten Fällen, in denen ihr Ohr auf irgendwo seht oder benutzt, wird es zusammen mit OpenID Connect verwendet, um euch eben zu authentifizieren. Also wenn ihr euch jetzt irgendwie bei einem Hedge-Talk mit einem Singlesign-On-Provider anmeldet zum Beispiel. Die Sicht kennt ihr wahrscheinlich alle, wenn man sich selbst irgendwo authentifizieren möchte, popt dann irgendwo so ein sign-in-with-sso oder sign-in-with zum Beispiel einer der Provider, die ich vorher in der Einführung kurz gezeigt habe, auf ... Man klickt da drauf, wird weitergeleitet zum jeweiligen Dienst, hat dort ein Log-In-Formular, wenn man nicht eh schon eingeloggt ist, muss sich da dann mit username-Password oder anderen credentials einloggen, wenn es irgendwie Multi-Factor-Authentication oder weitere Dinge gibt, die beim Log-In-Enforced werden sollen, werden die dort dienstzeitig enforced. Danach fragt der Dienst euch nochmal, hey, du bist gerade dabei, dich woanders, mit deiner Identität hier einzuloggen. Der Dienst hätte gerne Zugriff auf folgende Dinge, in dem Fall eben OpenID, um sich zu verifizieren, E-Mail-Adresse und Profilinformationen. Den auch, dass es MD-Damstadt-CCCDE ist, der Dienst hätte gerne Zugriff drauf hätte. Und sobald wir hier auf Accept klicken, sind wir wieder zurück beim Headstock und eingeloggt, als der Nutzer, mit dem wir uns da eben gerade authentifiziert haben. Das Coole daran ist, MD-Damstadt-CCCDE hat keine Ahnung von meinen Log-In Credentials, das, der ganze Log-In, das ist alles im Kontext meines Authentifizierungsproviders passiert. Und MD-Damstadt-CCCDE bekommt von dem einfach nur glaubhaft versichert, yo, das ist wirklich gerade PSIDE, der sich bei mir eingeloggt hat. Hier sind die Profilinformationen von PSIDE, die du angefragt hast. Bitte schön. Diesen Vorteil davon, ich muss MD-Damstadt-CCCDE nicht meine Credentials geben. MD-Damstadt-CCCDE muss ich nicht darum kümmern, diese Credentials irgendwie zu speichern und sicher zu haben. Und ich habe eine zentrale Stelle, an der ich so Dinge wie 2-Faktor-Autentifizierung, Multi-Faktor-Autentifizierung, Password-Changes etc. abfrühstücken kann und meine User-Base habe. Den Teil kennt ihr wahrscheinlich alle? Schauen wir uns mal an, wie das Ganze aus der technischen Sicht aussieht. Bevor ich überhaupt so ein Ohr auf Klein nutzen kann, muss ich den Klein, oder ich nenne das jetzt in dem Beispiel zusammen, oder in dem Vortrag mal App, muss ich mich bei dem Dienst, über den ich die Authentifizierung oder Autorisierung machen möchte, registrieren. Dabei hinterlege ich dort typischerweise ein paar Dinge. Das ist zum einen, wie heißt denn eigentlich der Dienst oder die App, die ich da gerade registrieren möchte? Was soll die denn an Zugriff maximal haben können? Wo leitet die am Ende hin zurück? Und gegebenenfalls noch so ein paar weitere optionale Infos, wie eine Webseite, ein Beschreibungstexten, Bild etc. Redirectury ist in dem Fall eben die URL, an die ich weitergeleitet werde, nachdem ich mich dort authentifiziert habe. Die muss man schon beim Registrieren von der App dort angeben, dass eben später nicht jemand sich als meine App ausgeben kann und den Nutzer nach Authentifizierung woanders hin weiterleiten kann. Genauso mit den Zugriffstrechten, wenn ich direkt am Anfang schon festlege, dass diese Anwendung jemals immer nur maximal Readrechte benötigen wird, dann kann ich nicht in einer späteren Anfrage auf einmal irgendwie zu Writerechten eskalieren. Deswegen gibt man das bereits vorher an und bekommt im Gegenzug eine ClientID und ein ClientSecret, die meinen Client eindeutig identifizieren. ClientID ist in dem Fall, kann man als Public betrachten, wird auch so in der URL mit übergeben. Sehen wir gleich. ClientSecret sollte die eigene App niemals verlassen. Wir haben jetzt erstmal ein User, der hat irgendwie sein Webbrowser, macht die Webseite auf und klickt dort auf den Login button. Unsere Anwendung leitet den User jetzt an den Autogesierungsserver weiter. Und das macht es, indem es dem User einen Readirect zurückschickt, der dann von dessen Browser ausgeführt wird. Dabei gibt es folgende Dinge. Einmal ResponseType ist gleich Code, weil das die Art und Weise ist, wie wir Ohr aufgenutzen möchten. So den anderen Arten komme ich dann später noch. Die eigene ClientID, wie ich gerade schon gesagt habe, die ist als Public zu betrachten, die kann einfach dort in der URL stehen. Und die ReadirectBury, also wo ich dann später, nach erfolgreicher Authentifizierung, gerne hätte, dass der User zurückgeleitet wird. Und gegebenenfalls ein Scope, wenn ich nicht den Initial Scope benutzen möchte, sondern zum Beispiel noch mal kleiner einschränken, was ich jetzt hier in dem Fall haben möchte. Sieht dann so aus, also unsere App oder Webseite schickt dem User, beziehungsweise dessen Browser, hey bitte, öffne folgende URL und dieser folgt dann dem Readirect und öffnet die URL zum Autorisierungs-Server, gibt dem dort den ResponseType, die ClientID und die ReadirectBury mit und gegebenenfalls den Scope. Jetzt befinden wir uns beim Autorisierungs-Server, das ist der Teil, den wir vorher mit dem Login-Formular gesehen haben und als erstes prüft der Autorisierungs-Server einmal die ClientID, ob er die kennt und ob die ReadirectBury, die ich gerade angegeben habe, zu den Pass, die da ganz am Anfang angegeben wurden bei der Registrierung. Wenn Scope mit angegeben wurde, prüft er außerdem, ob der innerhalb, ob der ins Subset ist, dessen, was bei der Registrierung angegeben wurde und nur, wenn das alles passt, macht er weiter. Dann kommt der eigentliche Login, also wir lassen, Nutzer und Nutzerinnen, einmal Passvor-Zugangs-Daten, gegebenenfalls Multifaktor-Ordentifizierung, ähnliches eingeben und zeigen danach Informationen über die Anwendung, die da gerade anfragt an, also entweder nur die URL von der Anwendung oder auch die Beschreibung und worauf die denn gerade Zugriff möchte. Nutzer oder Nutzerinnen können jetzt zustimmen und im Falle, dass sie zustimmen, folgt eine Weiterleitung, geben wieder zurück an den Browser des Users, bitte gehe hierhin und schicken ihn zurück zu der Anwendung, also zu der ReadirectBury, die wir mit dem Initialen Request mitgegeben haben. Zusätzlich hängt der Server an diesen Request noch ein Access Code an, den dann gleich relevant wird. Also dieser Access Code ist quasi im Endeffekt ja, Nutzer hat sich erfolgreich authentifiziert, hier ist ein Access Code, damit kannst du gleich weitere Dinge tun. Wichtig ist, mit diesem Access Code kann man noch auf keine Ressourcen und sonst nichts zugreifen. Der Screen, den ich gerade eben meinte, wir geben einmal Zugriff und dann sehen wir hier, wir werden vom Authentifizierungsdienst wieder über den Browser des Nutzers zurückgeleitet und der leitet es weiter an die Webseite. Es ist jetzt in dem Kontext, dass bisher überhaupt keine Kommunikation zwischen unserer App und dem Authentifizierungsdienst stattgefunden hat. Also jetzt mal abgesehen davon, dass wir am Anfang irgendwann mal unsere Anwendung registriert haben. Innerhalb dieses Login Flows ist bisher keine direkte Kommunikation zwischen unserer Anwendung und dem Autorisierungsdienst zustande gekommen, sondern immer nur über Weiterleitungen im Browser des Users und dieser hat eben zwischen diesen beiden Scopes also dem Autorisierungsdienst gewechselt. Mit allem was da dazugehört, also zum Beispiel Cookies, die immer nur im jeweiligen Kontext gültig sind. Das heißt, unsere Anwendung weiß nichts von der Authentifizierung beim Authentifizierungsdienst und kann dementsprechend auch keine Credentials oder ähnliches von dem Klein besitzen. Das Einzige, was wir bis jetzt haben, ist der Access Code, den wir zurückbekommen haben. Mit diesem Access Code, die erste direkte Kommunikation zwischen unserer Anwendung und dem Authentifizierungsdienst, können wir zu dem Authentifizierungsdienst gehen, sagen, hey, ich habe hier folgend ein GrandType, das ist, wir hatten vorhin als ResponseType Code angegeben, das ist das Pondor eben um dann den Access Code in einen Talken um zu tauschen, sagen, GrandType Authorization Code, geben einmal unsere Client ID mit, geben unser Client Secret mit, um wirklich zu beweisen, dass wir der Client sind, die Redirect-Dury, die wir ursprünglich mitgegeben hatten, mit, auch nochmal zur Verifizierung, den Scope, der angefragt wurde und den Code, den wir gerade erhalten haben. Der Authentifizierungsdienst prüft das Ganze jetzt und gibt bei Erfolg einen Access-Token an unsere App zurück. Und mit genau diesem Access-Token können wir dann auf weitere Ressourcen zugreifen. Zum Beispiel, zum Beispiel von Mastodon zu bleiben, auf die Public Timeline eines Users zuzugreifen oder die Profilinformation eines Users abzurufen. Im Context von OpenID Connect würden wir damit jetzt zum Beispiel Profilinformationen oder User-Informationen, die uns zur Authentifizierung eines Users dienen, abrufen können. Das war eine sehr vereinfachte Darstellung bzw. das ist die rudimentäre Nutzungsweise von Ohr auf. Da gibt es aber zusätzlich drauf noch ein paar Sicherheitsmechanismen, weil das, was ich gerade gezeigt habe, ich warte mal, ich gehe da einmal zurück. Das ist an vielen Stellen noch anfällig. Zum Beispiel für Cross-site-Request forgery für Token-Injection-Attacken für, wenn ich versuche, einen Token zu raten, zum Beispiel etc. Deswegen wurden sich über die Jahre ein paar Gegenmaßnahmen ausgedacht. Das erste ist ein State-Parameter. Den geben wir, das ist eine einzige Artige oder zufällige Zeichenkette, die wird initial, wenn bei uns sagt, ich möchte mich einloggen, wird der generiert und lokal zum Beispiel in eine Cookie im Session oder im Local Storage von der Nutzer oder der Nutzer, den gespeichert. Den geben wir dann bei der initialen Authentifizierungsanfrage mit. Bekommen den auch genauso vom Server mit der Antwort wieder zurück und können dann eben bei uns prüfen, ob der State, der in der Antwort mitgesendet wurde, zudem den wir in einer Session oder im Local Storage gespeichert haben, passt. Passt alles, ist alles gut, passt ja nicht, haben wir wahrscheinlich an irgendeiner Stelle jemanden, der versucht uns da einen Code zu injecten oder der Nutzer oder Nutzerin über einen irgendwo platzierten Link versucht hat zu uns zu schicken. Das Ganze ein bisschen erweitert, nennt sich dann Proofkey for Code Exchange, das ist nicht direkt ein Ersatz für den State-Parameter, sondern eher nochmal zusätzlich, wird vor allem für Mobile-Anwendungen und Single-Page-Applikationen empfohlen, könnt ihr aber generell eigentlich immer benutzen, auch wenn zum Beispiel der Server das nicht unterstützt, wird euch damit einfach nicht antworten, aber es geht nicht kaputt. Also er wird euch schon antworten, er wird nur nicht auf diese zusätzlichen Parameter eingehen, so war das gemeint. Das ist auch wieder wie gerade eben beim State-Parameter eine einzigartige oder zufällige Zeichenkette, die wird Code Verifier genannt, wird auch wieder von der App erzeugt und lokal gespeichert, nur dass wir die diesmal nicht im Klartext an den Server schicken, sondern dass wir die vorher einmal durch Base64 URL und ein Hash-Verfahren schicken, zum Beispiel Schad 256, Schad 512, sucht euch was aus und das was dabei rauskommt, nennen wir Code Challenge. Das schicken wir mit der Authentifizierungsanfrage an den Server und geben ihm gleichzeitig noch mit welches Hash-Verfahren da genutzt wurde. Das heißt der Server hat einmal die Challenge und das Verfahren dafür, dass er dafür genutzt wurde, kennt aber den plaintext nicht. Der Server gibt uns diesmal davon nichts wieder mit zurück, sondern der restliche Flow läuft erstmal normal und erst, wenn wir den Access Code vom Server zurück bekommen haben und versuchen den gegen einen Token einzutauschen, müssen wir zusammen mit wieder, wir schicken wieder unser kleinen ID, unser kleinen Secret und den eigentlichen Code Verifier also den plaintext davon. Damit beweisen wir dem Server, dass wir auch die Entität sind, die diesen ganzen Flow initial gestartet hat. Weil nur wir den erzeugt haben können. Server prüft ob Challenge und Verifier zusammenpassen und falls das passt kriegen wir unseren Token zurück. Soweit erstmal zu den Sicherheitsmechanismen. Das was ich euch gerade über Ohr auf erzählt habe ist nur so ein ganz kleiner Teil der Wahrheit. Das ist nämlich der Authorization Code Ground oder der Authorization Code Flow und gibt da noch diverse weitere. Aber das ist somit der Wichtigste und eigentlich auch der, den ihr wenn es geht benutzen solltet. Eine kleine Abschwächung von diesem hier gibt es noch, wenn ihr zum Beispiel eine Single-Page-Applikation oder eine mobile App habt, dann habt ihr im Zweifel keinen Entität, die daran beteiligt ist, die nur unter eurer Kontrolle steht. Das ist so eine Single-Page-Applikation, da kann ich eben in den Source Code gucken bei einer mobilen Applikation, kann ich das auch. Wenn ich irgendwo eine Webseite mit einem Webserver habe, kann ich in der Regel nicht in den Quellcode dahinter schauen oder auch in den Speicher. Das heißt, bei einer mobilen Anwendung oder auch bei einer Single-Page-Applikation kann ich mein Klein-Secret nicht irgendwie in meiner Anwendung backen und das dementsprechend auch nicht benutzen. In dem Fall gibt es trotzdem den Authorization-Code-Flow, nur dass wir ihn dort ohne Klein-Secret machen und an der Stelle solltet ihr dann definitiv Proof-Key für Code Exchange oder Pixie benutzen, um das abzusichern. Außerdem gibt es einen Klein-Credentials-Flow. Da spart ihr euch den ganzen Charme mit der Nutzer-Interaktion, nehmt einfach nur eure Klein-ID und euer Klein-Secret und greift damit auf APIs des Dienstes zu ohne Nutzer-Kontext. Im Beispiel von Mastolon wäre das zum Beispiel die Public Timeline eines Servers, die ihr damit lesen könnt. Dafür braucht ihr keinen Nutzer-Kontext, das könnt ihr einfach so direkt, nachdem ihr eure App dort registriert habt, machen. Außerdem gibt es den Device-Code-Flow für zum Beispiel Geräte mit eingeschränkten Interaktionsmöglichkeiten. Habt ihr vielleicht schon mal gesehen, wenn ihr irgendwie auf eurem Smart TV euch bei YouTube versucht habt, anzumelden, dann zeigt euch euer Smart TV einmal so ein QR-Code oder eine URL, auf die ihr gehen könnt, auf die Zahlen, die ihr dann auf dieser URL eingebt. Dort macht ihr dann den ganzen Autorisierungs-Flow und euer Fernseher kriegt automatisch mit, dass ihr euch dort angemeldet habt. Funktioniert im Hintergrund einfach so, dass euer Server einmal bei dem Autorisierungsdienst sich so ein Code generieren lässt, euch den anzeigt und ab dann periodisch den Authentifizierungsdienst polt, ob ihr euch schon eingeloggt habt. Außerdem gibt es noch zwei Liegesie-Methoden, das ist einmal der Implicit-Flow und der Passwort-Flow. Werde ich nicht näher drauf eingehen, falls ihr die irgendwo entdeckt oder überlegt, sie zu implementieren, macht bitte einen großen Bogen drumrum. Wie vorhin schon gesagt, OAuf an sich kann erstmal keine Authentifizierung, sondern nur Autorisierung. Deswegen haben wir OpenID Connect oder ORIDC, das baut auf OAuf auf und ist im Endeffekt einfach nur ein weiterer Endpunkt, der User-Info-Endpunkt. Den könnt ihr mit dem Access-Talken, den ihr nach der Autorisierung bekommen habt, aufrufen und bekommt dort Informationen über den eingelockten Nutzer, die eingelockte Nutzerin. Zum Beispiel Nutzername, E-Mail-Adresse. Dann habe ich mir gedacht, wir spielen das einfach mal gemeinsam am Beispiel von Mast oder undurch. Weil ich finde, das ist einfach nochmal greifbarer, wenn man das irgendwie gesehen hat. Weil ich mir eine Live-Demo nicht ganz zugetraut habe, habe ich die vorhin einfach screen shorted. Wie wir gesagt haben, wir müssen erstmal Registrieren. Das ist jetzt noch nicht Teil von OR auf, sondern eben Vorbedingungen dafür. Und in der Regel geht ihr zu einem Dienst und klickt euch dort irgendwie in den Dev-Tools oder in den Developer-Bereich davon so ein Kleint. Im Falle von Mast oder undurch geht das jetzt nicht so einfach, weil es ist dezentralisiert, wir haben sehr, sehr viele Server. Das heißt, dort fragen wir einfach am Anfang unserer Nutzer, unsere Nutzerin, welchen Server sie denn benutzen möchte sondern dort per Rest-AP einfach unseren Kleint. Sieht so aus, ist der Apps-Endpunkt, dem geben wir einmal einen Namen für unseren Kleint mit und welche Redirectories der benutzen soll. Ich habe in dem Fall example.com.slashcallback genommen, weil ich nicht die Zeit hatte einen kompletten Kleint zu bauen. In eurem Fall wäre das dann die URL eures Kleins oder wenn ihr zum Beispiel eine App auf dem Telefon benutzt, dann so ein Schema-Link mit fu-double.double-slash auf den eure App reagiert. Was wir zurückbekommen ist unter anderem die Kleint ID und das Kleint-Seekfit neben den Sachen, die wir auch hingeschickt haben. Das ist genau das, was wir für den Rest davon brauchen. Das heißt, die beiden schreiben uns raus und merken uns. Und danach können wir auch schon unseren Nutzer oder unsere Nutzerin auf das jeweilige Log in den Formular weiterleiten. Das ist dann der Ohr auf Authorize-Endpoint. Das heißt, wir wollen den Codeflow gehen, unsere Kleint ID und die Redirectory, wo wir hingehen wollen. Wenn ich hier etwas anderes als example.com.callback angeben würde, wird der Server wieder nicht mitspielen, weil er sagt, das ist nicht das, was mit der App registriert wurde. Unser Nutzer, unser Nutzerin, wird also folgender Login-Screen präsentiert, Ohr vor Beginners, der Name, den wir vorher angegeben haben, möchte gern permissionen, um auf den Account zu greifen und zu vermischen, weil ich keinen Scope angegeben habe und das bei Mustodown der default ist. Wenn ich jetzt auf Authorize-Klicker werde ich wieder an den angegebenen Callback weitergeleitet und dort angehängt, wird eben besagter Code. Den komme ich durch die Callback, durch die Weiterleitung, jetzt in meiner App wieder und kann den zusammen mit meiner Kleint ID, mit meinem Kleinen-Secret und dem ursprünglich angefragten an den Token Endpoint schicken und bekomme daraufhin mein Access-Token zurück, den, den ich brauche um dann auf die eigentlichen Ressourcen zuzugreifen. Das heißt, diesen Token speichere ich mir jetzt und kann damit, im Namen des Nutzers oder der Nutzerin zum Beispiel auf den VeryFile Credentials Endpoint zugreifen und mir dort Profilinformationen auslesen. Seht ihr, der in dem Fall hart funktioniert, ist mein Account. Abtippen des Token können wir euch sparen, gelöscht oder rewockt. Das ist auch ganz wichtig, wenn ihr irgendwie eine Anwendung Zugriffe auf euren Account gegeben habt, dann seht ihr das in der Regel in den Einstellungen oder bei Mastodon Accounts, bei anderen Diensten dürfte das ähnlich sein. Damal regelmäßig reinzugucken, gucken welchen Anwendungen ihr den Zugriff gegeben habt und ob ihr die noch alle braucht, schadet auf jeden Fall auch nicht. Also bei mir merke ich, wenn ich mich irgendwie öfter mal mit einem Private-Tab oder irgendwo eingelockt habe, dann sammeln sich jetzt die dann im Endeffekt irgendwo noch valide Credentials sind, die man an der Zeit einfach mal rauswerfen könnte. Habe ich hier an der Stelle auch gemacht, deswegen ihr sagt, abtippen des Token können wir euch sparen und damit wären wir auch schon am Ende und ich würde gerne Fragen beantworten, falls ihr welche habt, falls es uns von der Zeit irgendwann ausgeht, gerne auch noch draußen an der Bar, auf der Wiese. Genau. Erst mal vielen Dank von meiner Seite. Da gibt es auch schon die erste Frage. Ja, ist mehr ein ganz kurzer Hinweis für alle Leute, die tatsächlich sich jetzt mal ein ORS-Client bauen wollen. Es gibt sehr gute RFCs mit Best Practices für ORS-Clients, für Single-Page Applications, für Native Apps und für andere Clients, da gibt es jeweils einen RFC für, die sollten man sich angucken, weil sonst kann man da extrem viel falsch machen und dann freuen sich die Pentester. Ergänzen dazu vielleicht auch noch, es gibt auch noch diverse Frameworks, die man einsetzen kann. Wenn ihr in eurer Sprache so ein Framework zur Verfügung habt, guckt einfach mal ein bisschen, ob das gut abgehangen ist, ob das viel genutzt wird, wie entsprechende Kommentare auf GitHub sind und nehmt im Zweifel so ein Framework anstatt das selbst zu implementieren. Gut, dann direkt daneben gab es Sie eine Frage, hätte man das Mikrofon noch da lassen können? Danke. Der Token, den ich ganz am Ende bekommen habe, den die Anwendung bekommt, kann ich, wenn ich den Steele im Namen des Users Aktionen durchführen, kann ich mich also, wenn ich in der App schreibe, darum kümmern, diese Tokens geheim zu halten? Genau, der Existoken, den du am Ende bekommst, ist das Einzige, was du brauchst oder was auch jemand anderes brauchen würde, um auf APIs im Namen des Users zuzugreifen. Das heißt, wie du schon sagst, wenn den jemand stielt, hat derjenige oder diejenige die gleichen Rechte wie deine Anwendung oder der Nutzer oder die Nutzerin. In der Regel haben solche Tokens auch eine Lebensspanne, das heißt, die laufen nach einer Zeit ab. Das kann sein, dass ihr direkt initial noch ein Refresh-Token mitbekommt, mit dem ihr den dann wieder erneuern könnt. Es kann sein, dass ihr das selbst nochmal machen müsst. Das hängt immer so ein bisschen von der jeweiligen Implementierung und vom jeweiligen Dienst ab. Ja, danke erst mal. Und ich habe noch eine Frage zu dem Existoken. Also jetzt bei deinem Beispiel, bei Mastodon-Akt, das natürlich sind, dass ich den irgendwie als Mastodon-Client vom Mastodon-Surer bekomme und dann da Dinge tun kann. Wenn ich mich jetzt bei so einem Login with Google Teil bei einem Hedge-Tok einanmelde, dann bekomme ich den Token ja von Google und dann muss das Hedge-Tok im Hintergrund mit Google kommunizieren, um dann abzufragen, ob der Token valide ist oder wie läuft das. Das nimmt diesen Token zumindest initial, um eben OIDC, also den Part mit der Authentifizierung zu machen. Das heißt, es ruft damit einmal den User-Info-Endpunkt auf, um zumindest deinen Namen, deine E-Mail-Adresse zu bekommen, um deinen Account damit anzulegen und gibt dir dann sehr wahrscheinlich einfach selbst eine Session. Das heißt, es wird nicht regelmäßig nachprüfen, ob du jetzt noch irgendwie bei Google eingeloggt bist, aber es wird eben initial einmal prüfen, wer du bist, sich das von Google bestätigen lassen und dich dann damit mit einer eigenen Session einloggen. Cool, danke. Du hast gezeigt, wie man so ein Klein registriert. Da war es irgendwie gar kein Klein registriert oder so bei, im Sinne von, dass da irgendwie ein Hüte war, den Klein zu registrieren. Kann ich einfach eine Million Klein registrieren? Ich vermute, Mastodon hat Rate-Limits. Wie viel du per Zeit registrieren kannst, aber ansonsten habe ich keine Limitierung an der Stelle gesehen. Also du kannst mit dem API-Request kannst du ihn beliebig oft abschicken, bekommt beliebig oft ein Klein-ID-Klein-Sieg zurück, kann passieren, dass es zeitlich rate-limited ist. Mehr Limit habe ich bisher bei Mastodon nicht gesehen. Aber auch schwierig vor, dass an irgendeiner Stelle also dann Limit, worauf würde man da limitieren wollen auf den Klein-Namen, dann nummeriere ich ihn halt durch. Also ist an der Stelle schwierig. Bei anderen Diensten ist es häufig so, dass so eine Klein-Registrierung in deinem persönlichen Account als Entwickler dort gebunden ist und dass du dann eben so Dinge oder Restriktionen hast, wie du darfst halt nur 10 Clients pro Entwickler-Account und ansonsten musst du ganz viel Geld bezahlen oder so. Bei der Klein-Registrierung hattest du neben dem Klein-Sieg wird und der Klein-ID unten auch noch so ein Warpit-Talk oder Warpit-Sieg wird. Ist das was Mastodon Spezifisches oder gehört das auch noch zum Overflow? Das was Mastodon Spezifisches, da habe ich ehrlich gesagt auch nicht nachgeguckt. Wofür es denn genau benutzt wird, mich hat es auch ein bisschen irritiert. Habe ich aber bei Mastodon das erste Mal gesehen in dem ganzen Flow? Ja ich habe mich immer gefragt ob ich jetzt mal anmelde. Ich will ja die ja gar nicht nutzen, sondern ich will ja eigentlich einen anderen Dienst nutzen. Kannst du darauf eine Antwort geben? Tun die die Daten sammeln oder was ist der Vorteil für den Offerization-Server? Was sie genau damit machen, kann ich dir nicht sagen, das weiß ich nicht und ich kann über den Vorteil den sie davon haben, auch nur spekulieren. Aber an sich sind es alles Dienste, die eine sehr, sehr große Nutzerbasis haben und dadurch, dass sie einem den Login mit dem eigenen Dienst woanders ermöglichen ja auch wieder so eine Art Kundenbindung aufbauen. Also wenn ich mir jetzt irgendwie bei Ziegdiensten mich eben mit Facebook oder mit Google angemeldet habe, dann wird das ja auch für mich irgendwann eine Hürde von dem Dienst wegzumigrieren weil ich ja überall meine Accounts oder Registrierungen entweder ändern oder neu erstellen müsste. Ich vermute, dass das deren Geschäftsmodell dahinter ist, ob das wirklich so ist, ob es das Einzige ist, ob man sich das anbieten kann. Aber gibt ja jetzt auch nicht nur Google und Facebook, die sowas anbieten, sondern ganz häufig hat man das auch in Firmenkontexten, dass es eben einen zentralen Login irgendwo gibt und das Interesse daran, kann ich auf jeden Fall beschreiben, dass es einen zentralen Ort zu haben, an dem sich Nutzer und Nutzerinnen einloggen können und Nutzer und Nutzerinnen darauf zu konditionieren, sich nur dort einzuloggen und nirgends anders. Und ich habe eine zentrale Stelle, an der ich weitere Restriktionen, wie zum Beispiel Zwei-Faktor- Identifizierung, Passwort- Änderungen etc. entfossen kann. Dann jetzt noch eine letzte Frage dahinten in Gelb. Die Frage war, ob es nicht nur Unternehmen gibt, die das anbieten, sondern auch staatliche Institutionen, die OOF anbieten. Ich wüsste jetzt nicht konkret, dass es mit dem Ausweis mit persönlichen Details über staatliche Stellen geht, aber wäre natürlich auch ein prädestinierter Endpunkt für sowas oder Anbieter für sowas. Ich weiß, dass sehr, sehr viele Banken OOF benutzen, um ihr Online-Banking zu realisieren und der Sprung zu staatlichen Stellen wäre nicht weit. Ich weiß jetzt aber nicht, ob es definitiv schon was gibt. Vielen Dank für den Vortrag und die sehr interessanten Fragen und was es jetzt eigentlich genau. Vielen Dank.