A friend who is just getting into using Nodejs for backend development asked me to explain the difference between using session and jwt. So I thought I’d write this for any other person trying to understand what it means when you hear other developers talk about sessions and token based authentication.
Quick Introduction
Firstly, let’s talk about the HTTP (HyperText Transfer Protocol). From a quick Google search we get that:
HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
From the above definition, we can tell that HTTP is what enables communication between a client (frontend) and a server (backend). HTTP is stateless so each request made is totally unaware of any action taken previously. Say for example we just logged into our twitter account and we navigate to our settings page, with the default HTTP behavior, we would be required to log back in again because the server has no idea that we just logged in but with session and token authentication we can tell the server that we are already logged in and we have should be granted access to that page.
What is session based authentication?
Session based authentication is one in which the user state is stored on the server’s memory. When using a session based auth system, the server creates and stores the session data in the server memory when the user logs in and then stores the session Id in a cookie on the user browser.
The session Id is then sent on subsequent requests to the server and the server compares it with the stored session data and proceeds to process the requested action.
What is token based authentication?
Token based authentication is one in which the user state is stored on the client. This has grown to be the preferred mode of authentication for RESTful APIs. In the token based authentication, the user data is encrypted into a JWT (JSON Web Token) with a secret and then sent back to the client.
The JWT is then stored on the client side mostly localStorage and sent as a header for every subsequent request. The server receives and validates the JWT before proceeding to send a response to the client.
headers:{
"Authorization": "Bearer ${JWT_TOKEN}"
}
- A typical example of how the token is sent with the header to the server
When to use?
There really isn’t a preferred method for authentication, both methods can be used interchangeably or together to create a hybrid system. It all boils down to the developer and the use case.
However, it is worth noting that token based authentication scales better than that of a session because tokens are stored on the client side while session makes use of the server memory so it might become an issue when there is a large number of users using the system at once.
Top comments (18)
Best Explanation On Internet
Thanks. I'm happy you liked it.
I read ur article on medium. Good job.
How to secure the JWT data? for example, in the session, user_id, shopping cart items, etc are stored on the server, while in JWT they are stored on the client, so the client may be able to change his user_id to 1 for example to gain super admin permissions later. This is a messy point to me!
JWT implementation already deals with that. Simply put, anyone can read (decode) the token. (the encoding scheme is Base64). However, it's impossible to forge a new valid token like your situation without the authenticating server knowing about it. The fake token on subsequent requests will be rejected immediately.
Even if a user tampers a token stored on client side,the server will compare the token sent with each subsequent request with it's secret key.
@goose97 @webdevopsfresher
_It is too late, but thank you for your reply. _
This may explain why such kinds of authentication need the HTTPS? I think, to add encryption as an additional security layer between the client and the server.
Thanks for a great intro to this topic!
Please... for the love of god, never store the JWT in localStorage nor sessionStorage. It is vulnerable to XSS and a ton of other stuff. Store it in a secure cookie and let the server handle it without any client manipulation.
Anyway this is a great explanation!
I love the simplicity, thanks
Hey! This is the best explanation. Thank you!
What is the validity period of the token and how to ensure it is active
Hey, you get to set the validity when implementing the token on your server.
Thanks
great
how do we know the jwt received is right if we don't store it on the server side ? Do we encrypt it with our own private keys and decrypt them back afterwards?
Hey ! Pretty much, yes. Basically, once the server create the JWT, it'll "sign" it with a secured secret (an overcomplicated string, most likely). When your client send the JWT with the request, the server will "verify" the token, using the secret key you used to sign it.