Not setting session automatically and manually managing session id/cookie?

[hsnoil]

How do I go about properly preventing a session from writing into the database? From what I see when I do an authorization, it writes the session into the database even if the authorization fails. I don't want that, I only want a session when the login succeeds

Also, is it possible for us to manually manage the session id once generated? I want to store the session id inside a JWT/encrypted cookie

Ideally, what I want is this:

Not logged in user = JWT/encrypted cookie session, nothing goes into the database and no database session id

Logged in user = JWT/encrypted cookie session, session id is written into the database and stored in the JWT but expires in 30 minutes, user can still stay logged in on JWT

Logged in user accessing a secure section of the site like changing their email = require database session id login

Admin/Mod user = JWT but always needs database Session id, database session id lasts long but with non-elevated privileges

Admin/Mod user accessing a secure section of the site = needs to do 2FA to elevate privileges before access which lasts for 30 minutes

My thoughts right now is handle the JWT/encrypted cookie session myself, and call axum-login when I need the database session id. For elevating I am thinking of having admin/mod users have 2 user groups, and based on the session upgrade the group

Thoughts/suggestions?

[maxcountryman]

I would strongly advise not to use JWTs this way.

I don't want that, I only want a session when the login succeeds

Existence of a session does not confer the authenticated semantic (nor should it for proper security). This is the purpose of the auth hash, which must be verified on each request. Only when the auth hash is present and verified is the request considered authenticated. You must use AuthSession to manage and inspect the authenticated state: if you don't, all bets are off.

Separately the fact the session is being set might not be intended but regardless it's crucial to understand the above semantic.

Edit: Using the permissions example, we can observe that using an incorrect password and failing to authenticate does not set the session. However, because I cannot overstate the importance of this, the session itself is not the authenticated semantic (this is managed by axum-login within the session as a typed value) so it would be a grave mistake to rely on it as such.

[hsnoil]

I used JWT/secure cookie as a term since I didn't know the official name for it, but the article clarifies the term I am looking for is "stateless session". I am not hung on JWT specifically, all I want is storing data in the cookie for login without hitting the database when not necessary for low risk/non-sensitive parts of the site

I also figured out why a session was being written into the database even though the password was wrong, it was due to "axum_messages" messages.error("Invalid credentials");, is there a reason why the example uses that? It seems like a needless session being created when one can simply pass back a code

[maxcountryman]

The article argues against stateless "sessions" (it refers to them as JWTs) for the reasons outlined therein. Again I would not recommend this approach.

If database overhead is a concern re the session, is there a reason you wouldn't use something like Redis instead? I would also point out that the same article mentions that this is unlikely to be an issue until you reach a very large scale (they use Reddit's as an example).

[hsnoil]

The article says:

As you can see here, it's completely reasonable to combine sessions and JWT tokens - they each have their own purpose, and sometimes you need both. Just don't use JWT for persistent, long-lived data.

And that is precisely what I want to do.

Even the example given of using axum_message to deliver short term messages would have been better off as a stateless than writing to a database or memory store

Also, I will note the article looks at things a bit too simplistically. For one, if you have no control where your software is deployed like shared hosting or vps, then even a medium traffic site would face the load of reddit "relatively"

Then there is latency consideration, as accessing network more often, even the docker loopback has a cost per individual load times

I do plan to use Redis too as a cache server alongside other things like sending only parts of a session needed and not the entire thing when not needed

[maxcountryman]

You are misunderstanding the article: you want to use JWTs as a session mechanism and it is directly against that. The article only suggests using JWTs for non-session use cases (see the end for some examples of where Sven thinks JWTs should be used).

To be clear: This article does not argue that you should never use JWT - just that it isn't suitable as a session mechanism, and that it is dangerous to use it like that.

As for latency, this is simply not something that matters in practice (and I would venture is almost always a premature optimization that isn't backed up by real world observations): I've worked on many web services, some reaching high volumes of traffic, and none of them required "stateless sessions" (some of these sites reached quite significant volumes at peak and didn't even break a sweat). Unless at this very moment your server is going up in flames because of the load sessions are putting on it, it's far too soon to bother designing around. As I mentioned previously, the article also covers this in some detail (showing you the stages of scaling sessions and what's required to do so).

Again I would strongly discourage this.