I’ve found a few similar threads around CORS auth with 3rd party cookies disabled, but our setup is a little different + all those threads have been left unanswered for months (and are now closed).
We have a SPA where auth works just great (hosted on app.domain.com with Auth0 being on login.domain.com). We also have a browser extension, which just embeds an iframe and displays a few views of our app embedded on the page the user visits. If 3rd party cookies are blocked (e.g. Safari, latest Chrome versions or even the “Brave shields” in the Brave browser), then the user cannot authenticate, as the cookies to login.domain.com are cleared/not passed along.
Auth0 lists Refresh Token Rotation as the solution, but even though we have it set up for our app, we’re unable to authenticate from within the iframe.
The setup from an end-user’s perspective is then: client.website.com > extension with iframe (chrome://<extension-id>) > iframe embeds app.domain.com > no cookies shared with login.klausapp.com
I’ve reviewed your case with the rest of my team, and we’ve come to the conclusion that, with iFrames it’s almost impossible to say that no problem will occur, so our recommendation is not to use iFrames if you want full assurance that the flow will work everywhere.
A cookie is defined as third-party if the domain on the page is different than the domain associated with the cookie. So if you have an app in the “company.com” domain and your Auth0 custom domain is “identity.company.com”, those are technically different domains. However, most browsers are okay when there’s a match in the parent domain (“company.com” in the example). Note that I’m saying “most browsers” because the rules are never very clear, and browsers can change that decision over time.
Apple’s “Intelligent Tracking Protection” for Safari, for example, has additional restrictions in place on when third-party cookies are available. This is Apple’s specific (no standard governing these rules) and they certainly change and tweak the system over time.
With iFrames the scenario is a bit more complex, because now you have three domains at play: the hosting page domain (extension with iframe on client.website.com), the domain of the app in the iFrame, and the Auth0 domain. Making all these domains match will be pretty much impossible, especially if the hosting app is from a third party (not controlled by you).
Also, letting third-party apps host your identity prompts in an iFrame poses a security risk (see “Clickjacking”, Clickjacking | OWASP Foundation
That being said, a solution implemented for Safari by another customer who had a similar architecture was to use the Storage API: Updates to the Storage Access API | WebKit
Please review this carefully, as it might be the only available solution, but note that this is not something we can help you implement, and will depend on how much customization the third-party allows.
I hope the above information answers your questions. Please let me know if you have any other doubts.