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