4 ms·

> You need to implement expiring tokens that are refreshed, otherwise there’s no way to revoke a token. I create a new token for each request. Store expiry tim

by m33k44 6y ago

> You need to implement expiring tokens that are refreshed, otherwise there’s no way to revoke a token. I create a new token for each request. Store expiry time and ephemeral id in the token and the cookie, set a separate ephemeral session cookie. Then on the server side check the expiry time and then cross-check the id stored in the token to the one in the session cookie. And then in response to the request generate a new token with a new id and expiry time. > check the DB to see if the session is still valid I am trying to build a stateless server. But I am trying to understand the advantages and disadvantages of stateless and stateful way of managing web sessions.

alexmingoia 6y ago
So how do you revoke sessions? There’s no way to logout or invalidate sessions? That may be okay for your use case but it means if a session token is ever leaked it can be used presumably forever. I would recommend maintaining a table of active sessions in the DB and periodically checking the client’s session token against that. That way you avoid DB queries on each request (session is verified cryptographically), but every X minutes you check that the session is still valid by asking the DB. 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.
- m33k44 6y ago
  > So how do you revoke sessions? 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.
  - alexmingoia 6y ago
    > 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 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?

by m33k44 6y ago

alexmingoia 6y ago

So how do you revoke sessions? There’s no way to logout or invalidate sessions? That may be okay for your use case but it means if a session token is ever leaked it can be used presumably forever. I would recommend maintaining a table of active sessions in the DB and periodically checking the client’s session token against that. That way you avoid DB queries on each request (session is verified cryptographically), but every X minutes you check that the session is still valid by asking the DB. 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.

m33k44 6y ago
> So how do you revoke sessions? 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.
- alexmingoia 6y ago
  > 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 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?