I have setup the callback URLs and verified that the webcredentials entry matches, as well as set up my provisioning profile with associated domains. Every step in the walkthrough matches what is asked for, but I continue to get the following error:
Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier {MY_IDENTIFIER} is not associated with domain {MY_AUTH0_DOMAIN}. Using HTTPS callbacks requires Associated Domains using the `webcredentials` service type for {MY_AUTH0_DOMAIN}"
I have cleared derived data and tested on simulators and my personal device with the same result. At a bit of a loss on what to do next.
Would I be right in thinking you also posted about this on our GitHub repo for Flutter (see here)? Did you end up solving the problem? I’ve not specifically researched this issue, but Widcket’s comment - which is essentially related to information caching - would seem to make sense.
As mentioned, you can check the information Apple holds by visiting https://app-site-association.cdn-apple.com/a/v1/YOUR_AUTH0_DOMAIN_OR_CUSTOM_DOMAIN. Typically, this should match the information provided by https://YOUR_AUTH0_DOMAIN_OR_CUSTOM_DOMAIN/.well-known/apple-app-site-association - i.e. the AASA file data hosted by Auth0. At least for the appID in question.
If there’s a mismatch, then it’s likely going to be in the domain name portion, and would typically be a result of switching from using the out-of-box Auth0 Domain Name to using a Custom Domain Name (or vice-versa). In essence, one domain is being used with Auth0, whilst the other has been cached by Apple.
According to the Apple Documentation, it looks like it’s possible to add associated domain entitlements; it also mentions that the Apple CDN will update periodically, so the problem would likely fix itself…eventually!
Another possible solution could be to delete the App definition and create a new one (with a new App ID). However, this would likely have a knock-on effect on your application - including the need to change the Application (Client) definition in Auth0.
I’d be very interested to know how you ended up solving the issue, so please feel free to post an update here when you have the chance and let us know how you got on. Cheers
We too are having this problem on a regular basis. Sometimes it clears up, sometimes it doesn’t. Sometimes it happens in the iOS Simulator, sometimes it only happens on iOS devices. I’ve checked Apple’s CDN and everything looks fine there. Unfortunately creating a new App ID is not really an option. As it happens we are not (yet) using custom domains, and we don’t use Flutter. Any other ideas @peter.fernandez ?
Hi @rick.pasetto, and welcome to the Auth0 Community!
As I mentioned in my previous comment, I’ve not researched this issue specifically, however, here are a couple of things that spring to mind that would be worth checking (numbered for convenience of reference rather than any particular order):
Have you checked to see that your application makes consistent reference to your Auth0 tenant Domain? For example, if you have a Custom Domain defined, then I would expect your iOS app to reference that Custom Domain consistently rather than switching between the Custom Domain and the default tenant domain at any point.
What happens if you retry the operation that gets the error? Though I would’ve expected Apple to gracefully handle cache refresh syncs, you may be encountering some artefact that results in the information required being unavailable whilst a cache refresh occurs.
Feel free to post any response here in the thread, thus keeping me and the rest of the Community apprised of your findings
@peter.fernandez thank you for the thoughtful reply! To answer your questions:
No, we are not using a Custom Domain, so that is not likely the culprit.
Retrying the operation sometimes works, sometimes doesn’t. By the way, the operation I’m referring to is simply just logging in (or rather, starting the login process) via Auth0’s Universal Login.
Some other interesting data:
This happens regardless of whether the app is run in Xcode or built, signed and delivered to users
This happens on both debug and release builds
I saw in other places that adding a ?mode=developer to the webcredentials: associated domain URN is supposed to circumvent Apple’s CDN, but that didn’t work (Caveat to other readers: this might have been incorrect information in the first place, I don’t know)
The error we get is exactly the same as the one at the start of this thread.
We may have the same case like @suraj.pathak , only happens on simulator for iOS 17.4 onwards. checked on simulator iOS 17.2 , everything looks fine.
By the way, we switched to another account’s application recently. As we have not enrolled any Apple Developer Program, there is not any “Team ID” available at the moment and our “.well-known/apple-app-site-association” looks like below:
{“applinks”:{“apps”:,“details”:[{“appID”:“undefined.com.abc.def”,“paths”:[“/ios/com.abc.def/*”]}]},“webcredentials”:{“apps”:[“undefined.com.abc.def”]}}
Not too suer this will cause the issue or not
Folks, I just wanted to post and give an update to everyone currently on this thread…or who comes across this thread Our iOS SDK team is currently looking into this situation in more detail, and I will post back here when I know more. Thank you everyone for your patience whilst we try to get more clarity In the meantime, I have a couple of follow-up questions which I believe will provide our (SDK) team with additional insight/information…
There are aspects to this issue which feel like a classic case of contended access - i.e. where cache update at the Apple CDN is periodically failing for some reason, but then subsequently succeeding on some later retry/update. As I’m sure folks are aware, there are a number of subscription options associated with Auth0, each one carrying associated policies for resource Rate Limiting. In addition, an Auth0 Tenant can be configured with an Environment Tag which further impacts rate limit policies. So, in the context of the issue, can I please ask folks to provide an indication of each of the following (numbered for convenience of reference rather than any particular order, and feel free to DM me if you’d prefer ):
Also, if anyone experiencing this issue has an Auth0 subscription that includes a paid support contract, I would urge you to open a support case as well as this could help expedite matters Thank you.
For folks experiencing this problem, it would be very helpful if you could also share some more information regarding the region in which your Auth0 Tenant is deployed (again, feel free to DM me if you’d prefer ). I’m not looking for specific tenant names, but rather an idea of where in the world tenants are generally being provisioned, i.e.
All of that information is very helpful indeed, and thank you for providing it
Environment Tag: Development (but we’ve seen it on Staging as well)
So can I just confirm whether or not you are seeing this in Production as well?
Subscription: Enterprise
As an Enterprise-level subscriber, I would highly recommend you open up a support case, tagging/linking the conversation here on Community. This will help to expedite matters to provide a speedier resolution…and in turn, in the spirit of collaboration, also help all concerned. Thank you
We are seeing a number of failure events with this error even though the /.well-known/apple-app-site-association on our custom domain returns a valid JSON string with our correct TeamID. We’ve been seeing this for a while and have tried multiple things to fix it, but no luck.
We are also seeing this consistently in a tenant set to production. Our development tenant does not see this consistently and settings are mostly identical. There were a few times where the error showed in development, but a reinstall of the app cleared it up; and may have been due to our transition between app builds that had webcredentials configured differently.
This app has not been previously released in the app store.
It is using custom domains. YOUR_AUTH0_DOMAIN_OR_CUSTOM_DOMAIN“/.well-known/apple-app-site-association” looks fine, and matches https://app-site-association.cdn-apple.com/a/v1/YOUR_AUTH0_DOMAIN_OR_CUSTOM_DOMAIN .
@peter.fernandez I watched this happen with a user immediately after they downloaded our app off the App Store. They ran into this error. I believe it may have fixed itself after a few hours, but this is extremely frustrating for us as developers to lose a significant chunk of our users to an error before they ever have the chance to interact with our app.
Do you have any more info from the team about what could be causing this?
Has there been any movement on this? We just setup a production tenet (us based) and I’m seeing this same issue. Dev tenet works as expected, and as far as we can tell everything in the prod tenet is setup the exact same way. Only appears to be an issue with iOS (native sdk)
Thank you for joining the community and sharing your feedback on this, @reuben1; I am sorry to hear this situation has had the impact it has, and, of course, this is far from ideal! I’d also like to welcome @chad.timmerman, and share with both of you - as well as everyone else here - that this is something we are actively looking into. However, as it stands, we don’t currently have a resolution right now sadly I will, of course, keep this community channel posted with any updates as they become available; thank you all for your continued patience
P.s. just to reiterate: if you are experiencing this issue and you do have a paid subscription with Auth0 that includes support, I recommend you open a support case, tagging/linking the conversation here on Community. Thank you
So for our issue, I was able to resolve it when I was creating a sample app the submit to the support team. My issue was with the development tenet plist file getting copied when trying to point to the production tenet. Once I confirmed that correct plist file was being used for production, everything seems to be working as expected.
I would suggest that everyone double check and confirm that the correct ClientId & Domain are being used.
In the meantime, I have a couple of follow-up questions which I believe will provide our (SDK) team with additional insight/information…
I will, of course, keep this community channel posted with any updates as they become available; thank you all for your continued patience 