Hi there,
With our applications currently hosted on different domains to the custom login domain, the introduction of third party cookie tracking limitations, i.e. Safari ITP, has required that we employ one of the suggested mitigating approaches. Refresh Token Rotation using the auth-0-spa-js lib (1.7.0-beta.5) currently appears to require that cacheLocation be set to “localstorage” to work in Safari, which has is own security implications. Regardless, we are interested in using the seemingly preferred option of having the applications share the “parent” domain of the (login) custom domain.
Currently we have something similar to:
login.domain.com
app-one.com
app-two.com
It seems that the suggestion is that we could do something like:
login.domain.com
app-one.domain.com
app-two.domain.com
In which case, the Auth0 cookies (auth0, did, etc) will be set for login.domain.com, and since they are set for the same “site” (domain.com) as the sibling subdomains, the rules seem to suggest that they should be “accessible” to the sibling domains, also. With the call to the authorisation endpoint being performed within an iframe (as a nested context within a sibling domain), I would assume that the calls to the login.domain.com would also be considered to originate from the same site.
Is my understand correct? Also, are there are any other (application) cookies that have significance here, and what alternative options might we have?
If there is an issue with the cookies being set on the login.domain.com domain, is it feasible to set the custom domain to be the parent domain and therefore allow the application sub-domains to access the cookies, or to have the cookie domain values set to the parent domain (domain.com) whilst keeping the custom domain set to login.domain.com?
Thank you in advance!
Regards,
Jon