Hi, after the weekend, my website on the localhost started requesting “*** Client is requesting access to your dev-*** account", and it stopped saving the session and started asking to log in on every page reload.
What is checked:
- The production environment is working as expected.
- Authorization configuration was not changed on my side, not in the codebase, not in the dashboard.
audience is matched on both sides, in local configuration and in the dashboard.- "
Allow Skipping User Consent" It is turned on in the dev environment dashboard.
I expect it not to ask for consent and the session to be saved without login on every page reload.
It was working perfectly fine for more than a year until today.
Does anybody know how to fix this issue?
Hi @yaroslavtereshchuk
Welcome back to the Auth0 Community!
I understand that you are experiencing repeated login prompts and consent screens on your Auth0-integrated application running on localhost after a recent browser update.
The issue is caused by third-party cookie blocking in your browser, which breaks Auth0’s silent session restoration mechanism. On localhost specifically, Auth0 enforces a security rule that prevents silent consent skipping, forcing a full interactive login on every page reload.
Root Cause: Your browser’s tracking protection or third-party cookie blocking feature was recently enabled (likely through an automatic update), preventing Auth0 from using hidden iframes to silently restore your session.
Solution: Implement Refresh Token Rotation, the modern best practice that eliminates reliance on third-party cookies entirely.
-
Sign in to your Auth0 Dashboard and navigate to your Application settings.
-
Enable Refresh Token Rotation in your application configuration.
-
Update your SPA codebase configuration. If you are using @auth0/auth0-react or @auth0/auth0-spa-js, add the following to your Auth0Provider or Client initialization:
useRefreshTokens: true,
cacheLocation: 'localstorage'
- Verify that the SDK now saves the rotating refresh token in your browser’s local storage, allowing sessions to persist across page reloads without third-party cookies.
Official Workaround (temporary): If you need an immediate fix before implementing Refresh Token Rotation, you can temporarily disable third-party cookie blocking in your browser. In Chrome, navigate to chrome://settings/trackingProtection or chrome://settings/cookies and either disable tracking protection or add [*.]auth0.com to the allowlist for third-party cookies. Note that this is a temporary measure; third-party cookies are being phased out across all browsers.
Additional note: If you implement Refresh Token Rotation but still see the consent screen on your first local login, consider moving your development environment away from localhost, as Auth0 applies stricter security rules to localhost applications.
Please follow up if you need further assistance with Refresh Token Rotation configuration.
Kind Regards,
Nik
Thank you for the answer.
What I did:
- I added
[*.]auth0.com to the list of allowed sites to use third-party cookies.
- Checked
Refresh Token Rotation and it is enabled.
- Added
useRefreshTokens and cacheLocation params to the configuration on the implementation side.
What is the result:
- Site stopped asking for login on every page reload.
- But the “Consent” window is still showing.
My current questions:
- Can I remove the “Consent” window on the localhost?
- Isn’t storing tokens in
localstorage vulnerable? If someone tricks the user into pasting a malicious script in the console, the user’s token can be stolen. Or is this configuration only for the development environment?
We are having the same issue with localhost. All bullet points from the first message apply to us as well.
Localhost was working fine last week, but silent authentication started failing yesterday, and we’re not sure why.
The error we see in the logs is:
"error": {
"message": "Consent required",
"oauthError": "consent_required",
"type": "oauth-authorization"
},
We suspect this may be related to how the browser handles third-party cookies, but we haven’t been able to confirm this theory in the browser settings.
We purposely avoided using Refresh Token Rotation due to security concerns.
Hi again!
I understand that you are asking why Auth0 forces a consent screen on localhost environments, and whether the recommended localStorage token storage approach is secure.
Auth0 intentionally enforces consent screens on localhost because it treats localhost as an unverifiable domain. This is a deliberate security feature that cannot be bypassed by toggling “Allow Skipping User Consent” in the dashboard.
Root Cause: Auth0 classifies localhost as an unverifiable domain and always requires explicit user consent during authentication on localhost, regardless of your application settings. If this worked previously, you likely had an active session cookie from an earlier login, and your browser permitted third-party cookies for Auth0’s silent iframe. When your session expired or your browser enforced third-party cookie blocking, Auth0 re-evaluated the consent rules and now requires the consent screen.
Solution: Use a custom local domain instead of localhost.
-
Edit your computer’s hosts file:
- On Mac or Linux:
/etc/hosts
- On Windows:
C:\Windows\System32\drivers\etc\hosts
-
Add a custom domain mapping: 127.0.0.1 mylocalapp.com
-
Sign in to your Auth0 Dashboard and navigate to your Application settings.
-
Replace all localhost references with your custom domain:
- Update Allowed Callbacks from
http://localhost:3000 to http://mylocalapp.com:3000
- Update Web Origins to
http://mylocalapp.com:3000
- Update CORS settings to
http://mylocalapp.com:3000
-
Start your local development server and navigate to http://mylocalapp.com:3000. Because the domain is no longer localhost, Auth0 will respect the “Allow Skipping User Consent” toggle.
Regarding localStorage security: Storing tokens in localStorage is vulnerable to Cross-Site Scripting (XSS) attacks. Any JavaScript executing on the page—from a malicious browser extension, a compromised npm package, or user-entered console scripts—can read localStorage tokens.
However, this configuration is widely used in production as a necessary architectural tradeoff and is considered secure only when strictly paired with Auth0’s Refresh Token Rotation mechanism. For your development environment specifically, localStorage with Refresh Token Rotation is an acceptable approach.
Alternative approach: If you implement Refresh Token Rotation but still encounter the consent screen on your first local login, you must move away from localhost entirely. The custom domain workaround above is the recommended path.
Fallback for interactive login: If you cannot move away from localhost, adjust your frontend code to handle the consent_required or login_required error when getAccessTokenSilently() fails. Implement a seamless fallback to an interactive login method so users can see and interact with the consent screen.
Please follow up if you need further assistance with this configuration.
Kind Regards,
Nik
Hi, thank you for the answer.
Now I have enough information about what to expect and how to deal with the issue.