I’m trying to get cross-origin and silent auth to work together. Here’s my situation:
I have two client applications. Let’s call them Outer and Inner. Inner is hosted in an iframe inside of Outer. Previously we had an IdentityServer4 IDP providing OIDC auth, and we were using a hybrid flow to authenticate users to Inner. In the transition to Auth0, that doesn’t seem like it will work, because opening an iframe to the /authorize endpoint returns a CSP header frame-ancestors set not to include the Outer window.
After reading through a bunch of Auth0 documentation, I came to the conclusion that using Silent Authentication was probably the right way to handle authentication inside the Inner application. I have custom middleware set up to send a request to the /authorize endpoint from the back-end, and I’m successfully capturing login status info from the Location header in the response back from Auth0. The problem is that it’s always returning a ‘login_required’ error – even when I’m already logged into my Auth0 account. I suspect the problem is that my back-end system for the Inner client is not sending back Auth0’s cookies when making the call against the /authorize endpoint.
I have my cross-orgin domains set up and I have cross-origin auth turned on for my Inner client. I do have custom domains set up, but we’re running all our clients/apps on localhost in development, so I think it’s still causing a problem with the cookies. I’m guessing everything would be working if this was deployed to an environment running on the same domain as our custom domain.
My question is this: Is there any supported way to configure Auth0 to set cookies that are accessible to my localhost client? Or do I have to edit my hosts file to point my custom domain to my development app?
Bonus question: Will I have to run my local development environment under HTTPS for it to work?
There’s too much magic (not really magic, but special behavior) around localhost both in browsers as well as the Auth0 service itself. For example, the consent prompt can’t be automatically skipped for localhost.
Just because of the above I would say it is not worth it to be developing with such a different configuration and then possibly miss things that once deployed may work differently.
In conclusion, my recommendation would be to use the host file and just map a domain to your local machine. Technically, even if you don’t map your own domain, but map something like example.com or inner.example.com this will already be better than using localhost.
In relation to HTTP versus HTTPS I believe there are some settings in a client application that can only be configured to point to HTTPS URL’s although those may not be strictly required in certain situations. Nonetheless and again based on the general opinion that you’ll likely want to develop closer to the actual deployment config I would also try to use HTTPS for development.
Thank you for your reply. That makes sense. I’ve set my development environment to use my own domain via the hosts file over HTTPS, but I’m still not able to access the Auth0 cookies from my server-side application. If I have everything set up right, I should be able to access the cookies that were set by Auth0 on login.mydomain.com from my application at app.mydomain.com, right?
My colleague and I spent some more time troubleshooting this together, and we found that in order for my application (app.mydomain.com) to access the auth0 cookies (login.mydomain.com), the cookie sent from the login domain has to be set with the “domain” flag set to either my login subdomain or my root domain name.
I may have been confusing in my reply; aligning the custom domains will not imply that you will be able to access Auth0 service cookie values in your own system. As you said in order for you to be able to access the values themselves the cookies would need to be set differently (likely in the parent domain).
There’s not built-in option to allow the cookies to be set in the parent domain when using a custom domain so the behavior you observer is expected.
However, for the purpose of cross-origin authentication you would also not need to access those cookie values directly. The reason for aligning domains is that this should allow browsers to send those cookies even when iframes are being used.