# Silent Authentication Systematically Requiring Consent in SPA - Breaking Token Rotation for oidc-spa Library Users **URL:** \ **Category:** Get Help\ **Tags:** consent, application\ **Created:** [July 11, 2026, 5:10pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575 "2026-07-11T17:10:18Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![garronej](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/garronej/32/80027_2.png) [@garronej](https://community.auth0.com/u/garronej)\ **Post date:** [July 11, 2026, 5:10pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/1 "2026-07-11T17:10:19Z")
I’m the maintainer of oidc-spa, a provider-agnostic OIDC client library for single page applications ( [Auth0 | OIDC SPA](https://docs.oidc-spa.dev/providers-configuration/auth0) ). 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. ---
**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\ **Post date:** [July 13, 2026, 3:41pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/3 "2026-07-13T15:41:01Z")
Hi @garronej Welcome to the Auth0 Community! According to Auth0 documentation, the `consent_required` error during silent authentication (`prompt=none`) occurs when **the user was logged in at Auth0, but needs to give consent to authorize the application**. This can happen when the application is requesting scopes or permissions that require explicit user consent, and silent authentication cannot proceed without user interaction. The systematic `consent_required` errors during silent authentication are most likely stemming from the limitations of iframe-based session checks in modern browsers, compounded by how Auth0 specifically issues refresh tokens. To utilize your enabled Refresh Token Rotation (RTR) and resolve this without compromising security, you **must** request the `offline_access` scope. Fortunately, Auth0’s implementation of RTR for SPAs allows you to enforce strict expiration limits on these tokens, directly addressing your valid security concerns regarding non-expiring credentials in the browser. There are two intersecting concepts at play here regarding OIDC standards, Auth0’s architecture, and browser security: 1. **The Brittle Nature of Silent Auth (prompt=none)**: Even with a Custom Domain (first-party context), modern browsers are increasingly aggressive with cookie partitioning, Intelligent Tracking Prevention (ITP), and strict cross-origin policies. If the browser blocks or drops the Auth0 session cookie within the hidden iframe used for silent authentication, Auth0 cannot verify the session and will default to requiring user interaction, often surfacing as a `consent_required` or `login_required` error. 2. **The** `offline_access` **Misconception in Auth0** : You mentioned that Refresh Token Rotation is enabled, but the `offline_access` scope is intentionally omitted for security. In Auth0’s OIDC implementation, **a refresh token will not be issued unless the** `offline_access` **scope is explicitly requested in the authorization flow**. ## **[Solution]** To restore a seamless background token renewal experience while satisfying stringent security audits, you should bridge the gap between RTR and the `offline_access` scope using strict configurations. 1. **Request the** `offline_access` **Scope** Update the `oidc-spa` library configuration for Auth0 to include `offline_access` in the scope array. This is the required trigger for Auth0 to dispense a rotating refresh token to the SPA. 2. **Enforce Strict Refresh Token Lifetimes** To satisfy security audits and ensure tokens are not long-lived, you can (and should) configure aggressive expiration policies. Instruct your Auth0 users to configure their SPA settings in the Auth0 Dashboard: 3. **Verify API Consent Settings** Just to be absolutely certain that backend configurations aren’t forcing the consent screen: ensure that the API (Audience) your SPA is requesting access to has the **“Allow Skipping User Consent”** toggle enabled (Dashboard \> Applications \> APIs \> Settings). Since you are on a custom domain, first-party applications should inherently skip consent, but this setting guarantees it. In summary: 1. **Understand** that Auth0’s **silent authentication** using `prompt=none` requires that the user already has an active Auth0 session and that no new consent is required, because `prompt=none` explicitly forbids user interaction. 2. **Recognize** that **Refresh Token Rotation** in Auth0 is documented as requiring the **`offline_access`** scope to function, because Auth0 documentation states: “You must enable offline access and request the offline access scope in the client SDK.” 3. **Note** that without the **`offline_access`** scope, Auth0 may not issue a refresh token, and subsequent silent authentication attempts may fail with `consent_required` if the authorization server interprets the request as requiring new consent. 4. **Review** the [Auth0 documentation on configuring silent authentication](https://auth0.com/docs/authenticate/login/configure-silent-authentication), which explicitly lists `consent_required` as a possible error when “the user was logged in at Auth0, but needs to give consent to authorize the application.” 5. **Check** your tenant-level **Log In Session Management** settings, specifically the **Require log in after** timeout setting, because Auth0 support guidance indicates that session expiration can trigger consent requirements during silent authentication attempts. 6. **Consider** that a platform change to Auth0’s session or consent handling may have occurred, but the documented behavior requires either the `offline_access` scope for refresh token rotation or acceptance that `prompt=none` will fail when consent is needed. 7. **Evaluate** the Backend-for-Frontend (BFF) pattern as the recommended security-first approach for SPAs, because it avoids storing tokens in the browser and eliminates the need to choose between security and silent authentication reliability. Kind Regards, Nik ---
**Author:** ![garronej](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/garronej/32/80027_2.png) [@garronej](https://community.auth0.com/u/garronej)\ **Post date:** [July 16, 2026, 3:32am UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/4 "2026-07-16T03:32:38Z")
Hello @nik.baleca, Thank you very much for taking the time to respond and for pointing me to the relevant documentation. I think I now understand _what_ Auth0 is doing, but I’d still like to understand _why_ it behaves this way. I think we’re discussing two different issues. Browser restrictions around third-party cookies, iframe-based authentication, and Refresh Token Rotation are all important topics, but they aren’t related to the behavior I was reporting. The behavior I was describing is the following: - The SPA requests an authorization code for a first-party API. - “Allow Skipping User Consent” is enabled. - There is an active Auth0 session (the session cookies are present and accepted by Auth0). Yet Auth0 still displays the following confirmation dialog on every authorization request: > Hi Joseph Garrone, > > oidc-spa-example is requesting access to your dev-r2h8076n6dns3d4y account. > > [Decline] [Accept] The key piece of documentation I had missed is this: > Even when consent is skipped for first-party applications, a login confirmation prompt may still appear when the application uses a non-verifiable callback URI (such as localhost or a custom URI scheme). This protects users against application impersonation on the same device. > **[​Skip consent for first-party applications - User Consent and Third-Party...](https://auth0.com/docs/get-started/applications/third-party-applications/user-consent-and-third-party-applications#skip-consent-for-first-party-applications)** > > Developers | Learn how Auth0 handles user consent when applications request access to APIs on the user's behalf. After deploying exactly the same application to a production environment (using a same-site custom Auth0 domain), everything behaves exactly as expected: - No consent dialog is shown. - Silent authentication works correctly. - Session restoration works correctly. So this isn’t a production issue after all. However, I still think this behavior creates a significant amount of friction during development. Concretely, every time a developer reloads the application—which happens constantly while writing code, they have to approve the exact same confirmation dialog again. It also makes the development experience fundamentally different from production. I now have to explain to every `oidc-spa` user: > “Don’t worry, on localhost you’ll have to approve this dialog over and over again, and silent session restoration won’t work. Once you deploy your application, everything will behave differently.” This is surprisingly difficult to explain to developers who are learning OIDC because the application behaves correctly only after deployment. More generally, I find the confirmation dialog itself difficult to justify from a user experience perspective. Technically, I understand what is happening. The SPA is the OAuth client, while the backend is a resource server. The authorization server is therefore asking the user whether they authorize the client to obtain an access token for that API. But for a first-party application, this distinction is purely an implementation detail. The user isn’t authorizing a third-party service. They’re simply using one application provided by one organization. Whether the OIDC client runs in the browser or on a backend, whether the architecture consists of one service or ten microservices, is completely irrelevant to them. From the user’s perspective, the dialog effectively says: > “You just signed in to this application. Do you allow this application to access your account?” The only sensible answer is “Yes.” Declining simply prevents the application they intentionally opened from functioning. As a result, the dialog doesn’t help users make an informed security decision. Instead, it teaches them to mechanically click “Accept” every time they see it. That’s generally considered poor UX for security prompts. So I have two genuine questions: - Why is explicit user confirmation required at all when a first-party SPA requests an access token for a first-party API? - Is there any way to disable this confirmation dialog on `localhost` during development? It would significantly improve the developer experience while still allowing developers to exercise the exact same authorization flow they will use in production. Thank you again for your help. ---
**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\ **Post date:** [July 24, 2026, 3:57pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/5 "2026-07-24T15:57:12Z")
Hi again! I am sorry for the delayed response. In order to answer your questions: The root cause of this could be your web browser. Your browser has likely enabled strict **Third-Party Cookie Blocking**. This browser option breaks the hidden iframe mechanism Auth0 uses to silently restore your session on `localhost` . Because the silent session restoration fails, your app forces a full, interactive login on every reload. The consent screen is appearing because Auth0 has a hardcoded security rule: applications running on `localhost` are _never_ allowed to silently skip user consent. [OFFICIAL WORKAROUND] In order to skip the localhost consent screen on your development environments: **OPTION 1:** - **In Chrome:** Navigate to `chrome://settings/trackingProtection` (or `chrome://settings/cookies` ) and either disable tracking protection temporarily or add `[*.]auth0.com` to the list of sites allowed to use third-party cookies. **OPTION 2:** - Since third-party cookies are going away permanently across all browsers, the modern best practice is to stop relying on the hidden iframe entirely by using **Refresh Token Rotation**. 1. In your Auth0 Dashboard, go to your Application settings and enable **Refresh Token Rotation**. 2. In your SPA codebase (if using `@auth0/auth0-react` or `@auth0/auth0-spa-js` ), update your Auth0Provider/Client configuration to include: ```auto useRefreshTokens: true, cacheLocation: 'localstorage' ``` This allows the SDK to save a rotating refresh token in your browser’s local storage, surviving page reloads without ever needing to rely on third-party cookies. - If you implement Refresh Tokens but _still_ want to eliminate the consent screen on your very first local login, you must stop using `localhost` . Kind Regards, Nik ---
**Author:** ![garronej](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/garronej/32/80027_2.png) [@garronej](https://community.auth0.com/u/garronej)\ **Post date:** [July 28, 2026, 8:51am UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/6 "2026-07-28T08:51:51Z")
Hello @nik.baleca, I’d like to clarify that this is product feedback from the maintainer of an OpenID Connect client, rather than a support question about cookies, iframes, or refresh-token rotation. The unresolved issue is: > Auth0 provides no way for a first-party SPA running on `localhost` to silently obtain tokens for its first-party API without repeatedly displaying a confirmation prompt. The suggested workaround, persisting refresh tokens in `localStorage`, reduces the frequency of the prompt, but weakens the application’s security posture. Tokens stored there are accessible to any JavaScript executing in the application, increasing their exposure to both XSS vulnerabilities and compromised third-party dependencies or supply-chain attacks. This is not an acceptable solution for applications whose security requirements call for in-memory token storage. This creates an unfortunate incentive: developers must either accept a development experience that differs significantly from production or persist credentials less securely. Could you please escalate this product gap to the Auth0 engineering team? Ideally, Auth0 would provide a secure way for explicitly configured first-party SPAs and APIs to skip this prompt on `localhost`. If it is escalated, a tracking reference or confirmation would be greatly appreciated. Since the currently marked solution explains the behavior but does not address this concern, I also suggest unmarking it as the solution. Best, Joseph ---
**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\ **Post date:** [August 3, 2026, 7:13pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/7 "2026-08-03T19:13:36Z")
Hi again. I am sorry for the delayed response as I have been out of office. I understand the frustration this is causing for your development cycle and that having two separate environments is not ideal. There are two major architectural forces causing these systematic `consent_required` errors: 1. **Aggressive Browser Security Policies (ITP & Partitioning):** Silent authentication (`prompt=none`) inherently relies on the browser being able to send Auth0’s session cookie within a hidden iframe. Even if you use a **Custom Domain** (to simulate a first-party context), modern browsers (specifically Safari’s ITP and Chrome’s Privacy Sandbox) aggressively partition, block, or drop third-party cookies inside iframes. If the browser blocks the session cookie, Auth0 cannot silently verify the session, so it aborts the silent request and returns a `consent_required` or `login_required` error. 1. **Strict OIDC Scope Specifications:** According to the OIDC specification, `prompt=none` explicitly forbids any user interaction (no login prompts, and crucially, **no consent screens** ). If the application requests any scope that requires user consent (even if it’s just a custom API audience, or if the user has not yet explicitly checked the box to authorize the client), Auth0 cannot proceed silently and must yield a `consent_required` error. To resolve this issue without breaking the user experience or compromising your security posture, the official recommendation is implementing the following changes: #### \*\*Transition from Silent Auth to Refresh Token Rotation (RTR) 1. RTR is the modern, secure standard for handling session persistence in SPAs without relying on brittle, iframe-based silent authentication. 2. **The Fix:** Enable **Refresh Token Rotation (RTR)** in your Auth0 Dashboard (under **Applications \> Your SPA \> Refresh Token Behavior** ). 3. **The Scope:** Ensure your SPA requests the `offline_access` scope in its authorization requests. - _Security Note:_ While requesting `offline_access` traditionally meant getting a non-expiring credential (which understandably concerns security teams), **Auth0’s RTR implementation mitigates this danger entirely**. RTR enforces strict expiration limits, uses one-time-use refresh tokens, and automatically invalidates the entire token family if reuse is detected. #### **Verify Your “Allow Skipping User Consent” Dashboard Setting** If you are querying a custom API, Auth0 will systematically prompt for consent unless explicitly told not to. 1. Go to your **Auth0 Dashboard \> Applications \> APIs** and select your custom API. 2. Ensure that the **Allow Skipping User Consent** toggle is **Enabled**. 3. _(Note: If you are running your development environment on_ `localhost`\*, Auth0 will always require user consent for security reasons\*\*. 4. You can bypass this during local testing by mapping\* `localhost` _to a local domain name in your_ `/etc/hosts` _file, e.g.,_ `127.0.0.1 myapp.local`_)._ In the present situation where you are experiencing issues with the consent screen being prompted in a local environment, the second option is the official workaround in order to mitigate the issue without relying on the refresh tokens being stored in the `localStorage` in the development environment. The recommendation offered in the previous post was only for the development environment and not a production one in order to not expose the application to the risks as the XSS vulnerability, compromised third-party dependencies or supply-chain attacks. Kind Regards, Nik ---
**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\ **Post date:** [August 17, 2026, 7:13pm UTC](https://community.auth0.com/t/silent-authentication-systematically-requiring-consent-in-spa-breaking-token-rotation-for-oidc-spa-library-users/201575/8 "2026-08-17T19:13:52Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.