JSON Web Tokens VS Sessions
If we're talking about scalability , you can not use only Sessions because the memory or I / O you'll need is gigantic. Using only JWT, so much has 10, 100 or 100 million users, but not everything is just sweet.
The hybrid model is usually the best. You can persist sessions so that your user's state is persisted between several different devices. In the meantime, using JWT can help you reduce network traffic and I / O operations. JWT can also be used to give you an application of Single Sign-On , where user credentials will only be used on the first login, and then you will use authorization tokens to renew your regular tokens.
For your application to have the status maintained , just sign your JWT with some information relevant to the user's status. Remember that JWT can store any information you want on the client side with the client without being able to read it. You can add the current route, the path it has traveled, and persist in the database later, you can either save the nomeDeUsuario or some random token used to identify the session.
On network traffic , as you add information to JWT, it grows, and as a result, data traffic grows. It is necessary to realize that each strategy has a negative point, being the use of the processor to decode the tokens the negative of the JWT. Meanwhile, the negative side of sessions is the use of I / O and RAM .
One thing to note is that design of your application should realize when you need to use I / O, sessions in-memory, or JWT.
Two examples of what I can do for you:
- 1) A business application for 50 ~ 100 people with little access.
In this application, I did not care much. The 50 ~ 100 sections were always in RAM to ensure the status of the users. A fall of energy and 'xablau'. In the meantime, users logged in only once, and after that, the server sent a JWT with only the username of the user, which was used to identify and save it in cookies. The server relied on encrypted JWT and took the username as true. Meanwhile, with each login JWT was renewed for another week and, if it was overdue, the server requested the credentials.
- 2) A learning application, a scalable game.
In this application, there were no sessions. You simply create the account, get your JWT, which is stored in the Local Storage and stays logged in forever. Whenever he goes to the application, his account is identified and an I / O is made to create a character to play based on the previous games. Whenever the player dies, another I / O is done to save some information about the match and the dead character.
Quick Overview
Tokens
- Standardized by RFC 7519 .
- Quite compatible with mobile devices.
- It consumes more CPU, but less RAM
- Unsafe.
- Born to be small and keep logged in with single login.
- Stored on client, processed on server.
Sessions
- Although not standardized, it is widely used.
- Workarounds for dealing with mobile.
- Consumes more RAM and I / O, but less CPU.
- Unsafe.
- Born to 'keep logged in'.
- Stored on the server.
Everything is insecure, just left as a reminder. ;)
