29

There are a lot of articles around discussing what is the best place to store JWT on the clientside. In short, they're all about -

  • Http-only secure cookie - no XSS, but vulnarable to XSRF

  • Header (saved in local storage or DOM) - no XSRF, but vulnarable to XSS

I think I come up with an extremely savvy solution to this, but, since I'm complete noob in security I'm not sure if it's really savvy or stupid.

So, what if to split JWT and save part of it in the cookie and another part in the header? Would it be unbreakable?

This should also solve 'logout' problem - deleting header portion would make browser incapable of logging in.

Dharman
  • 30,962
  • 25
  • 85
  • 135
user656449
  • 2,950
  • 2
  • 30
  • 43

1 Answers1

29

The JWT needs to remain together, otherwise the signature validation won't work.

Protecting against XSRF is pretty easy, you just need another cookie.

Never use local storage for storing authentication information, it doesn't follow the same domain and origin rules as cookies. Read more here:

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Storage_APIs

Disclaimer: I work at Stormpath, we have a hosted user management solution and we spend a lot of time on security. I've written two blog posts where I discuss JWTs and front-end auth:

Token Based Authentication for Single Page Apps (SPAs)

https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/

Dharman
  • 30,962
  • 25
  • 85
  • 135
robertjd
  • 4,723
  • 1
  • 25
  • 29
  • 1
    But extra cookie to protect against XSRF means maintaining server side session, right? If so, gluing JWT back together is much simpler and more lightweight. And again, if only some part of JWT stored in local storage, can it be of any value to an attacker? – user656449 Jun 30 '15 at 07:53
  • 3
    @user656449 The CSRF token doesn't need to be stored. During login set a random CSRF cookie, and in JS copy the value into a header. On server-side verify that the cookie and header values match. It relies on the fact that only JS on your own domain can read the cookie value. https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token – Sampo Sep 03 '19 at 16:34