Security goal
Let's take a step back here and ask what security goal we are trying to achieve here. I think with any "login session" system the goal is the same, and comes in two parts:
- Initial login: the user proves that they are who they say they are; this is usually done with passwords, MFA, email confirmations, whatever.
- Maintaining the session: each subsequent request from the client to the server contains some proof that they are the same person that did the initial login, and not an attacker trying to hijack their session and pretend to be them.
The common way of achieving this is that upon successful login (step 1), the server gives the client some sort of long random-looking string (aka "an auth token"), and the client includes it in each subsequent request as the proof for step 2.
I say "common", but I'm not actually aware of any alternatives unless you want to get into TLS client certificates, or pre-shared API keys but those are a lot more effort and are not really "sessions" anymore.
Implementation
There is a lot of variety for what counts as an "auth token", for example:
- JSESSIONID (commonly seen with Tomcat servers)
- custom session cookie
- JWT tokens
- Bearer tokens
- some custom value in the
Authorization: header
Each of these has their own pros and cons. For example if you do JWTs, then you need to worry about securely storing a signing key in the server. Or if you use a session cookie then you also need an XSRF token. But in a broad sense these all follow the pattern of the server issuing a random-looking token upon successful login that the client echos back with each request.
Session management
(Response to comments)
You getting into the complexity of session management. This is getting way outside the scope of a security question, but I'll answer it anyway.
Yes, in order to process a request, the server will need to know "stuff" about the user and their session. For example:
- Username / email
- What group / permissions / access controls they have
- What time they logged in / when their session expires
- Whether they logged in with just password, or with password + MFA (for example if you require "step-up" to access sensitive parts of the app).
- What IP their session is from (maybe you want to enforce geoIP restrictions, or make sure they don't change to an IP halfway around the world part way through their session)
- A lockout-count (for example if you're doing a per-session lockout)
- etc, etc
As this is mostly security stuff, the server needs to be keeping track of this, rather than trusting the client to give the correct information. Debates about where and how the server should store these "session objects" are basically as old as the internet itself. The most common designs are:
- Server-side in memory: could be as simple as global vars in your application, or as complex as an in-memory database that synchronizes across servers. Pros: high performance as no db calls are needed. Cons: can run out of server memory, hard to scale horizontally (adding more copies of your server behind a load balancer), you need to worry about clearing out data when sessions expire.
- Server-side in database: make a db table for tracking sessions. Pros: scales nicely. Cons: slightly worse performance, you need to worry about clearing out data when sessions expire.
- Client-side (aka "stateless): put all the session data into an encrypted JWT (aka "JWE") and get the user to hand it back to you with each request. Pros: high performance, does not consume any memory on the server, scales nicely. Cons: more complex to implement properly, extra bandwidth usage.
As I said, this is an age-old debate, so google something like "server side session management" and you'll get loads of people debating the best way to store session data.
