SPA with Online Refresh Tokens

Server-validated refresh tokens · Immediate revocation · No DPoP (intentional)

Architecture & Token Flow
Online Refresh Tokens flow diagram
Security Implications

Strengths

  • Online Refresh Tokens are bound to the live Auth0 session rather than being an independent long-lived credential — killing the session kills the refresh capability too.
  • Replaces iframe-based silent auth with an actual token exchange, removing a class of third-party-cookie-blocking failures.

Risks & Considerations

  • This capability is still in beta, gated behind a tenant flag. If the flag isn't actually enabled, the client can silently fall back to classic long-lived refresh tokens without an obvious signal.
  • Session-bound tokens are only as strong as Auth0's own internal session-validity check on each refresh — unlike Traditional's revocation, this doesn't depend on the app's own Back-Channel Logout receiver working correctly; the check happens inside Auth0 during the /oauth/token call itself.

Hardening Checklist

  • Explicitly verify the online_refresh_tokens flag is active on the tenant before relying on the session-binding guarantee — don't infer it from client-side behaviour alone.
  • Treat this as reinforcing session revocation, not replacing the need for a sensible max session lifetime.