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 . . .
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.
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.
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.
Not sure what "stateful JWT authentication" is supposed to be anyway...
JS FE culture is so fucking obsessed with “modern” instead of what works best.
I am using a very similar stack to the author, but I couldn’t find anything as useful as this post.
I feel like an insane person sifting for information for React. So much SEO spam clogging google over useful content like this article.
As soon as you need multiple services it gets trickier.
I found those libraries that provide React components for authentication less useful. I prefer to store authentication state in a redux store and manipulate it with a vanilla client library ("ts-oidc-client" or the keycloak specific one).
On the linked PDF it says:
> Shorter keys can be brute forced.
Yeah... don't use short keys.
And then also misquotes:
> JWT token cannot be invalidated by itself
JWT _can_ be invalidated, you just need to somehow store the invalidated tokens, depending on the use case this can make sense, since the number of invalidated tokens is going to be way smaller.
> But if we need to send this on every request, we need to persist these credentials somewhere. In a native mobile environments, there are secure options, but on browsers we only have localStorage or sessionStorage, both of which are 100% insecure.
The mobile version is not secure either... You need access to the raw payload, so if the app has a remote code execution vulnerability, the attacker is going to be able to read the token.
Moe important, the list of issues would be the same for a session cookie: if you don't expire the session on the back-end or reflect changes in the user attributes, same issue.
Basically, apply the same best practices for session tokens or JWT token and you'll be fine. You can also put the JWT toke in the cookie, it does not have to be stored in the browser local stroage.
I think the premise of the article, which I wholeheartedly agree with, is that for 95% of software projects developers should choose the simplest implementation necessary to meet the requirements. Sessions come for (almost) free with the framework and most browsers, but JWTs have an additional cost for the problems they solve, which are usually poorly understood upfront.
And this is assuming I actually accept your claim that they share the same issues . . .
This is simplest thing for most cases.
The session authentication that is proposed in the article is also great but has two problems:
* It will be hacky to implement for mobile apps (it should be possible but would not be something I'd like to do, I had tried in the past and remember that I needed to jump to a lot of hoops to "pick" that session cookie)
* The cookies can't be shared between different domains (cookies be shared the same domain or between a parent and child domain, i.e api.example.com can set/get cookies from .example.com).
So you can use the SessionAuthnentication if your frontend and backend share their domain and you know that your API won't ever be used for mobiles apps. On all other cases use TokenAuthentication.
I don't have experience with JWT Authentication, however I know it can be done and is used be various apps f.e baserow: https://gitlab.com/bramw/baserow/-/blob/develop/backend/src/...
For example if you want multiple services or sites to use the same login/token. There is keycloak and django-oidc-provider. Those handle users and tokens for you.
This makes me doubt everything else he says.
I'm not sure that it's so easily handled if you're working from www.foo.com and api.foo.com
If the API tries to set an HTTPS-only session cookie on api.example.com, the client/browser will simply forward cookie that on every request (including requests made on behalf of a user like a frontend calling fetch()). You can try this yourself, or see it happening in the Github example linked in the post.
If you had backend APIs supported by different domains (api1.example.com and api2.example.com), things do get more troublesome. You could still configure the cookie domain for .example.com, but then you're sending the session cookie along with any request to any example.com subdomain.
seriously, use time-based and hmac-based one time passwords. combine them with the user's email, which is a strong guarantee for identity and uniqueness. if the user chooses to use a disposable email, it becomes their problem, not yours.
And since when were cookies and sessions 1998-level technology? That’s ridiculous.
