I'm currently implementing a REST Api for a Single Page Application and Mobile App. Any 3rd party login or grant access to them is not required. I've microservices behind a gateway (all HTTPS). My current design is as follows:

POST username/password to /session. This generates two tokens, SessionToken (7 days exp), AccessToken(15 min exp). The SessionToken contains a UUID that is saved in the database (so user can see all his active sessions and blacklist if needed). Tokens are set as an HTTP Only, Secure, Same-Site Cookie.

Why AccessToken? The charm is that I only hit the database once every 15 minutes to verify that the SessionToken wasn't blacklisted. And the user_id for lookups is contained in the token.

The SessionToken is extended every time a new access token is requested, so it will only be invalid when it wasn't used for 7 days or it was blacklisted.

Basically I want sessions that do not hit the database for EVERY request. So each microservice can validate the JWT and know it is user x performing the request.

Is this an acceptable approach?

  • 1
    1. Dont use JWT for session, it is not meant for that purpose (more data sent to the server, etc); 2. Session must! be checked on every request.
    – Kaymaz
    Commented Sep 3, 2020 at 18:51
  • @Kaymaz: Why? JWT has no purpose specified. It's allowing me to share data (here userid + claims). Few more KB send to each microservice is a worthy trade-off for 1 db hit every 15 minutes instead of one per request.
    – Regyn
    Commented Sep 4, 2020 at 10:17
  • "Why AccessToken? The charm is that I only hit the database once every 15 minutes to verify that the SessionToken wasn't blacklisted." This suggests that there is a trade-off wherein the user can act for 14 minutes and 59 seconds after their token is blacklisted? 15 minutes of potentially-malicious activity after an intentional action has been taken to revoke access (blacklisting) in return for savings of a few KB per request seems like the wrong priority from a security perspective.
    – msanford
    Commented May 26, 2022 at 16:40

1 Answer 1


Yeah, it sound like a fairly common design used to get revokable tokens but still not have to hit the database on every request. In this pattern, the more long lived session token is sometimes called a refreash token.

There are always discussions about where to store your JWT:s, but using cookies in the way you do is perfectly fine.

As always, the devil is in the implementations. Just because the basic idea is sound doesn't mean your implementation is. A few things to consider:

  • Since you are using cookies, you will need CSRF protection. Just the same-site flag is not enough.
  • Make sure you use your JWT:s correctly. Be aware of the unsigned JWT, etc., etc.
  • Test that you can't mix access and session tokens for different users.
  • Probably something more...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .