In the security community, there is a contention on whether an auth token (think OAuth access_token, JSESSIONID, ...) should be stored inside a cookie or if should live within javascript, so e.g. a variable in a single page application, local storage or session storage, etc.
If it is stored in javascript, all requests to resources that require auth have to be made from JS, so it is usually difficult to retrofit an application that was written for cookie-based auth to have it store the auth token in JS.
That being said, for new applications, the developers have to make this decision. Which one is more secure? It is often said that cookies are safer against XSS (with the HttpOnly flag set), but using cookies makes your app more vulnerable to CSRF. Tokens within JS, on the other hand, are easier to exfiltrate through XSS but CSRF therefore becomes much less of a problem.
But why not just combine the two approaches to get the best of both worlds? The web application can split the auth_token into two by doing:
r := random_bytes()
share1 := auth_token XOR r
share2 := r
share1 can then be set as a cookie and share2 as a JS variable. The web frontend then needs to always provide both shares to the backend to authorize a request.
Instead of XOR, other cryptographic operations are possible, but XOR is especially performant and should be easily available in every programming environment.