Session tokens & JWT tokens explained

Session tokens & JSON web tokens are very common & important topics when it comes to handling user authentication and authorization in your application.

Understanding Session Tokens

Imagine you're logging into your favorite website. When you enter your credentials and hit 'login', the server validates the user's credentials. If the credentials are correct, the server then authenticates you and generates a unique session token. This token acts as your proof of authentication throughout your session. This token can be a randomly generated string or encoded information, depending on the implementation.

What's important to note here is that session tokens are typically stored on the server's end, either in memory or a database. They're often short-lived, expiring after a period of inactivity or after you log out. This adds an extra layer of security, as it reduces the window of opportunity for potential attackers to exploit stolen tokens.

After the server has successfully generated the session token, the server sends the session token back to the client. Typically, this is done by setting a cookie in the client's browser with the session token as its value.

Because of this, when the client makes subsequent requests to the server, such as navigating to different pages or performing actions, it includes the session token with each request. Upon receiving a request, the server checks the session token included in the request with the session token in the server's memory or the database. It verifies whether the session token is valid and corresponds to an active session. If the token is valid, the server uses it to identify the user and their session, and then sends back the requested resource in the response.

The server maintains session data associated with the session token, such as user preferences, authentication status, and any other relevant information. Alternatively, the server just encodes the user ID and stores it in memory or the database and, based on every successful token verification, returns the user details from the database.

One important thing to note is that if session tokens are stored in memory, then when the server crashes, all the session tokens for each user stored in the server's memory get removed accordingly, causing the entire session data to be lost and forcing all the users to re-login.

Session tokens also require the server to maintain session state for each active session. This can lead to increased memory and storage usage on the server, especially in applications with a large number of concurrent users.

A good thing about session tokens is that because we store the token in the server memory or database, we can control invalidating or logging out a user anytime we want from the backend itself.

Understanding JSON Web Tokens (JWT)

Now let's discuss JSON Web Tokens (JWT). Again, let's consider the scenario where a user tries to log in to a website. The user or client provides their credentials, such as username and password, to the server for authentication. The server then validates the user's credentials. If the validation turns out successful, the server creates a JWT containing payload data about the user. This data could include user ID, roles, permissions, and any other relevant information.

Along with the payload data, in most cases, the server may sign the JWT using a secret key or private key to ensure its authenticity and integrity. This prevents tampering with the token by unauthorized parties. After the JWT is successfully generated, the server sends the JWT back to the client as part of the response payload. This JWT can either be stored in the cookie or local storage.

For subsequent requests to protected resources in the server, the client includes the JWT in the request headers, typically in the Authorization header using the Bearer scheme. Upon receiving a request, the server extracts the JWT from the request headers. The server then decodes and verifies the attached token based on the secret or private key. If it is valid, the server sends a response to the client. The server, upon decoding the JWT successfully, also extracts the payload data embedded in the JWT, which contains information about the user.

JWTs often have expiration timestamps to enhance security. If a JWT has expired, the server may reject the request or require the client to obtain a new JWT by re-authenticating. When a user logs out or their session expires, the server may invalidate the JWT associated with the user's session. This prevents further access to protected resources using the same JWT.

So, basically, JWTs are self-contained tokens that include all necessary information about the user. This eliminates the need for the server to store session state, making JWT-based authentication stateless and scalable. However, it's important to ensure we don't encode the JWT with a lot of user information, as it could increase the size of the JWT payload, causing performance issues while decoding it.

Also, JWTs have limited revocation, meaning they expire based on their expiration timestamp only, and the server or backend usually cannot control when to revoke or expire the JWT manually in case of a security breach. The revocation can be done from the server by changing the private key, but that isn't a good practice since it could cause all other users to also be unauthenticated.

Conclusion

So this was all about session tokens and JSON web tokens. If you found the video insightful, drop a like and subscribe for more.