Implement new session strategy that uses both stateful and stateless tokens.

[nicksrandall]

Problem

As I understand it, Auth.js allow 2 strategies for storing the session: JWT and database.

For the purpose of this discussion, these two strategies can be renamed stateless and stateful respectfully.

Each strategy has its own set of tradeoffs regarding speed and security.

JWT (stateless)

This strategy is fast as it requires no database call, but tokens can not be revoked once granted (and are typically long-lived). This is a security issue when a malicious attacker has gotten ahold of a valid user's token. In this scenario, the only thing that can be done to prevent the attacker from acting on the user's behalf would be to update the token secret globally, which would invalidate every user token and force all your users to log in again.

Database (stateful)

Due to database calls, this strategy has additional latency, but sessions can be revoked individually. If an attacker gets ahold of another user's token, it can be easily remedied by deleting the session in the DB, and the attacker will no longer be able to act on that user's behalf.

Potential solution

IMHO, the optimal approach would be to use both strategies in tandem -- leveraging each for what it is good at.

This dual strategy approach involves setting two cookies for each user: one stateless, short-lived token and another stateful, long-lived token.

When a user requests a protected resource, the stateless (fast) token can validate the user.
Because this stateless token is short-lived (probably less than 15 minutes), it must be regularly refreshed using the stateful token in the background.

The client could implement this process with a global interval (setInterval) that regularly refreshes the backend's stateless token by hitting a refresh endpoint.

The refresh endpoint would validate the stateful token with the database and only then deliver a refreshed stateless token.

Additionally, if the backend receives an expired stateless token with a valid stateful token, it could automatically refresh the stateless token on the user's behalf (this case should be rare because the token is being actively refreshed by the client).

Benefits

Because the stateless token will be used to validate the user, this approach has the benefit of not adding additional latency to the request most of the time. Also, because the token is short-lived and regularly refreshed, the token can be "revoked" by deleting the session in the database, which prevents the token from being refreshed. So the maximum time that an attacker can use a stolen token is just the length of the short-lived token (again, probably just a few minutes).

Proposal

I would love to see if we could implement this "dual" strategy in Auth.js.

[nicksrandall]

FWIW, I know that other auth providers (like Clerk) use this strategy.

[GermanJablo]

I love how well explained your proposal is.

This would be great as it would offer the best of both worlds. Additionally, Auth.js users wouldn't even have to think about auth strategies or which one to use.

For reference, Clerk's article explaining this hybrid approach can be read at: https://clerk.com/blog/future-of-auth-stateless-and-stateful

[DragonOsman]

I'm not a member of the team, but I'm interested in this proposal and am also a user of NextAuth.js, so I'll ask: is this being worked on? I know it was added as a suggestion/idea two years ago now, does that make it too old?