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?
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 (myapp.com authenticating to myapp.auth0.com) and the other domain tries to SET the cookie (myapp.com > SET-COOKIE myapp.auth0.com ). 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 (myapp.auth0.com/login > SET-COOKIE myapp.auth0.com), which will work and all subsequent calls to myapp.auth0.com 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:
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)