Hello everyone. I’m sorry we didn’t respond to this sooner–I’ve been working with a few customers on this issue but didn’t see this post until this week.
The TL;DR is:
- We consider this a bug in Apple’s implementation
- A bug report was submitted to Apple and it’s being reviewed
- We don’t have any good workarounds right now, except to use the “fully native” SIWA implementation: Add Sign In with Apple to Native iOS Apps
Our “official” problem description is below. I’ll try to answer any questions you have.
The Sign-in With Apple web authentication flow is not completed properly when launched inside an iOS application and the iPhone Apple ID is used to complete the flow (usually through Touch/Face ID). It works correctly if an Apple ID is not set on the iPhone or if an Apple ID other than the iPhone Apple ID is used.
The issue is that during the Web Authentication flow, at the final stage, an HTTP 302 redirect is made that specifies the custom scheme of the App. This is a URL that will notify the application that the browser’s job is complete. At this stage, control should be handed back to the app. However, when Touch ID or Face ID is used (the majority of use cases) it appears that the custom scheme listener becomes broken and will never notify the app. The result is the end-user will be stuck with a blank browser and can never complete authentication.
We’ve been investigating this and there’s strong evidence that this is a bug on Apple’s side. We have logged a bug with Apple that is currently being reviewed.
We are evaluating alternatives to address the issue in Auth0’s side, but we could not find a good solution yet. The only current workaround is to implement Sign-in with Apple using our native implementation of Sign in with Apple: Add Sign In with Apple to Native iOS Apps