Ask HN: Web developers on this forum, how do you manage user sessions? | Hacker News Reader

Ask HN: Web developers on this forum, how do you manage user sessions?

8 pointsm33k4416 comments

Do you maintain session information on the server or do you use web token and make server state-less? Why did you choose one over the other?

The way I am handling sessions is by embedding an "ephemeral session id" and a username in a web token and having that same id set as a separate cookie. When a request is received by the server then the "session id" embedded in the token is compared with the value stored in that separate cookie. If that matches then the username is extracted from the token. In response to that request, a new session id is generated and a new token is created and the value of a separate cookie is set to this new session id.

Do you see problems with this approach? Are there better ways to handle sessions without storing state on servers?

View on HN

A lot of your auth and session architecture depends on if you are doing a multi-page application or a SPA. If you are doing an SPA, I would just use a JWT and keep it in memory, don't put it in a cookie.

If you are doing a MPA, I would only use a session cookie and set the secure only flag as well as the same origin flag for the cookie. Obviously any auth and session management should be done via TLS (and only allow the last few latest and greatest, don't let the client downgrade you to something that can be exploited), if they compromise TLS we all have bigger problems than the fact that they got your cookie and a user session. If the client is owned by a hack there is not much you can do, as they already have the client, you just have to protect your endpoints from that client exploiting your server for more than that users information or privileged escalation attacks.

But honestly the best thing to do, is not roll your own. Use an existing auth solution. Httpd is pretty hardened and they are plenty of auth solutions for it, if you are using it.

> If you are doing a MPA, I would only use a session cookie and set the secure only flag as well as the same origin flag for the cookie.

I am doing an MPA. I am setting a session cookie, the secure only flag and the origin flag. But I am using JWT to store the ephemeral session id which is then compared on the server-side to the session cookie as a cross-check. A new JWT with new id is created for each request. That way the server remains stateless and the client gets new token back for each request; this token is then used in the next request. The only question I have is what are the disadvantages of doing this i.e. making each request independent of the other requests and then cross-checking the validity of incoming request by comparing id stored in the JWT with the one stored separately in another cookie.

> Httpd is pretty hardened and they are plenty of auth solutions for it, if you are using it.

I am not using httpd.

You need to implement expiring tokens that are refreshed, otherwise there’s no way to revoke a token.

Embed a time stamp in the encrypted token, extract the time stamp and if it’s been longer than X minutes check the DB to see if the session is still valid, and if so issue a new token.

Otherwise a leaked token is good forever.

> 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.

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.

> 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.

> 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?

Can you use something tried and tested over something custom?

It's common for people to suggest not inventing your own hashing algorithm because you'll likely make a mistake and open yourself up to security exploits - I'd go further and say don't write your own login system at all if you don't have to.

> I'd go further and say don't write your own login system at all if you don't have to.

Do you mean login using google, facebook etc?

I don't want to use third-party login services. Are there any pre-built self-hosted systems for this?

> Do you mean login using google, facebook etc?

I mean logins, passwords, password recovery, sessions, user roles etc.

> I don't want to use third-party login services. Are there any pre-built self-hosted systems for this?

If there's a specific language or framework you're using (e.g. Django, Laravel), look for the standard battle tested solution that everyone else is using.

You're just asking for trouble implementing this yourself. I wouldn't discount a third party service either.

I think more context is needed to understand what your web application does. When you say web token, I assume you mean JWT, which uses a process of encoding/decoding and can be hacked.

If an attacker can interfere with the JWT/cookie on the client and change the user id they can become any user on your system.

Don't put any user info on the client (JWT/cookie page rendered stuff is fine), just a hash that refers to the session id. This would make it harder for someone to change ids or guess usernames. And use HTTPS for all traffic.

Its okay to use lightweight sessions, a hash for the session id and a user id in a sessions table on the server should be enough to keep track of who is who.

Most web frameworks have this problem solved so maybe look into that for whatever language you are using (unless this is a comp-sci quiz question testing your understanding of sessions/security, haha).

> I assume you mean JWT

Yes.

> JWT/cookie page rendered stuff is fine

Please could you elaborate on this?

> And use HTTPS for all traffic.

Yes, that is done.

> unless this is a comp-sci quiz question testing your understanding of sessions/security, haha

No it is not :)

What I meant was don't put identifiable user information (ids, email addresses, etc.) on the client in a JWT or cookie and use that as a session identifier. If the JWT or cookie gets hacked then someone can impersonate anyone on your system.

Putting their info (email, name, etc.) on a user profile type of page should be fine if your app has a need to do that.

I am just storing ephemeral id and username in JWT and put the encrypted id in a separate cookie.

I make it to not need session IDs; for logins, I use the HTTP authentication (no cookies).

You might find this article informative: https://developer.okta.com/blog/2019/10/17/a-thorough-introd...

Reply on news.ycombinator.com