Live data from Hacker News

Authentication with Django and Single Page Apps (2020)

mikesukmanowsky.com

11–20 of 39 posts

Re: Authentication with Django and Single Page Apps (2020)

#11
post #10

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 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 prac…

Claiming that technology A shares the same issues as technology B while technology B is all the hype doesn’t exactly spell out why I should use technology B over technology A.

And this is assuming I actually accept your claim that they share the same issues . . .

Re: Authentication with Django and Single Page Apps (2020)

#13

Earlier quoted context omitted.

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 t…

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.

Re: Authentication with Django and Single Page Apps (2020)

#14

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 se…

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.

Re: Authentication with Django and Single Page Apps (2020)

#15
post #10

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 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 prac…

Claiming that technology A shares the same issues as technology B while technology B is all the hype doesn’t exactly spell out why I should use technology B over technology A. And this is assuming I actually accept your claim that they share the same issues . . .

I think the selling point for JWTs are that they're a mostly-standardized way to do auth tokens such that you only need to do one very simple and cheap database query (is this a token that has been invalidated but hasn't yet expired) rather than a larger number of database round-trips to implement various authorization checks.

Re: Authentication with Django and Single Page Apps (2020)

#16
> JWTs are vulnerable to brute force attacks once intercepted.

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.

Re: Authentication with Django and Single Page Apps (2020)

#17
I personally feel so validated after reading this post. The past 3 weeks have been me personally, painfully re-deriving this information independently.

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.

Re: Authentication with Django and Single Page Apps (2020)

#18
post #5

hahaha, let's go back to 1998 and use cookies and sessions for authentication. 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.

Huh? Sessions and TOTP aren’t mutually exclusive. In fact, they work quite well together. And since when were cookies and sessions 1998-level technology? That’s ridiculous.

Should they have said 1994-level? :P

Re: Authentication with Django and Single Page Apps (2020)

#19
post #10

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 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 prac…

What makes this a bad argument against JWTs rather than a good argument in favor of using built-in features of the platform? I agree that any purported issues with JWTs are solvable, but if you don't need the benefits they bring over sessions, why use them at all?

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.

Post reply on HN