security issues in JWT storage

The main argument for local storage seems to be this:

it is easier to protect against XSS than protecting against XSRF

The argument for that is that XSS is supposedly solved by automatic input sanitation, while CSRF is difficult to understand.

The second point may or may not be true, but - as your source states - complete protecting against CSRF is relatively simple. If your application is restful it is simply a matter of checking all POST requests for a CSRF token*.

XSS on the other hand is not that simple. Input sanitation is not the solution, encoding the output is. And the problem is that this encoding depends on context. Different encoding is for example needed if you are in a JavaScript or HTML context.

While some frameworks do provide templating engines with automatic encoding, others do not. And automatic encoding generally only HTML encodes, but does not consider XSS in a JavaScript context. Adding to that that many developers skip the templating engines in some cases and output user inputs directly, I would argue that XSS is more difficult to defend against than CSRF.

_{* This is a bit simplified, and there are other things to consider. HTML injection for example may leak CSRF tokens, and the application may actually use GET requests to change the server state.}

Conclusion

I would disagree that XSS is easier to defend against than CSRF. As this is the main argument for local storage, I would go with the cookie approach. It provides small mitigation for XSS and also has the added benefit of ensuring that relevant data is only send over HTTPS (via the secure cookie attribute).

In my experience as a developer and pen-tester, I would argue that it is probably easier to work with a web development framework that has inbuilt protection against CSRF than it is to have developers correctly protect against XSS. This would suggest Stormpath's solution.

Chances are that you probably want to protect against both attacks anyway.