DEV Community

loading...

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

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