I pretty much agree with the sentiment of this post.<p>I’ll probably get downvoted for saying this . . .<p>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.<p>I guess you’re not a real engineer nowadays if you can’t say that your new app uses <i>insert buzzword or trendy technology here</i> . . .
I personally feel so validated after reading this post. The past 3 weeks have been me personally, painfully re-deriving this information independently.<p>JS FE culture is so fucking obsessed with “modern” instead of what works best.<p>I am using a very similar stack to the author, but I couldn’t find anything as useful as this post.<p>I feel like an insane person sifting for information for React. So much SEO spam clogging google over useful content like this article.
> JWTs are vulnerable to brute force attacks once intercepted.<p>On the linked PDF it says:<p>> Shorter keys can be brute forced.<p>Yeah... don't use short keys.<p>And then also misquotes:<p>> JWT token cannot be invalidated <i>by itself</i><p>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.<p>> 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.<p>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.
A lot of bad arguments against JWT tokens. These items are definitely something you can address with JWT token:
* expiration date
* invalidation
* change of roles or any significant change in user attributes<p>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.<p>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'd also written an article on token authentication for django: <a href="https://www.spapas.net/2021/08/25/django-token-rest-auth/" rel="nofollow">https://www.spapas.net/2021/08/25/django-token-rest-auth/</a> using the REST Framework's TokenAuthentication.<p>This is simplest thing for most cases.<p>The session authentication that is proposed in the article is also great but has two problems:<p>* 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)<p>* 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).<p>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.<p>I don't have experience with JWT Authentication, however I know it can be done and is used be various apps f.e baserow: <a href="https://gitlab.com/bramw/baserow/-/blob/develop/backend/src/baserow/api/authentication.py#L15" rel="nofollow">https://gitlab.com/bramw/baserow/-/blob/develop/backend/src/...</a>
Now… let’s just cover SAML. How do these methods congrue with SAML? I guess maybe all of this (token, etc…) is issued _after_ a SAML “handshake” is complete?
This works for quite a few simple and not so simple usecases. You should look into using proper oauth2 or oidc when it makes sense to do so.<p>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.
is there an implicit assumption that we're operating on the same domain here for the frontend and backend<p>I'm not sure that it's so easily handled if you're working from www.foo.com and api.foo.com
hahaha, let's go back to 1998 and use cookies and sessions for authentication.<p>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.