Details of the inquiry
I have heard that, unlike the session method, the JWT token method does not store the generated JWT on the server.
If so, how does the server identify a client that is allowed access, and how is the token later revoked?
If the session method is one in which the server creates and stores a session, sends it to the client, and then, when the client makes a request, compares the two values to identify whether the client is allowed,
the JWT token method is different. After the authentication process, the server uses the client’s information and its own Private key to create a token and only sends it to the client; the server does not store it. When the client makes a request, the server identifies whether the client is allowed by checking whether the JWT that was sent is a token issued with its own Private key. It should help to understand that process from a lifecycle perspective, from the stage at which the client logs in to a typical web application service through whether the server identifies the client.
1. User login and JWT token issuance
The user sends a login request to the web application using authentication information (for example, an ID and a password). The server verifies the user’s authentication information (for example, an ID and a password).
If authentication succeeds, the server creates a JWT using the logged-in user’s information and the server’s Private key. The server sends the created JWT token to the client.
2. Storing the JWT token on the client
In general, the server does not separately store the JWT token it has issued, except for special purposes such as blacklisting and reuse.
The client, however, must use the JWT the server sent, so it stores the JWT in a safe store and by a safe method, such as a browser cookie, session storage, or local storage.
3. Using the JWT token on the client
When the client sends a request to the server, it includes the JWT it has stored in the HTTP header and transmits it to the server. In most cases it is sent in the “Authorization” and “WWW-Authenticate” header fields in the form “Bearer [token]”.
4. Verifying the JWT token on the server
When the client makes a request, the server verifies the JWT in the HTTP header. In this process it checks the Signature portion with the server’s Private key to verify that the JWT is one it issued. If the JWT Signature verification result is valid, the Payload portion can be decoded and the client’s information can be confirmed. In this way the server identifies the client and processes the request according to that client’s privileges. It also verifies whether the JWT token sent by the client is valid by checking the token expiration time “exp” value set in the JWT, or whether it exists on a blacklist.
5. JWT token expiration and reissuance
When the JWT token reaches its expiration, the client can be issued a new JWT through a mechanism such as a “Refresh Token”. If one thinks of the lifecycle from creation to revocation as with a traditional session, the JWT token method stores the token on the client rather than on the server, so there is no revocation stage implemented on the server.
What takes the place of that function is implementing an “exp” setting and a token blacklisting function. It is common to use an in-memory database such as Redis to implement blacklisting. It is possible to implement a function that stores every token in Redis whenever it is created and later revokes it, but this method runs counter to the purpose of using JWT, so it is not a recommended method.
Therefore, by using an expiration period set with “exp” and a blacklisting function, expired JWT tokens, or JWT tokens that are no longer valid because of logout or a similar event, must be kept from being abused by a malicious user.