Beginner concerns when using the servant-auth-server package

I'm looking for a simple way of handling authentication using servant like this:
1. User submits credentials to login
2. User now has access to protected endpoints

The two ways of achieving this as far as I'm aware of is:
1. Use session ids and store the session data server-sided
2. Use JWTs to store the user's data client-sided

Now when it comes to the servant ecosystem, it appears there's no simple built-in solution for managing server-sided session.
This would be my preference, as my current requirements is to only have one instance of our backend server.
JWTs make sense in micro-services since it's stateless, but it seems way too over-kill for our use-case.

I'm not going to roll out own authentication though since I'm not a security expert. I decided to look into ``servant-auth-server`` and played around with it.

Here are things I'm concerned about:
- By default, generated JWTs have no expiry date. If the token is compromised, a bad actor could use this token forever
- There's no refresh tokens. @and-pete explained in #1527 that, from my understanding, ``servant-auth-server`` handles the lifecycle of the JWT through the cookie's expiry date.

Of course the simple solution to the former is to set an expiry date myself. The issue with this now is that if I set the JWT's expiry date to be short-lived (e.g. 15 minutes), users on my website will be forced to login again after 15 minutes.
Even if the cookie extends its expiration, the JWT is expired. If I leave the JWT to be long-lived, then I'm back to square 1.

If I were to add a refresh token endpoint, the ``Auth`` combinator seems like it'd have conflicts (in theory), due to it sending that ``JWT-Cookie`` by itself every time you send a request to a protected endpoint.

What should I do in my situation? I'd appreciate any feedback, as I don't want to have any potential security issues from misunderstanding how to use this library. Thanks in advance!