👋hey Colin. This is an important and nuanced topic. Let's dive in 👇 There’s different types of applications where refresh tokens are used: - Regular Web Applications (eg: PHP/Express/Next.js w/ App Router). These can access cookies server side and will mostly just need a session. If a refresh token is needed, it can be stored in a database, in the session or in an HttpOnly cookie - BFF apps (eg: Next.js w/ Pages): Same - Mobile Apps: Can store refresh tokens in the Keystore where it’s safe - SPAs: related to this SDK There is a recently published BCP related to this: OAuth 2.0 for Browser-Based Applications ietf.org/archive/id/draft-ie… co-authored by @aaronpk from our team. It goes into detail about the various architectural patterns available for JS apps and the attacks that are mitigated with each pattern.. Now, for this specific case: our initial guidance was indeed to not store refresh tokens and instead use what we refer to as Silent Authentication. This leverages the OIDC Authorization Code Flow (with PKCE) + an iframe to renew tokens using a session (this session is stored in an HttpOnly cookie). This works as long as all of your applications (and your Auth0 tenant) are on the same parent domain. Modern browser versions have implemented several kinds of Third Party Cookie blocking which will break this flow when multiple domains are involved. Few examples: 1. car-rental.com interacting with car-rental.auth0.com (seen as third party) 2. dev-car-rental.vercel.app interacting with login.car-rental.com (seen as third party) 3. car-rental.com interacting with login.car-rental.com configured as a custom domain (this is ok, seen as first party) 4. car-rental.com and car-deals.com interacting with login.car-rental.com (car-deals.com is seen as third party). For those scenarios, in which access tokens are needed on the client side, we recommend using refresh tokens as the mechanism to renew tokens. Client side logic running in the browser can be vulnerable to XSS, so we must be extremely careful here. This is why we’ve implemented the guidance from the OAuth 2.0 Security BCP (datatracker.ietf.org/doc/htm…) and OAuth 2.0 for Browser-Based Applications BCP section 6.3.2.3 (ietf.org/archive/id/draft-ie…) related to using refresh tokens on the client side (expiration + rotation). We are also working on introducing token binding, also part of the BCP spec datatracker.ietf.org/doc/htm…, limiting the use of those refresh tokens to the browser they were issued to. As part of that work we can now detect if refresh tokens have been leaked and revoke that refresh token when that is the case. We also wrote a blog post about this at the time auth0.com/blog/securing-sing…. It’s only after we introduced this feature that we could provide guidance to use these from the client side. I think it might be worth clarifying a few things 1. The current OAuth spec doesn't define a session token and we have no concept of it. There’s sessions (which are HttpOnly cookies), id_tokens, access_tokens and refresh tokens. They are very different artifacts and have different uses, limitations and security controls. They should not be conflated in “session tokens”. 2. OWASP talks about session identifiers, not about session tokens (see point 1). github.com/OWASP/CheatSheetS…. We are an OAuth and OIDC Authorization Server and implement the security guidance outlined in the OAuth 2.0 Security BCP to make sure these refresh tokens are protected. 3. React is used in SPAs, Mobile Apps, Server Rendered apps, BFFs. The architecture of the application in which React runs matters. There isn’t a one size fits all for React.