Unterschied: JWT und Sessions

Veröffentlicht 31. Oktober 20204 j

Hi,

wann und wofür benutzt man denn JWT und wann und wofür Sessions am Besten?

31. Oktober 20204 j

Session: Der State wird auf dem Server gehalten. Das heißt, der Server weiß "Die Anfrage gehört Session X und diese Gehört zu Benutzer A".

Stateless: Der Token (kann JWT sein, muss aber nicht) wird mit dem Request mitgesendet. Der Server hat selbst keinen State, aber er sieht das Token und weiß dann: "ah, das Token gehört zu Benutzer A".

Vorteile von Stateless:

Stell dir mal vor, du hast nicht nur einen Server, sondern ganz viele. Dann müssten die Server irgendwie ihre Sessions synchronisieren -> Aufwand.

Vorteile von JWT:

In dem JWT-Token können Informationen gespeichert sein.

31. Oktober 20204 j

Autor

vor 33 Minuten schrieb pr0gg3r:

Session: Der State wird auf dem Server gehalten. Das heißt, der Server weiß "Die Anfrage gehört Session X und diese Gehört zu Benutzer A".

Stateless: Der Token (kann JWT sein, muss aber nicht) wird mit dem Request mitgesendet. Der Server hat selbst keinen State, aber er sieht das Token und weiß dann: "ah, das Token gehört zu Benutzer A".

Vorteile von Stateless:

Stell dir mal vor, du hast nicht nur einen Server, sondern ganz viele. Dann müssten die Server irgendwie ihre Sessions synchronisieren -> Aufwand.

Vorteile von JWT:

In dem JWT-Token können Informationen gespeichert sein.

Danke für die Antwort. Ich meinte aber eher den Unterschied zwischen:

- Session ID, welche in einem Cookie gespeichert wird und alle anderen Infos auf dem Server zu der ID

- Token (JWP, oder was gibt es noch?), wo alle Informationen auf der Clientseite gespeichert (auch im Cookie) werden und der Server nur den Token validieren muss

Wann benutzt man was davon?

31. Oktober 20204 j

Ich verstehe deine Frage nicht ganz. Erst einmal ist es davon abhängig, was dein Backend bietet. Hast du ein Session-basiertes Backend, wird eben die Session verwendet. Ob du die Session in einem Session-Cookie oder Token in Cookies speicherst oder auch nicht, hat mit der grundlegenden Technologie erst mal nichts zu tun.

Hast du ein stateless Backend, dann wird es irgendwie irgendeine Art von Token verwenden. Wird gerne bei APIs gemacht.

Es kommt auch immer drauf an, was für Technologie du verwendest. Hast du zB ne PHP-Seite, ist die Verwendung von Sessions recht einfach (solange du einen Server hast).

Willst du APIs erstellen, ist stateless die bessere Wahl, zumindest wenn man REST macht: Die URL entscheidet auf welche Ressource zugegriffen und zurückgesendet werden und nich die Session. Ich habe da auch mal einen wilden Mix gesehen, da konnte man sich nie sicher sein was zurück kommt (je nach Rolle und zig anderen Faktoren). Sowas will man eigentlich vermeiden.

/Edit:

Nochmal heruntergebrochen:

Im Browser: ist es egal, der kann ein Session-Cookie oder ein Token in einem Cookie speichern.

Im Backend:

- Session: stateful

- Token: stateless

Bearbeitet 31. Oktober 20204 j von pr0gg3r

31. Oktober 20204 j

Um es vllt einmal anhand eines Beispiels zu machen:

Ich trenne Front + Backend immer mittels subdomain.
Wenn mein Frontend mittels z.b. Axios mit api.meinedomain.com kommuniziert (z.B. einloggt, Request sendet etc) dann erfolgt dies mittels JWT.

Nutzt du z.b. Laravel und hast auch diese unschöne Angewohnheit, mittels blade-Templates im Grunde Front+ Backend auf einen Haufen zu werfen, kannst du Sessions verwenden.