DEV Community

Discussion on: JSON Web Tokens (JWT) vs. SessionID 🔐 ? explained in 2 mins

Collapse
 
szalonna profile image
Joe

We migrated from a simple JWT-based solution to a SessionID-to-JWT solution, where we store a session ID on the frontend, the backend validates it and replaces it to a JWT token with short expiration time and all the other services - which are running in our trusted environment - using this JWT token to authorize the requests.
With this solution:

  • we can easily revoke sessions (e.g. we detect some abusive behavior or the user logs out)
  • the backend services can authorize the requests based only on the JWT token
  • we can skip the logic and the user flow when the JWT token expires on the frontend and needs a refresh, as the session extends with every request and the JWT only used for a single request

...but the dark side is:

  • we need to ask for a new JWT token for each requests so the authentication service is under heavy pressure (we can fix this by creating tokens for longer expiration time and cache them for each session)
  • we need to create a logic in which the authorizer service can create a new token for the session (e.g. we need to store some kind of refresh token and need to manage that if the refresh token expires)

In addition, we use a double session ID solution:

  • one is stored as HTTP-only cookie
  • one is stored in the local storage and added as custom HTTP header for every request

With this we can reduce the possibility of XSS and XSRF.

Collapse
 
techbos profile image
TechBos😎

The hybrid solution and the duo-session solution are both very interesting! Thanks for sharing.