JSON Web Tokens (JWTs) vs Sessions Cookies : Web Authentication

Показать описание

When we browse the web using some browsers such as Chrome and Firefox, we will normally use HTTP which is a stateless protocol. It means that each request sent from the browser will not leave any state data on the server, which will cause the subsequent requests from the same client cannot be identified to be coming from the same sender. Currently, some popular ways to make servers remember the clients' states are using the session cookies or the JSON web tokens.

How Server-Side Sessions Work?
Session cookies are an old way of saving clients' states on the server side. The client will send the login details such as username and password to the server. The server will authenticate those details and then create a session object in its session store. The session store is a place where session data is being stored on the server memory, databases or both. Then, the server returns a cookie to the client with the session ID. That cookie will be stored in a secure place on the client where it can be accessed by HTTP only. This limitation will prevent other malicious javascripts from accessing those session cookies. If the client makes a follow-up request, the browser will send the cookie to the server, and the server will use the session id to check the session object in its session store to authenticate the user's login status.

How JSON Web Tokens Work?
Abbreviated as JWT, JSON web tokens are getting popular in recent years with the booming of the modern web technologies such as microservice architectures etc. Different from the centralized server system from the old days, today's server systems usually contain a couple of loosely coupled service components. Each user will authenticate their identity on one or some of those components. It is not an easy job to synchronize the session store on each of those components. JWT is a good solution for this issue. Unlike server-side sessions which will maintain a session store on server's memory or databases, JWT will only be stored on the client's computer and there is no need for the server to maintain anything. After the authentication of the user, the server will create a JWT token for the client, which includes a header, a payload such as user details and expiry time of the token, and a signature which will be signed by the server's private key. The client will use the server's public key to validate this token. You can think of this process like a hotel. After the check-in at a hotel, you will get your hotel key which will be related to your identity. You can use this key to access a number of services in the hotel such as restaurants, swimming pools and gym. But you cannot use your key to enter others' rooms. Your hotel key will have the same functionality as the JWT token and those public hotel services will be the same as those web server components. Every time you want to use a service, you need to include your JWT in your HTTP request header which can be used to authenticate your identity. Those services retrieve the public key from the identity server and use it to authenticate the request from the client.

Comparison Of Server Session And Stateless JWT
The JWT we are mainly discussing in this video is the stateless JWT, which means the token doesn't leave any data on the server side. There are also stateful JWT tokens which will work as a combination of JWT and session cookies. Compared with the classic server-side sessions, stateless JWT has a lot of advantages. The first one is Scalability. Due to the fact that there is no session store synchronization within server components, you can easily redirect your users to other server endpoints without worrying about the absence of session data in other servers, making it easy for balancing workloads. Regarding the Maintainability, there is no need for the servers to maintain the session store for sessions, which will make the server maintenance much easier. One of the main shortcomings of stateless JWT is that it is difficult to revoke a token immediately. For example, if a user found that his JWT to access his online bank account was stolen by a hacker and he wanted the bank to revoke that token as soon as possible. Let's say the token is valid for ten minutes or so. If for whatever reason you want to disable that token, in the case of server sessions, you can easily revoke the access , but it might be a difficult job if the server is using stateless JWT to authenticate users because there is no data stored on the server side. Actually, it is a general flaw of almost any stateless session identifiers. You cannot invalidate stateless JWT, but the same goes for stateless cookies etc. If you want to have the control of revoking the token at any time, you have to use the stateful JSON Web Tokens.