I’ve added SIWA to our standard flow, which is currently Universal Login. I’m able to sign in with Apple, but I’m left with a blank Safari modal stuck at appleid.apple.com.
I have to cancel out to dismiss it. A subsequent login attempt just uses the existing apple credentials from the previous attempt (so presumably login succeeded) and things proceed smoothly from there.
I suspect it has something to do with the callback settings, but I’m not really sure what more I need to configure. I’ve already set the callback on the Apple side.
Yes, up until it goes into native Swift code. I’m using Universal Login with the Apple social connection, so the typical:
Auth0
.webAuth(clientId: Env.auth0ClientId, domain: Env.auth0Domain)
.scope(“openid profile offline_access”)
I just assumed that would work just like the other social connections, but is that not the case? I haven’t found a Universal Login + SIWA + Swift example yet.
Thanks Konrad! At a higher level, though, does this imply that it should work? I’m wondering if SIWA is intended for either full native (like the tutorial you replied with that has custom view controllers) or Universal Login + SIWA for non-mobile, but not Universal Login + SIWA + mobile.
I’d like to add that I’m experiencing the same issue with SIWA when trying to use it with a react-native application using the web-auth flow.
I receive the native popup which succeeds but I am then left stranded at a blank appleid.apple.com page.
I too have followed the various tutorials as required and if I choose use a different Apple ID from the native popover I am able to log in no problem, it is only if I try to use the Apple ID I’ve already signed in with that I get stuck on the blank page.
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
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
It looks like the bug has already been resolved. We’re told the fix will be deployed in the next iOS release, but that process is plainly out of our control so I can’t offer any timelines.
Little bit of additional detail: Apple says they’re targeting iOS 13.4 for the update. But just to re-iterate, this is information relayed from Apple–Auth0 has no control over the release schedule.
Apple released iOS 13.4 on Mar 24. One of our engineers tested it and confirmed the bug described in this post is fixed. Just keep in mind when supporting your users that this is only fixed in 13.4 and above.
(sorry for the delay posting here–I had put this post in another thread about this and just now realized it)
