amplify-js: When I use sign in with apple in amplify, it jumps to safari, so it is rejected by the App Store review.

Hello everyone, we are working closely with the Amazon Cognito team to resolve this pain point. We understand that the Sign In With Apple experience through hosted UI is a sub-optimal experience, and we are working on enabling a mechanism for helping you use it natively in your apps. We will provide updates on this issue as we make progress.

I am actually SUPER disappointed by this conclusion. Even though I am very thankful for @mkrn and his thoughts, I really don’t get why Amplify makes it so incredibly hard to provide a custom authentication flow, because Firebase already showed us how easy it can be done and I am quite shocked at how bad of a job Amplify is doing at this, especially as I do not want to settle for the mediocre UX that the HostedUI would provide my users.

Nevertheless, thanks to everybody contributing

With the release of the latest major version of Amplify (aws-amplify@>6), this issue should now be resolved! The Auth.federatedSignIn() method has been renamed to signInWithRedirect which displays the sign-in UI inside a platform-dependent webview. On iOS devices, an ASWebAuthenticationSession will be launched and, on Android, a Custom Tab.

Please refer to our release announcement, migration guide, and documentation for more information.

@nadetastic yes I am.

Just to make it clear for you. When I use InAppBrowser.openAuth(), it will open the in app browser and then show the native ios login, not the web based login which is nice.

https://user-images.githubusercontent.com/80689446/215415748-81b139b3-eac2-4413-bba2-f72fd08cbd67.MP4

What I am wondering and looking for is to never have the InAppBrowser open at all. Can’t it make the auth call without opening a browser. It is not nice UX.

classic amplify, 3 years later and we still cannot have a standard sign in with apple method. The browser popup approach looks awful, there should be the native apple bottom modal that prompts you to double tap to sign in, no redirecting to the browser. This is why I switched to firebase which just works in about 10 minutes. This should absolutely be a priority and its very telling that it isn’t.

@pjsandwich any specific docs you followed for this?

https://docs.amplify.aws/lib/auth/social/q/platform/react-native/#oauth-and-federation-overview and select Sign in with Apple. If you have an existing app, you won’t need to create some of the Apple resources or keys, but you will need to generate new provisioning certificates.

Has there been any movement on this? I’m confused as to why there is documentation describing how to implement Apple Sign In with Amplify while every preliminary discussion I’ve looked at prior to attempting implementation seems to have its own issues. I’m personally interested in why this doesn’t work.

A better question is: If I follow the Expo CLI full sample code, will this work? I’m assuming not, or this issue would be closed.

For anyone looking at a variety of attempted solutions, here are some related issues: #4689 , #6637 , #4580 , #6547

Considering Apple is now going to enforce all apps submitted to App Store to have Apple Sign In as an authentication option, I’d expect this to be a high priority item, however it seems like this is now entering its third year of issues… Hope there’s some progress soon.

Hi @DatMoser - we share your frustration about how complex it is to setup CUSTOM_AUTH currently with Amplify. We have multiple conversations happening internally now to find ways to streamline this experience for our customers.

For anyone looking to use a native Sign In with Apple (SIWA), here’s the work-around:

• Use this package, or native SIWA code with Swift and decode the idToken from Apple, to get the email and name of your user.
• Sign in with amplify with authenticationFlowType: “CUSTOM_AUTH”,
• You’ll have to implement 3 lambdas to define auth challenge, create auth challenge, and verify auth challenge response
• Add them as hooks to your Cognito user pool
• If your sign-in errors out with UserNotFoundException then sign Up with randomized password
• If your sign in receives challengeName CUSTOM_CHALLENGE, respond with the idToken you’ve got from apple
• In your verify challenge response hook use verifyAppleToken npm package to validate the token
• In your define auth hook, issue the tokens, voila = you’re signed in with your cognito user! You might have to verify nonce for extra security

Unfortunately, it’s NOT possible to use native SIWA with federatedSignIn (it must use hosted UI, for Cognito auth backend to generate cognito users linked to identities). I’ve tried many workarounds, with no luck.

Hi @nubpro @mcarlstein @amhinson

In my project, I would like to share that Apple has accepted “Sign in with Apple” with a little change.

In urlOpener, I changed ephemeralWebSession to true, so that iOS doesn’t show the dialog before opening in-app browser. At least, about Jan, 2 React Native apps I involved have been accepted with this change.

async function urlOpener(url, redirectUrl) {
  await InAppBrowser.isAvailable();
  const { type, url: newUrl } = await InAppBrowser.openAuth(url, redirectUrl, {
    showTitle: false,
    enableUrlBarHiding: true,
    enableDefaultShare: false,
    ephemeralWebSession: true, // update
  });

  if (type === 'success') {
    Linking.openURL(newUrl);
  }
}

Detail

in iOS, ephemeralWebSession has these pros/cons.

ephemeralWebSession === true

• No confirmation dialog.
• User MUST provide authentication info like ID/PW, Touch ID or Face ID etc, EVERY TIME.

ephemeralWebSession === false

• iOS shows the confirmation dialog. (EVERY TIME, Even if for logout!!!)
• iOS will reuse auth info if exists. That means user only needs to provide authentication info at first time.

So I recommend to check the url before calling InAppBrowser.openAuth() and set ephemeralWebSession dynamically depends on the url.