3

I'm developing a single-page-app that interacts with an oAuth based service. This service grants JWT tokens (refresh and access) for a lot of resources. Potentially the number of tokens can be anywhere between 2 and 100.

My question is- where should I store those tokens?

  • Cookies has a size limit of 4KB, and each token is roughly 1KB, so that's a no go.
  • Session storage solves that problem but is exposed to XSS, and will not persist if the user opens a new tab of my app.

Is there a best practice here? Is there a way to utilize session storage but keep it more secure somehow?

1 Answer 1

2

First thought is that it does seem to be quite a lot of tokens and it does beg the question if it's indeed a requirement for the authorization server to issue so many specific tokens or if less tokens with more broader applicability could suffice.

However, focusing on your question...

Besides the sessionStorage there is also localStorage which would tackle the issue of sharing between multiple tabs.

As you correctly pointed out, storing between cookies and web storage does present different security challenges, one being, that web storage is vulnerable to XSS while an HTTP-only cookie is not. However, a HTTP-only cookie used for authentication is vulnerable to CSRF because it's automatically included by the browser, while a token stored in web storage is not.

At the days end, choosing the right storage is choosing the pros and cons that best adjust to your specific scenario. For a better idea on the impact of your choices check this answer on StackOverflow. It covers the pros and cons of the following options:

  • Option 1 - Web Storage (localStorage or sessionStorage)
  • Option 2 - HTTP-only cookie
  • Option 3 - Javascript accessible cookie ignored by server-side

For the ones that don't follow links, I include the conclusions part inline:

My recommendation for most common scenarios would be to go with Option 1, mostly because:

  • If you create a Web application you need to deal with XSS; always, independently of where you store your tokens
  • If you don't use cookie-based authentication CSRF should not even pop up on your radar so it's one less thing to worry about

Also note that the cookie based options are also quite different, for Option 3 cookies are used purely as a storage mechanism so it's almost as if it was an implementation detail of the client-side. However, Option 2 means a more traditional way of dealing with authentication; for a further read on this cookies vs token thing you may find this article interesting: Cookies vs Tokens: The Definitive Guide.

Finally, none of the options mention it, but use of HTTPS is mandatory of course, which would mean cookies should be created appropriately to take that in consideration.

2
  • I've marked this answer as correct, though it does not present a solution, since as João mentioned- there is a tradeoff with each option, and one should consider all pros and cons. Thanks @João Angelo!
    – Nir Smadar
    Commented Dec 7, 2016 at 19:09
  • I am struggling with the same problem. I think the best solution for my case would be option 1 + data obfuscation + minimized javascript. JS will "encrypt" the data in the localStorage and "decrypt" it when needed. An attacker who successfully manages an XSS attack has to decyper the minimized JS. Another barrier for the attacker. Maybe something like this
    – DoubleVoid
    Commented Nov 13, 2018 at 23:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .