Beeindruckend, wie du JSON Web Tokens so anschaulich und eingängig erklärt hast, dass du dafür keinerlei Bilder benötigst. Und weil sie nicht nötig waren, haben sie auch überhaupt nicht gefehlt, dafür gab es ja die zahlreichen kleinen und nützlichen Wiederholungen. Ich fand es auch super, wie du die Umgebung, in der JWTs eingesetzt werden, beschrieben hast, besonders die Vertrauensverhältnisse, die man dafür braucht. Einfach nur genial.
Sehr gut erklärt, mal wieder. Unterstützend rate ich das Video anzuschauen, während man sich die Webseite oder den RFC anschaut. So konnte direkt zuordnen, was du erzählt hast.
[gr] Danke schön! Und was die Bilder angeht, ja, kann ich nachvollziehen … wir versuchen es meistens, eher minimalistisch zu halten, aber ja, manchmal wäre es ganz hilfreich.
Danke für den Tipp, dass es da auch "none" beim Algo geben kann. Finde, dass symmetrische JWTs Sinn machen, wenn diese als Login Tokens verwendet werden, und der Client diese sowieso nicht lesen muss. Der Server signiert sie also symmetrisch, schickt sie dem Nutzer und wenn der Nutzer sich später anmelden möchte, schickt er dem Server diesen Token zurück und der Server prüft dann, ob alles passt und nix manipuliert wurde.
Ich habe ein entsprechendes System vor ein paar Jahren implementiert als JWT noch nicht sonderlich verbreitet war. Ich referenziere im ISS auf den öffentlichen Schlüssel, validiere das Server Zertifikat gegen eine CA und vertraue einer Whitelist an CN's. Dadurch kann das Login-System stündlich neue Schlüssel generieren. Funktioniert gut, aber es gibt keine kompatiblen Implementierungen. Welches Szenario würde einen häufigen public-key Wechsel managen und wäre z.B. zur Implementierung von Istio kompatibel?
[gr] Ich denke, ein Ansatz, den Du mir mal angucken könntest (sofern ich die Frage richtig verstanden habe), ist JWKS, beispielsweise unter auth0.com/docs/tokens/json-web-tokens/json-web-key-sets Die Idee ist, dass Du für einen IdP die Keys dynamisch über einen Endpunkt zur Verfügung stellst, und sie von dort abrufen kannst. Was man dabei aber berücksichtigen sollte, ist, dass man nicht für jeden Request auch wieder einen JWKS-Request macht, sondern das vernünftig cached - wobei sich dann die Frage stellt, wann man den Cache invalidiert. Wie immer, there are two hard problems in computer science … 😉
@@thenativeweb das hatte ich befürchtet - JWKS ist mir bekannt. Für lang laufende Token mit häufigem Schlüsselwechsel wird die Struktur riesig. Da kein "offizieller" Weg vorgesehen ist, im Token die KID zu referenzieren werden Prüfungen über die Zeit (->viele Keys im JWKS) langsam und teuer. Man könnte cachen bis eine Validierung fehl schlägt, aber damit schlagen gefälschte Token tiefer ein und begünstigen DOS Vektoren. Trotzdem vielen Dank für die Antwort!
Beeindruckend, wie du JSON Web Tokens so anschaulich und eingängig erklärt hast, dass du dafür keinerlei Bilder benötigst. Und weil sie nicht nötig waren, haben sie auch überhaupt nicht gefehlt, dafür gab es ja die zahlreichen kleinen und nützlichen Wiederholungen. Ich fand es auch super, wie du die Umgebung, in der JWTs eingesetzt werden, beschrieben hast, besonders die Vertrauensverhältnisse, die man dafür braucht. Einfach nur genial.
[gr] Vielen, vielen Dank 😊
Sehr gut. Mit kleinen Schaubildern wird die Struktur von JWTs oder die Signaturverfahren anschaulicher.
[gr] Danke für Dein Feedback 😊
Sehr gut erklärt, mal wieder.
Unterstützend rate ich das Video anzuschauen, während man sich die Webseite oder den RFC anschaut. So konnte direkt zuordnen, was du erzählt hast.
Frei gesprochen aber Bilder wären echt super. Aber haben ja schon einige in den Kommentaren erwähnt. :) Danke für deinen Content!
[gr] Danke schön! Und was die Bilder angeht, ja, kann ich nachvollziehen … wir versuchen es meistens, eher minimalistisch zu halten, aber ja, manchmal wäre es ganz hilfreich.
Danke für den Tipp, dass es da auch "none" beim Algo geben kann.
Finde, dass symmetrische JWTs Sinn machen, wenn diese als Login Tokens verwendet werden, und der Client diese sowieso nicht lesen muss.
Der Server signiert sie also symmetrisch, schickt sie dem Nutzer und wenn der Nutzer sich später anmelden möchte, schickt er dem Server diesen Token zurück und der Server prüft dann, ob alles passt und nix manipuliert wurde.
[gr] Das stimmt, das ist ein potenzielles Anwendungsszenario.
prima Erklärung - danke!
[gr] Gern geschehen ☺️
Hi, super erklärt! Aber mal eine andere Frage: was sind das für RGB Panele hinter Dir am Whiteboard? :-D
[gr] Das freut mich, vielen Dank 😊
Die RGB-Panele sind die Hexagons von Nanoleaf.
Ich habe ein entsprechendes System vor ein paar Jahren implementiert als JWT noch nicht sonderlich verbreitet war. Ich referenziere im ISS auf den öffentlichen Schlüssel, validiere das Server Zertifikat gegen eine CA und vertraue einer Whitelist an CN's. Dadurch kann das Login-System stündlich neue Schlüssel generieren. Funktioniert gut, aber es gibt keine kompatiblen Implementierungen. Welches Szenario würde einen häufigen public-key Wechsel managen und wäre z.B. zur Implementierung von Istio kompatibel?
[gr] Ich denke, ein Ansatz, den Du mir mal angucken könntest (sofern ich die Frage richtig verstanden habe), ist JWKS, beispielsweise unter auth0.com/docs/tokens/json-web-tokens/json-web-key-sets
Die Idee ist, dass Du für einen IdP die Keys dynamisch über einen Endpunkt zur Verfügung stellst, und sie von dort abrufen kannst.
Was man dabei aber berücksichtigen sollte, ist, dass man nicht für jeden Request auch wieder einen JWKS-Request macht, sondern das vernünftig cached - wobei sich dann die Frage stellt, wann man den Cache invalidiert. Wie immer, there are two hard problems in computer science … 😉
@@thenativeweb das hatte ich befürchtet - JWKS ist mir bekannt. Für lang laufende Token mit häufigem Schlüsselwechsel wird die Struktur riesig. Da kein "offizieller" Weg vorgesehen ist, im Token die KID zu referenzieren werden Prüfungen über die Zeit (->viele Keys im JWKS) langsam und teuer. Man könnte cachen bis eine Validierung fehl schlägt, aber damit schlagen gefälschte Token tiefer ein und begünstigen DOS Vektoren.
Trotzdem vielen Dank für die Antwort!
Wo sollte man das jwt speichern? Ich habe gehört httponly cookies eignen sich dafür... aber gibt es noch eine bessere Alternative ohne Cookies?
Vielen Dank ! Gut erklärt, Bilder waren gar nicht nötig !
[gr] Vielen Dank 😊
Welche Signatur hatte unser alter Personalausweis, als er noch keinen Chip hatte?
Gut erklärt, es fehlten ein paar Bilder oder Diagramme um es zu veranschaulichen.
[gr] Danke für Dein Feedback 😊
Genau damit beschäftige ich mich gerade 😀
[gr] Das war doch dann gutes Timing 😊