
Ask HN: Web developers on this forum, how do you manage user sessions? - m33k44
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?<p>The way I am handling sessions is by embedding an &quot;ephemeral session id&quot; 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 &quot;session id&quot; 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.<p>Do you see problems with this approach?
Are there better ways to handle sessions without storing state on servers?
======
kls
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.

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

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

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

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

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

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

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

~~~
m33k44
> 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 :)

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

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

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

------
explorigin
You might find this article informative:
[https://developer.okta.com/blog/2019/10/17/a-thorough-
introd...](https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-
to-paseto)

