Like some here, I don't understand the hate around keeping tokens in localstorage. People immediately say "but js can read it!" but so what? If someone can put malicious js in my site, it is GAME OVER, secure http-only cookie or not. When that is the case, the saner option is doing away with an old and misused invention called cookies. The upside with ditching cookies is that you are an order of magnitude safer against CSRF since your browser does not send anything automatically. You don't need to keep CSRF token state in your server(s) either (helps with scale, one less state to worry about), it is a win.
http-only secure cookies do not give you any additional security. Ditching cookies does.
Store a security token in localStorage and additionally store a secure signature for it in a secure, HTTP-only cookie. On your backend, verify validity of both the token and its additional signature contained in the cookie.
My actual point stands, the Web Storage API doesn’t offer the same protections as cookies. Don’t store sensitive data in localStorage, that is emphatically not it’s intended use.
And what would those be that are relevant to this discussion? The way we (ab)use cookies is arguably not their intended use either.
I can't think of a scenario in this context where an attacker says "damn he is using http-only cookies, I won't be able to do what I want to do"
The only pragmatic difference between both is js accessibility. That only matters when someone can inject scripts into your site. My point is, when that happens, cookies are also bust.