Auth0 Home Blog Docs

3rd party cookies


Our team is using the deprecated Cross Origin authentication (using "/usernamepassword/login).
We’re about to move to the newer “/co/authenticate” using custom domains.
Custom domains exist because you decided, rightfully so, that 3rd party cookies could be expected not to be enabled (especially in e.g. an enterprise setting).

However… We noticed that using silent authentication (which is an iframe visiting the auth0 domain) cookies are also NOT being sent. In this context they’re also considered 3rd party cookies.
The result in our current set-up is that a user is instantly logged out when the browser is trying to renew the session; the session cookie is not being sent.

Does this mean that your clients, using the hosted login page/universal login for their SPA, should be concerned about their users having 3rd party cookies enabled?

Silent authentication alternative ( Safari , cross-origin tracking )

If you use the Universal Login Page, everything works just fine with or without custom domains. The issue arises when you’re trying to authenticate to a another domain ( authenticating to and the other domain tries to SET the cookie ( > SET-COOKIE ). This operation will fail if you don’t use custom domains. When you use the universal login page, the cookie is set in the same domain ( > SET-COOKIE, which will work and all subsequent calls to should also send the cookie.


I realize now that I should have been more specific. The issue I’m raising actually isn’t about 3rd party cookies specifically but what kind of cookies browsers (Chrome in this case) will block if you turn on the feature “Block third party cookies”. In Chrome, for example, it seems to also be blocking 1st party cookies if sent via an iframe. Which might be indicated by the flavour text; “Prevent third-party websites from saving and reading cookie data”.

To be more specific: even with our current usage of “/usernamepassword/login” the browser will redirect to the Auth0 appliance domain (self submitting form against “/authorize”) and Auth0 will, as a last response in the authentication, reply with a redirect statuscode (back to the app), a Set-Cookie header with HttpOnly session cookie and an id/access_token for immediate use. Even with “Block third party cookies” enabled in chrome I can clearly see this cookie being set. Great!

Now, when silent authentication is triggered after, due to session renewal being invoked via the Auth0 library. An iframe will be created by the Auth0 library, targetting the Auth0 domain to get a new token (using the session cookie) and then renew the current HttpOnly 1st party session cookie that was there. However, with “Block third party cookies” enabled the mentioned 1st party HttpOnly cookie is not sent in the previous step. Chrome seems to block it due to the “Block third party cookies” feature being turned on (I assume to avoid tracking).

Now, I could be wrong but isn’t universal login also relying on Silent Authentication to renew Auth0 SSO sessions?


Ah, ok. Thanks for the clarification. Yes, Chrome and possibly other browsers with 3rd party cookies disabled won’t send the cookie when you try to call checkSession. IE/Edge, for example, send the cookie anyway.


I’m a bit surprised that this isn’t mentioned somewhere other then here:

Am I right to say that this matrix is almost just as relevant for any implementations using silent authentication with or without using the cross-origin authentication feature.
It would be useful have a similar matrix reported here:



You’re absolutely right. I’m talking with the docs teams right now to add a section about this in relevant docs. I’ll keep you posted in this thread.


This also took me the better half of a day and should definitively appear in the docs for silent authentication. Silent authentication is ultimately a premium feature, seeing that it requires custom domains to work properly on 85% of browsers (not IE/Edge)

1 Like

So I just found this after a day of debugging why my iPhone is stuck in a login loop.

I spent all day yesterday migrating from embedded to universal login to work around the third party cookies issues. Do I have to fork over money to make it work on newer browsers after all?


I can confirm that custom domain fixes the silent authentication issue, and by extension fixes the redirect loop on iOS 12 safari.

1 Like

Thanks a lot @JanErikFoss for sharing it with the rest of community!

closed #11

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.