Why does NextAuth use "JWT sessions" by default?

[Fronix]

Question 💬

I love this library, I use it daily, and it's been great.
But something I've been wondering about is why NextAuth uses JWT tokens and why it uses it as inside a cookie? Isn't this an antipattern? What's the point of having a cookie session with a JWT token inside it?

I don't use JWTs, but I still am curious of why this feature exists, since NextAuth generates its own JWT, and it stores the OAuth token from the provider(s) you sign in from.

How to reproduce ☕️

Some material I've found that explains more about what I'm talking about:
https://www.youtube.com/watch?v=pYeekwv3vC4
http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[balazsorban44]

I won't have the perfect answer here since I am not the original creator, but mostly it comes with the advantage of not having to deal with a database.

There are drawbacks as well as advantages, and we have a F.A.Q section summing things up better I probably could: https://next-auth.js.org/faq#json-web-tokens

I hope that helps.

That said, we do offer "traditional" database persisted sessions, if you need/want that.

[Fronix]

I currently use NextAuth with the "traditional" database cookie sessions.

Yeah, I've read through it all, and I understand the reasoning behind it, but I do feel like NextAuth is very JWT focused. Most issues I see are about JWTs and how to deal with it. When most of the time, the solution is to not use JWT.

I know this is not actually a NextAuth problem, it provides both, and that's the best. But there are strong arguments against using JWTs as login sessions, that's why I wanted to pop up the question and see if there's a discussion going, apart from the FAQ (which I assume was written some time ago)

[balazsorban44]

The general problem is that people probably don't really understand how JWT works, or they confuse their provider's JWT (oftentimes access_token will be one) with the one generated by NextAuth.js, or they don't understand how to handle that token in their third-party apps. (Which is also totally possible, just decode/decrypt that token as you would normally do with any access_token).

This way of handling sessions is not uncommon, https://github.com/auth0/nextjs-auth0 for example uses a similar technique. As said, I think the biggest gain is not having to deal with a database, and generally much faster responses.

We do list the disadvantages, and everyone should decide what they need for their apps. But in most cases, the JWT option will suffice for most of the users IMO.

[balazsorban44]

I've just watched the video (have seen the articles before), and while I won't argue about some of the points, I don't feel that every point they are making is fair/true there.

I am not going to pretend that I'm a security expert, but from experience, I can definitely tell it's easier to start off with a non-DB solution. Given the popularity of these libraries/solutions, if it was SUCH a big concern, I am pretty sure the industry would have caught up.

We do provide DB persisted sessions, so I guess the way of solving this would be to default to database sessions, but that would probably upset way more people than those that are concerned by our current default.

As not being the original creator of next-auth I cannot tell you their reasoning for going with that default, unfortunately.

@iaincollins if you read this and have some thoughts on this, please share them in the docs through a PR https://github.com/nextauthjs/docs

[Fronix]

Yes, usually it's about people not understand how JWTs work, and the industry should really make an effort to make it easier to understand. Currently, there are so many "best practices" regarding JWTs, and it's often confused with OAuth since it usually uses JWTs people think that they have to use them, when in fact they don't.

The video is quite harsh, yes. He makes good points, and not all points are fair! But I do believe that JWT today really are used (more often than not) to reinvent what already exists.

Auth0 does it as well, the difference is that there's a huge company behind that, and I'm guessing there is a lot of work behind making it secure. They effectively remove the requirement of having to learn about authentication, which I think is bad.

NextAuth DB persisted sessions work awesome, they are easy and require no setup at all. And defaulting to it might, as you said, upset a lot of people. But sometimes, maybe the boot is more effective? 😂

I'm also not going to pretend I'm a security expert, I just enjoy learning and understanding things. And authentication is something I enjoy building.

And please, do not take this as any hard critique or anything. I'm just curious and want a peak into others minds and thoughts regarding this topic since I don't have a lot of others to discuss it with.

[balazsorban44]

Thanks, and thank you for the questions! It's totally fine!

If you think this section of the docs: https://next-auth.js.org/faq#what-are-the-disadvantages-of-json-web-tokens is not fair enough, I am happy to accept any PRs. But the best way of going here (in my opinion) is to just wait out so hopefully (several?) security experts would raise a question around this and could either debunk/enforce the "correct" way. next-auth has grown in popularity quite a lot recently, so that should raise eyebrows if we are doing something very wrong.

Until then, I am pretty sure we will just continue recommending either of the solutions and default to JWT session cookies.

[Fronix]

My bad, should have made it a discussion. Forgot that those exist ^^

[iaincollins]

But something I've been wondering about is why NextAuth uses JWT tokens and why it uses it as inside a cookie? Isn't this an antipattern? What's the point of having a cookie session with a JWT token inside it?

I would second what @balazsorban44 has said.

The short answer is that a JWT allows for cheap, fast and highly scalable authentication, because you don't need to maintain a list of all active sessions server side (e.g. in a database, on a file store) and it can be convenient in loosely distributed systems, where different products reading a session are managed by different teams or where different endpoints may be handled by de-coupled code (e.g. serverless functions) and standardized tooling and good documentation is available for it.

There are other ways of designing proprietary solutions that deliver similar benefits (even without some of the drawbacks), but you need to be at the scale of several million concurrently active sessions with strict sub-second latency before that ought to be an issue.

The main tradeoffs to using JWT for sessions include; cookie size is very limited, it increases data traffic slightly (though typically only relevant on mobile devices in limited bandwidth scenarios) and it comes with some conceptual complexity (e.g. reading, signing and how you handle expiring sessions).

If using a JWT as a session token it should be stored as a cookie rather than somewhere like local storage to avoid session hijacking by third party scripts or from exploitation of cross site scripting attacks - and if you want to support clients that do not have JavaScript, or in the event there is a compatibility problem executing client side code (the more common anti-pattern here is to use local storage in an SPA because "it's easier" to store them that way, in practice that's true but it can be a security risk and is a pattern than can lead to interoperability issues).

[balazsorban44]

Probably the best explanation we can give on this thread.

The only thing I think we can do for a more secure default is to encrypt the JWT in the session by default, which if I really correctly was the case before (v2), but was reverted because of the size/calculation-time increase.

I have been approached by security experts though, who recommended that we use encrypted JWT by default anyway and highlight it as a less secure option to not encrypt. We will decide on this before v4 goes to stable I think.