Alternative JWT auth mechanism?

[iaincollins]

In the thread at vercel/next.js#153 @trandainhan has created a nice JWT implementation.

https://github.com/trandainhan/next.js-example-authentication-with-jwt

It's not suitable for some of the use cases I have - where I need the server to be able to store a Refresh Token from places like Google+ to do operations in the background - but it's a lot less convoluted if you don't need to store data server side or don't want to have to maintain a separate session database.

It's obviously potentially faster and certainly cheaper to scale - and perfect for static websites. With JWT encrypted token payloads are small enough they could all be stored on the server.

To maintain CSRF support without sessions, we'd have to migrate to migrate to an approach like the Double Submit Cookie method (where a CSRF token is created in a cookie and in a value submitted along with each POST request):

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookie

If I add this it would be potentially much simpler and in theory there could still be the option to save user profiles to a database (using optional callbacks).

[iaincollins]

Pull requests with JWT sessions would be great. I appreciate it's a lot of work so seems unlikely, but even if it's only a partial implementation it would be something.

[iaincollins]

While appealing I think there are too many problems using only JWT tokens in practice, especially with oAuth.

For example because it doesn't store the RefreshToken server side, if the resets their local data or uses another browser or computer, then you can't get an updated AccessToken later if you want to make API calls - as APIs like Google+ only return a RefreshToken the first time a user signs in to a new service.

Storing things entirely client side in a JWT token (that is encrypted/decrypted on the server) is okay for some uses cases, but it's very limiting for many scenarios so I'm not going to worry about it now I have published the code for session management in next-auth and next-auth-client.

There is a case for using JWT tokens instead of having a session database (but still having a user database), but that's a slightly more specific use case that has some pitfalls of it's own - and the overhead of having a session database is low in most scenarios (especially as, in this example, it can just be a collection in the same database as the user data).

I'm going to close this issue. If it reopens at all it will probably be an enhancement to next-auth.