Best way to do Session authentication with quarkus-security?

[andreiverse]

I like the quarkus-security extension and noticed there isn't a built-in way of doing http sessions, not even an extension for easy management of sessions/cookies. I understand quarkus' focus is on micro-services, but nobody is storing session information in memory, they will always be using something like Redis. JWTs are hard to invalidate (can be fixed with refresh tokens and access tokens, which should be stored anyway in a db) and the data from a token will eventually get stale, which can cause security issues.

If I still want to do session based authentication like this, what are my best options?

[quarkus-bot[bot]]

/cc @sberyozkin (security)

[sberyozkin]

Hi, thanks for the query,

In general, a session based authentication term is often mixed up with stateless vs stateful session data storage.
Contrasting, for example, session based authentication vs JWT based authentication is incorrect and misleading.

Session based authentication is always about depending on a cookie as a link between the browser and the server to represent an active user session. It is supported with either a stateful approach where the cookie is a binary pointer into a server-hosted session data, or a stateless approach where the encrypted cookie contains all the session related data.

It is what this is all about, nothing to do with micro services. The use of HTTP session in some Java APIs which is really about the stateful session backup only contributes to the confusion.

Currently, in Quarkus, users have 3 options how to build such systems:

1. Form Based authentication - simple session-based stateless authentication mechanism - the user name is encrypted in the cookie.
2. OpendId Connect mechanism - session based authentication mechanism, stateless by default, but with Redis and DB OIDC state management plugins also shipped, and users being able to register custom state management plugins.
3. Follow Quarkus security architecture and implement whatever session based authentication system they would like to, by registering a custom HttpAutrhenticationMechanism.

Michal, @michalvavrik, I suppose, one thing that we might want to consider, is to let users who do Form Based authentication in option 1, to choose not to store the user name in the encrypted cookie but in the server, similar to what you did for OIDC with Redis/DB... Please consider adding it to your queue, IMHO it is not urgent, but can be useful.

[andreiverse]

Is it possible to contribute with a session method? There might only be needed for the mechanism to be implemented and a session repository interface

[andreiverse]

Just realized the session repository would be complex to implement because it should support different storages (Like Redis)

[michalvavrik]

Michal, @michalvavrik, I suppose, one thing that we might want to consider, is to let users who do Form Based authentication in option 1, to choose not to store the user name in the encrypted cookie but in the server, similar to what you did for OIDC with Redis/DB...

Only advantage I can see is that we wouldn't send the encrypted username. I agree it would be nice to have.

[michalvavrik]

If I still want to do session based authentication like this, what are my best options?

I only judge from this link as I have never tried Micronaut, but I didn't see on that page anything you can't do with the form-based authentication. In fact, it sounds like form-based authentication to me. Session cookie serves just as an identifier so that we don't need to send credentials on every request, there is no other information there. If you need persistent storage, I'd go with OIDC extension as we have redis/db token state managers. But yeah, as Sergey mentioned we don't have other persistent session storage options.

[andreiverse]

I believe implementing this in a modern web app can be troublesome, with session based auth it would go like this:
-> POST /login with username and password in body
<- Server sets Http-Only SESSION cookie
Future client requests to server would include this cookie by the browser automatically

The client does not need to think about how it would store the credentials to send in future requests, risking to store real user credentials insecurely in insecure places

[michalvavrik]

I believe implementing this in a modern web app can be troublesome, with session based auth it would go like this: -> POST /login with username and password in body <- Server sets Http-Only SESSION cookie Future client requests to server would include this cookie by the browser automatically

The client does not need to think about how it would store the credentials to send in future requests, risking to store real user credentials insecurely in insecure places

First, I agree that using something like UUID for a session identifier is more secure. I do not entirely understand what else are you trying to say.

Server sets Http-Only SESSION cookie

you have choice if you want that, I think this is the good one though

Future client requests to server would include this cookie by the browser automatically

that is true for any session not managed on the client side

The client does not need to think about how it would store the credentials to send in future requests

part of the credentials (user principal), you can't authenticate without the password

risking to store real user credentials insecurely in insecure places

I think it the username is stored securely, it is encrypted. We can discuss how strong security it is, and I do not doubt that not sending the username at all is much better.

[sberyozkin]

Right, it is really about stateful vs stateless, the whole session concept is seriously overloaded.

@michalvavrik, you made a good point that the only thing that a form cookie encrypts is a user name, so I'm not sure now it is worth spending time on supporting storing that info on the server, perhaps we should, in case the form session state gets bigger, or if it is a user email and name etc.

Other than that, if @Ladicek 's PR gets eventually completed, users will be able to create stateful sessions in custom mechanisms easily