Is serverless authentication possible? (JWT without JWE)

[baba43]

Question 💬

I would like to have a simple and fast way to authenticate users. For this reason, I had previously developed my own solution based on JWT.

The advantage of JWT for me was that no lookup is necessary to know on the client side who is currently logged in and which role he has. This means that my app can load completely from cache and thus would theoretically work offline.

With next-auth, it seems that the session stored in the cookie needs to be resolved or validated on the server side. I always see a request to /api/auth/session before useSession gives me a result. This means that the page loading is unnecessarily delayed (until the request is through) and in the worst case even doesn't work at all (if there was a connection problem, or the user is offline for a short time).

Since I'm just getting into next-auth, my question is whether or not "serverless" authentication using JWT is possible? And if not, if we want to talk about what an appropriate implementation could look like?

If possible, I'd like to omit the roundtrip to the server completely, or if it makes sense from a technical or security point of view, make this request using the "stale-while-invalidate" principle: when there is a local session, it is returned immediately (maybe with an additional status that indicates it is stale), while the session is validated in the background. Of course this function can be opt-in.

Thanks for having this project and for maintaining it.

How to reproduce ☕️

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[balazsorban44]

This is literally the purpose of our library. See the landing page: https://next-auth.js.org/

Built for Serverless, runs anywhere

The check on the backend is necessary for security reasons. If you set everything up correctly, you shouldn't be calling the endpoint every time, since there is a cache mechanism built into the client-side code.

https://next-auth.js.org/getting-started/example

[balazsorban44]

The cache is using React Context. Meaning a manual page refresh will make it so that you are going back to the endpoint to verify that the session is still valid. But this is usually not the case with SPA applications, as page navigations won't reload the page. Thus minimizing the request to the backend to 1 in the lifetime of most user sessions. NextAuth.js re-requests the session when the tab gains focus again, so even after a long amount of time, you can be sure the session is kept in sync.

If you need periodic session validation, check the docs: https://next-auth.js.org/getting-started/client#refetch-interval

Keep in mind that validating/decrypting the JWT is extremely fast as with this strategy, there is no database involved (we do support database persisted sessions as well, with a focus on minimizing database writes to increase speed) the session is saved in an encrypted JWT (JWE) in a Secure, HttpOnly cookie. The secret encrypting the JWT is server-side only and should never be exposed to clients. Thus you must go to the backend to verify the content of the JWT. I really don't see a way around this.

[baba43]

You are right. If I want to encrypt the JWT (which I don't, since it has no significant advantage in terms of security), then I can't get around the request to the server.

I think it would be useful if next-auth could support the use case of classic JWT tokens, but maybe my use case is rarer than I thought.

Anyway, thanks for the time.

[balazsorban44]

Encryption is the new default as it does have a significant impact on security. 😅 We were assisted by security experts on the matter.

You can create your own encode/decode methods though, without encryption at your own risk:

https://next-auth.js.org/configuration/options#jwt

[baba43]

Well, I wouldn't turn off the encryption for fun, but that's the requirement to avoid the request to the server. As long as I can't turn off this request, it doesn't do me any good to disable encryption.

The encryption of JWT only makes sure that someone who steals the key can't read the content. Usually there is no secret data in the JWT, but only e.g. the user ID. Therefore, the impact on security is very limited in reality.

In the end, everyone has to decide for themselves whether they want to use JWT or JWE, because both obviously have advantages and disadvantages. The question now is whether next-auth wants to support JWT (without JWE) or whether there is no need for it.

[balazsorban44]

it is and has been supported forever. see the link above. the only thing that changed is that it's encrypted by default now.