Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authentication with Django and Single Page Apps (2020)

mikesukmanowsky.com

Post reply on HN
Print view View original

31–39 of 39 posts

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

#31

Post by scrollaway »

bayesian_horse wrote: post #28
csomar wrote: post #14

Earlier quoted context omitted.

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…

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.

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

#32

Post by scrollaway »

vhcr wrote: post #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.…

JWTs cannot be invalidated without giving up the main reason why you would use them: reliance on an authentication server for validating sessions.

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

#33

Post by bayesian_horse »

scrollaway wrote: post #31
bayesian_horse wrote: post #28

Earlier quoted context omitted.

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

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

#34

Post by scrollaway »

bayesian_horse wrote: post #33
scrollaway wrote: post #31

Earlier quoted context omitted.

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…

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.

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

#35

Post by MrJohz »

akira2501 wrote: post #24
MrJohz wrote: post #21

Earlier quoted context omitted.

But that's true of session auth as well. The only necessary check is "does this session token exist and have a creation date within the expiry period", which should be a single, fairly quick database query for all but the most extreme "at scale" cases. You should not need multiple round trips to validate that. The main use cases for JWT are: * I want to create a session token that I _never_ want to revalidate against…

> I want to create a session token that I _never_ want to revalidate against a database There's the middle ground as well with a long lived authentication or refresh token and a short lived authorization token. > I want to include role (or other) information directly in the token for the sake of convenience Once I started seriously developing cloud solutions, this became indispensable. It's not just convenient, it di…

A refresh/access token flow definitely can help by reducing the number of long-lived tokens floating around, but it's not really related to the type of token you use. The access token could be a JWT token, but it could also just be an opaque random string, or anything else that's convenient to pass around. It just so happens that reducing the longevity of tokens is useful if you don't want to revalidate tokens against a database.

JWT tokens definitely have their place, I don't want to imply that they're useless. They're a tool with tradeoffs like every other tool we use. But I've seen a lot of projects using them without understanding those tradeoffs, and then creating either very inefficient, overly complex, or subtly insecure applications as a result.

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

#36

Post by hsbauauvhabzb »

scrollaway wrote: post #30
hsbauauvhabzb wrote: post #4

Earlier quoted context omitted.

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

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.

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

#37

Post by msukmanowsky »

The_Amp_Walrus wrote: post #20

is there an implicit assumption that we're operating on the same domain here for the frontend and backend I'm not sure that it's so easily handled if you're working from www.foo.com and api.foo.com

The main assumption is just that you have a single API domain. The fact that the frontend and API may be on different domains doesn't impact this recommendation.

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.

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

#38

Post by msukmanowsky »

josephcsible wrote: post #22

> localStorage or sessionStorage, both of which are 100% insecure. This makes me doubt everything else he says.

I'll admit "100% insecure" is perhaps a bit hyperbolic, but they are insecure from the standpoint that any other script executing on the page can examine the contents of either localStorage or sessionStorage and then try to perform a brute force attack.

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

#39

Post by akajla »

akira2501 wrote: post #24
MrJohz wrote: post #21

Earlier quoted context omitted.

But that's true of session auth as well. The only necessary check is "does this session token exist and have a creation date within the expiry period", which should be a single, fairly quick database query for all but the most extreme "at scale" cases. You should not need multiple round trips to validate that. The main use cases for JWT are: * I want to create a session token that I _never_ want to revalidate against…

> I want to create a session token that I _never_ want to revalidate against a database There's the middle ground as well with a long lived authentication or refresh token and a short lived authorization token. > I want to include role (or other) information directly in the token for the sake of convenience Once I started seriously developing cloud solutions, this became indispensable. It's not just convenient, it di…

> I want to include role (or other) information directly in the token for the sake of convenience

This works up until a certain point. Once you get past simple RBAC to more fine-grained (resource-based) authz, jwts don't scale: https://medium.com/building-carta/authz-cartas-highly-scalab...

Post reply on HN