Sign in with Apple + Universal Login in Swift results in a blank page?

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.

2 Likes

Hey there!

Have you followed this tutorial thoroughly?

1 Like

Hi Konrad,

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.

2 Likes

Cause we don’t have such example just yet. Let me dig into it and get back to you soon!

1 Like

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.

1 Like

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.

1 Like

I am also faced with this problem. Are there any solutions?

Were you able to figure this out?

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:

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: https://auth0.com/docs/connections/apple-siwa/add-siwa-to-native-app

2 Likes

Thanks for sharing that @matt.macadam!

@matt.macadam Any updates from Apple in terms of the bug? Currently facing this with a NativeScript app and trying to figure out how to proceed.

No updates from Apple yet. The only suggestion I have for now is the “full native” flow I mentioned in my previous post.

1 Like

Thanks a lot Matt for the update!

Hi everyone,

Apple acknowledged this as a bug in WebKit, which is being tracked at:

https://bugs.webkit.org/show_bug.cgi?id=206462

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.

1 Like

@ron.hsu, @garygambill, @mike0368, @benjamin.cortens :point_up_2:t3:

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.

1 Like

Thanks for the info Matt!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.