[csomar]

Is this really about buzzwords or a lack of understanding of the technology choices?

Django Sessions is equivalent to stateful JWT authentication. Your choice of using one over the other depends on your constraints. But if I needed a session's based solution, I'd probably go with a stateful JWT implementation rather than Django own session. That is unless I am building a really basic app, and looking to get done with it by the next week.

[bayesian_horse]

There is no reason to use JWT in this case. Because you trust your session store, right? The only benefit of JWT is when you can't trust the "hands" the token passed through. Otherwise just use JSON...

Not sure what "stateful JWT authentication" is supposed to be anyway...

[scrollaway]

I think I can kind of understand one advantage of using state-backed JWTs, if I got the idea right: double validation, both client and server side. So client side you get immediate validation of regular expiry and various other attributes without contacting the server. There’s a slight performance boost for the server in some circumstances, traded for always more client side work.

[bayesian_horse]

JWT is nothing but a signed JSON. You only sign it because you need some entity to trust it without asking another server. If you need to ask another server, you don't need JWT. And that's what the Django session store is doing. The data isn't stored on the client side.

Another option is a signed or encrypted cookie containing whatever you want it to store. That is similar to a session store but stored on the client side and quite limited in size. Again, that's not really JWT, but you may use a JWT as a cookie if you have to. But JWT isn't encrypted (by default).

[scrollaway]

I understand what JWT is and I also don’t think it makes much sense to use them in a situation where you’re going to store them as is in the db. I’m just giving an example of what it could bring to the table if you did. Devils advocate and all.