I’m not sure what you mean by stateless server. The server keeps state regardless of whether you use a session verified by the database or verified by encryption.
I’m not sure what you mean by stateless server. The server keeps state regardless of whether you use a session verified by the database or verified by encryption.
Because the token is generated per request, there is no requirement to revoke the token. Each request is a session in itself. The private payload of the token contains the username if the user was authenticated, else that information is not present in the token. That gives an indication to the server that the request is from already authenticated user.
> There’s no way to logout or invalidate sessions?
A logout request from user will contain the token that was sent in the response to previous request from that user. Because the token is generated per request, the way the server can "invalidate" a session is by simplying logging out the user by removing the username from the next token. If a token is compromised then that will create a problem for that single request because the next token will be different and will be using a new key for encryption.
> I’m not sure what you mean by stateless server.
Stateless means the server does not have to maintain session information.
I don’t follow. What stops a user from replaying any token/request?
Request 1: User sends credentials.
Response 1: Server sends session token encrypted using server’s private key.
Request 2: User sends token from response 1.
Response 2: Server sends a new token, encrypted using server’s private key.
Request 3: User sends token from response 2.
What stops the user from using the token in response 1 multiple times? How does it become invalid?