Details of the Inquiry
I am in charge of technical security at my company. While talking with a developer, I was told that the JWT Token method, unlike the existing Session method, does not store the JWT on the server. I would like to know how the client is authenticated in that case.
Unlike the Session method, a WT (JSON Web Token) is designed so that the JWT itself contains the authentication and authorization information required. Therefore, unlike traditional Session-based authentication, the server does not need to store the JWT Token separately.
In some cases, however, the JWT is stored on the server for Token Whitelisting or Blacklisting.
Why did the JWT method emerge?
The traditional Session method is stateful, so every client’s session information must be stored on the server (in a database or a cache). Server load is therefore inevitably high. In a Microservice Architecture made up of many Microservices in particular, the Session method raises server load even further, which is why JWT technology came to be used even more actively.
A summary of client identification and authentication under the JWT method…
- Token creation
– When the client requests login, the server verifies the user’s information (ID, password, and so on).
– If authentication succeeds, the server creates a JWT using the user information and the server’s Private Key (or Secret Key).
– When stronger client identification is required, the client’s IP, the browser User Agent, and unique characteristics of the client device are included in the JWT Payload, or client identification is strengthened with a Challenge-Response Authentication mechanism. - Token transmission
– The server generally sends the created JWT to the client in the HTTP Header or the Body. - Token storage
– The client stores the received JWT in a cookie, local storage, session storage, or a similar location. - Token use
– Whenever the client sends a request to the server, it includes the stored JWT in the HTTP Header.
– It is usually sent in the Authorization header. - Token verification
– Each time the server receives a client request, it verifies the JWT included in the Header and checks the Signature portion using the server’s Private Key (or secret key).
– If the JWT Signature is valid, the Payload portion is decoded and the client’s information is checked. The client is identified through this, and the request is processed according to the corresponding permissions.
– The validity period of the token can also be verified through the “exp” (expiration) included in the JWT.
JWT is not stored on the server.
Because a JWT itself contains information that identifies the user, there is no need to store the JWT on the server as with a Session. The server identifies the client by verifying the JWT sent by the client with its own Private Key. From the server’s perspective, measures to strengthen security, such as preventing forgery and tampering of a JWT Token that is outside its control, are therefore essential.
I understand JWT from creation through verification, but there is no revocation?
As in the authentication process above, the server does not store the JWTs it creates, so it cannot revoke them at will. A function similar to revocation can be implemented through Token Whitelisting or Blacklisting, preventing misuse of tokens that are no longer needed or have expired (some products provide this function at the API Gateway).