Hacker News Reader

Comment by jay-barronville | Hacker News Reader

I pretty much agree with the sentiment of this post.

I’ll probably get downvoted for saying this . . .

Ever since using JWT’s became a trend, I’ve found that I can’t get a useful answer almost every single time I’ve asked an engineer (or team) why they picked JWT’s over old, boring, and tested sessions for a web app. It seems, just like React, GraphQL, etc., a lot of the industry just love jumping on bandwagons. I see so many companies adopting the new and shiny thing (or the thing attached to a big name) rather than the best tool for the job. Unless I encounter a specific use case that would be best served using JWT’s, I’ll stick with the “old” Redis sessions model.

I guess you’re not a real engineer nowadays if you can’t say that your new app uses insert buzzword or trendy technology here . . .

View on HN

The use of trusted jwt libraries which outsource registration and authentication has massive benefits such as SSO and reducing the risk of vulnerabilities (user reg/auth being handled by a dedicated party).

There’s no reliance on a database or state management, which can be useful under some conditions.

In my eyes, the problem is reliance of the authorisation header instead of cookies, this has some benefits but is also a massive deviation away from 20 years of websec. Granted all of http spec is a giant nasty hack, so it’s not really jwts fault.

How is your first paragraph a result of using JWT over sessions?

It depends on your definition of session (e.g. if you’re referring to a cookie, or if you’re referring to the use of JSESSIONID or similar). In both cases, JWT is just the token and how and where it’s transferred aren’t spec defined. I susupect the reason for the authorization header to be used is to prevent csrf attacks or to better facilitate SPAs, but I’ve never researched it.

You could technically use SSO with any other auth token, or exchange it during the auth process, but ultimately having metadata about the user in near clear text is useful.

Don’t get me wrong, I think jwt and the rest of websec is a total fucking mess, but jwt is far from the worst offender.

I think the original motivation was tied to when people were trying to build unified APIs for every kind of client: web, mobile, m2m. Cookies and sessions werent always available afaik.

I was under the impression sessions were just arbitrary tokens backed by some server-side logic (or perhaps a database)

At its core isn't it possible to just take an object, encrypt it with a secret, store it client-side somewhere (cookies, localstorage, filesystem, printed-on-paper, whatever), send it back to the server, and it decrypts it?

I don't quite see the difference (or benefits) of JWTs over something like that.

The difference between JWT and session is where the state is stored.

For session, you need a centralized backend to access the data stored in the session. For JWT, you only need to verify the signature of the token to trust the data stored in JWT.

JWT solves the problem of having multiple separated service that need to share data.

Storing state in JWT is easy way to share state, such as user permission, between different server.

But state in JWT can be outdated due to permission changes and you it's not possible to just expire it as it's stored in client.

To solve the problem, more complex auth setup is needed such as using short lived JWT, refresh token, which feels more like a bandaid to make JWT sufficiently secure

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.

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...

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.

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).

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.

I don't think it's a trend or that people are trying to be cool or something. JWT is like a simpleton version of Kerberos/ActiveDirectory tickets. Having authentication and/or authorization independent of operational systems has significant advantages is architecture and deployments.

Reply on news.ycombinator.com