I’m also curious to know the approach people took to verify their custom domain with apple… this means most of the time having login downtime while you unpoint the domain from auth0 and verify the file etc
You should provide the custom domain. Also, most if not all of the callback url settings in the Auth0 dashboard accept multiple urls, so you shouldn’t have to un-point anything.
Thanks Ron, however, I’m talking about the custom domain. Our domain is currently pointing to auth0, in order to verify with apple we have to unpoint it and serve the file, during which time the login is unusable. Does that make sense?
But yup, that’s what I used anyways, the custom domain, and getting this not very helpful error
Hm, I don’t think I follow. I don’t recall having to un-point anything or any kind of downtime. The verification I believe is independent of the login url settings.
What setting are you changing for the re-pointing?
No settings, just the custom domain is a CNAME pointing to the auth0 domain, I don’t see how you’d have that and at the same time use your domain in a server to serve the file
But I don’t mean to distract the post from its original issue, the weird error
We ran into the same issue and discovered there is a different set of configurations you need to enable for Native iOS users going through this flow.
If you go to Applications → (Your iOS Application client) → scroll to the bottom to Show Advanced Settings → and open up the Device settings tab you’ll see a toggle to enable native flow for apple sign in. This should do the trick, you’ll need to provide the Team and App Id.
I always get a 401 when this is included in headers: headers: { ‘content-type’: ‘application/x-www-form-urlencoded’ }, but a 403 when the previous is not included.
I request that the Auth0 support help us a bit more, cause the error we get is too generic and cannot help in solving this issue. Auth0 should have a much better support, especially on paid plans!