Options for token storage and refresh in SPAs

Question

I've been reading Aaron Parecki's draft of browser-based apps' (meaning SPAs like those developed with React or Angular) authentication best practices with OAuth 2 as well as OWASP security guidelines, and it left me really confused:

1. The draft of the RFC mentions rotating refresh tokens. Now how would I do that while adhering to stateless constraint of REST? Do I include some digest of a random string in the cookie and the refresh token as well and check if they are equal?
2. What is the correct way (or rather, some of the more secure ways) of storing refresh tokens in the browser? I've checked okta's JS auth library, and it uses localStorage by default, which OWASP guidelines recommend against. Does it have some kind of extra protection? Should I put some extra digest in it and also put it in a cookie and match them?
3. OWASP recommends session IDs should be completely opaque to the client, but if we use JWT, doesn't it violate this principle? Does this mean I should always encrypt my JWTs with a symmetric cipher?

Some references:

• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-04#section-4
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.md
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md

Answer 1

TRADITIONAL SPA FLOW

In the traditional SPA flow it was standard to use iframes to silently renew tokens.

Meanwhile access tokens were best stored only in memory and should also be short lived. There were still threats of capturing tokens in transit, some of which are explored in this post of mine.

2021 UPDATE

There are two big changes to browswrs that are related to SPA token refresh:

• Browsers drop third party cookies aggressively, meaning that traditional SPA token refresh no longer work reliably (eg in the Safari browser)

• Browser cookies security has become stronger via SameSite=strict cookies, and concerns about XSS threats (video) have increased

BACK END FOR FRONT END

So it is now recommended to store refresh tokens in HTTP only encrypted SameSite=strict cookies. This is best done in an API driven manner, to avoid impacting the web architecture. See this blog post for some up-to-date best practices and links to resources including a React code example.