DEV Community

loading...

Discussion on: JSON web tokens are NOT meant for authenticating the same user repeatedly: Use session tokens instead

Collapse
lafayetteduarte profile image
Lafayette Duarte

This article here is quite interesting on the subject
blog.duendesoftware.com/posts/2021...
"It’s not only your own code that must be XSS-proof. It’s also all the frameworks, libraries and NPM packages you are pulling in (as well as their dependencies). And even worse, you have to worry about other people’s code running on your host. The recent work around Spectre attacks against browsers illustrates nicely that there is more to come."

Collapse
stevepryde profile image
Steve Pryde

Fair enough. Thanks for that.

I just think that cookies are a horrible solution and will break for anyone who disables cookies on your site. There's also those awful cookie accept banners that plague the web these days. I'd very much like to get away from these.

The attack vector from npm packages isn't really any different in the browser than on the server. Your server language might not be JS but if you still rely on 3rd party code then the same issue applies to every piece of software. I think webassemby may also mitigate this to a degree in the browser as well.

Thanks for the link though. Very useful.

Thread Thread
stevepryde profile image
Steve Pryde • Edited

Here's another take, and talks about an aspect that I also think is more important - avoiding XSS attacks in the first place: pragmaticwebsecurity.com/articles/...

If you're running untrusted or compromised code in your app, it's basically already game over. All of these approaches such as cookies and web workers seem to be avoiding the real problem and it seems more like security via obscurity (which is no security at all) - hoping the XSS can't find where we put the tokens or our mechanism for retrieving them. Bottom line is that if your application code can do something, then (in all cases I've seen so far) so can the XSS code since it's running in the same space.

I'll continue reading on this because the topic interests me. I'd prefer to see better solutions that focus on eliminating XSS rather than assuming that all browser code is compromised.

Thread Thread
lafayetteduarte profile image
Lafayette Duarte

Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.

identityserver4.readthedocs.io/en/...
I'm yet to try this one

Thread Thread
lafayetteduarte profile image
Lafayette Duarte

Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.

identityserver4.readthedocs.io/en/...
I'm yet to try this one

Forem Open with the Forem app