nicht angemeldet
Verwirrung um JWT Tokens
1 0 0 0 
Rolf B
Verwirrung um JWT Tokens
Hallo,
Versuche, das Grundprinzip von JWT Tokens genauer zu verstehen...
...genauer gesagt von Access und Refresh Tokens. Habe mir dazu jetzt drei verschiedene Tutorials mit [mindestens] vier verschiedenen Herangehensweisen angesehen und bin nun ein wenig verwirrt.
Beide Tokens werden mithilfe des Private Server Keys signiert und verschlüsselt an den Client geschickt. Das (länger gültige) Refresh Token wird dabei zusätzlich in der Datenbank mit der entsprechenden User ID hinterlegt./(?)
Wenn nun ein (kurzfristig gültiges) Access Token abläuft, wird das vom Client geschickte Refresh Token mit dem in der Datenbank abgeglichen (??) und wenn für gültig empfunden, wird ein neues Access Token ausgestellt. (???)
Wenn das Refresh Token abläuft - wird dann ein neues Refresh Token ausgestellt oder der Client zur erneuten Authentifizierung genötigt?
...oder war das alles Humbug und funktioniert in Wahrheit GAANZ anders?
Zu allem Überfluss kommen auch manche JWT Tutorials ganz ohne Refresh Token aus und behandeln nur Access Tokens.
Danke für Aufklärung!
Xandl.
-
Für mich stellt sich das wie folgt dar:
- Ein JWT-Token berechtigt zum Zugriff auf „irgendetwas“.
In konkreten Implementationen kann geregelt werden, ob und wie nach einem Ablauf des JWT-Token ein neues generiert wird.
Deine Fragen drehen sich um (eine) solche konkrete(n) Implemantation(en) - Aber ohne diese zu nennen. Dein „Habe mir dazu jetzt drei verschiedene Tutorials mit [mindestens] vier verschiedenen Herangehensweisen angesehen und bin nun ein wenig verwirrt.“ lässt sogar den Schluss zu, dass Du Tutorials zu verschiedenen Implementationen angesehen hast. Das ist in etwa so, als ob Du ein Tutorial zu dBase gesehen hast und Dich fragst, warum das Gezeigte nicht in MariaDB, MSSQL oder OracleDB funktioniert... sind doch alles Datenbanken.
Die Implementation zu kennen ist aber eine Voraussetzung, um Deine Fragen beantworten zu können.
-
Handelt sich eigentlich um ein ziemlich ordinäres Login System, wo der Client quasi eingeloggt bleibt und so auf einen privaten Bereich Zugang hat. Hier böte sich natürlich auch die PHP SESSION Variable an, die ja aber aber den "Nachteil" mit sich bringt, dass die Beziehung Client/Server dann nicht mehr stateless ist (Frage der Skalierbarkeit).
Zwar ließen sich mithilfe der SESSION Variable Brute Force Attacken durch Rate Limiting ganz gut in den Griff kriegen - das müsste aber andererseits eigentlich auch mit mit Zeitstempel versehenen JWT Tokens gut umsetzbar sein…
Aber wie funktioniert in diesem Fall das Zusammenspiel zwischen Refresh und Access Tokens sinnvollerweise?
Danke, Xandl.
-
Handelt sich eigentlich um ein ziemlich ordinäres Login System, wo der Client quasi eingeloggt bleibt und so auf einen privaten Bereich Zugang hat. Hier böte sich natürlich auch die PHP SESSION Variable an, die ja aber aber den "Nachteil" mit sich bringt, dass die Beziehung Client/Server dann nicht mehr stateless ist (Frage der Skalierbarkeit).
Es ist IMMER das billigere Verfahren, welches besser skaliert. Und wieso sollte eine Session etwas am stateless-Charakter von HTTP[S] ändern? Sessions skalieren übrigens sehr gut. Oder arbeitest Du an einer Lastverteilung via Level-3 Switching, willst also mehrere Server auf verschiedene Rechenzentren von Telkos oder dergleichen verteilen? Da sehe ich jetzt auch keinen Vorteil von JWT. Die Daten müssen (wenn die Session auch „reisenden“ Clients stabil zur Verfügung stehen sollen) so oder so zwischen den teilnehmenden Servern ausgetauscht werden. Bei Round Robin auch…
Zwar ließen sich mithilfe der SESSION Variable Brute Force Attacken durch Rate Limiting ganz gut in den Griff kriegen - das müsste aber andererseits eigentlich auch mit mit Zeitstempel versehenen JWT Tokens gut umsetzbar sein…
Weder noch. Brute Force abzufangen sollte wegen des zwingend mit diesen verbundenen DDoS-Charakters immer so billig wie möglich erfolgen. JWT sind teuer in Erzeugung und Auswertung.
Und vor allem sind die JWT für was anderes, viel komplexeres als Sessions gedacht. Einfache Regel: Was mehr Logik erfordert ist teurer.
-
Hallo Raketenwilli,
Sessions skalieren übrigens sehr gut
Ich glaube, es ging ihm um einen geclusterten Webserver. Entweder muss ein Client bei einem Host bleiben, was wirklich suboptimal skaliert und Failover verhindert, oder man braucht einen singulären Sessionserver (in ASP.net State Server genannt) oder eine geschickte Implementierung über eine Session-Datenbank (was ich als aspstate DB kenne).
Beides ist im PHP nativ nicht drin. Glaube ich… Ich habe mal an einer PHP Seite mitgemacht, die eine Session DB verwendete, aber die Seite war nicht geclustert. Aber bestimmt kriegt man entsprechende Libs irgendwo her.
Rolf
--
sumpsi - posui - obstruxi-
oder eine geschickte Implementierung über eine Session-Datenbank.
Dafür gibt es fertige Lösungen (in Frameworks) und Beispiele im Web.
Man kann sogar das Session-Verzeichnis einfach auf eine NFS-Freigabe legen - wenn denn das Aufräumen sodann diesem (oder einem) Server überlassen wird.
Mit Debian und dessen Derivaten ist das kein Problem. Siehe
/etc/cron.d/php:# Look for and purge old sessions every 30 minutes 09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi ~Das muss man auf den anderen Servern nur abschalten.
-
Man kann sogar das Session-Verzeichnis einfach auf eine NFS-Freigabe legen - wenn denn das Aufräumen sodann diesem (oder einem) Server überlassen wird.
Da möchte ich Zweifel ob der Performance anmelden. MemoryDB und Konsorten wären die bessere Wahl.
-
Man kann sogar das Session-Verzeichnis einfach auf eine NFS-Freigabe legen - wenn denn das Aufräumen sodann diesem (oder einem) Server überlassen wird.
Da möchte ich Zweifel ob der Performance anmelden.
Also ich schaufle hier via NFS in einem 1GBit/s-Netz etwas mehr als 110Megabytes/s. Wie viele aktive Sessions werden verwaltet? Und wie viele Zugriffe verursachen diese?
MemoryDB und Konsorten wären die bessere Wahl.
Kommt drauf an. Du kannst ja für die Sessions auch eine oder mehrere Ramdisks bauen und die via NFS frei geben. Aber eine Frage: Wieviel Ram willst Du denn bereitstellen, wenn Du bei NFS Performancebedenken hast…
-
-
-
-
-