Silent Authentication Systematically Requiring Consent in SPA - Breaking Token Rotation for oidc-spa Library Users

Get Help
,
1

I’m the maintainer of oidc-spa, a provider-agnostic OIDC client library for single page applications ( Auth0 | OIDC SPA ). I’m reporting a critical issue affecting all Auth0 users of our library where silent authentication has suddenly started systematically requiring consent.

The Problem:
Silent authentication requests previously worked correctly now systematically return consent_required errors, making background token renewal impossible. This breaks the SPA user experience by forcing frequent re-authentication.

Impact Scale:
This isn’t just affecting one application - it’s impacting all users of the oidc-spa library who have chosen Auth0 as their provider. Our library is designed to work with any OIDC-compliant provider using standard flows, and Auth0 was previously working seamlessly.

Configuration Details:

  • SPA applications using Authorization Code Flow with PKCE
  • Custom domain setup (first-party context)
  • Refresh Token Rotation enabled
  • No offline_access scope (intentionally avoiding for security reasons)
  • Provider-agnostic implementation following OIDC standards

What Changed:
The applications were working correctly, then suddenly stopped without any configuration changes on our end. The systematic nature suggests a platform-level change rather than individual configuration issues.

Security Concerns:
The suggested workaround of using offline_access scope is not acceptable for security reasons, as it creates non-expiring refresh tokens in the browser. This fails basic security audits and contradicts security best practices for SPAs.

Broader Impact:
This issue affects the viability of provider-agnostic OIDC implementations with Auth0 and forces users to choose between:

  1. Poor security (long-lived tokens)
  2. Poor UX (frequent re-authentication)
  3. Major architectural changes (implementing BFF pattern)

Has there been a platform change that affected silent authentication behavior? This is impacting multiple applications using standard OIDC flows that should be supported. Any guidance on maintaining both security and usability would be greatly appreciated.