Ideally, Amplify/Cognito should not use a web view for Sign in with Apple

[jgale]

Describe the bug

Amplify/Cognito use a Web View when displaying the Sign in with Apple native action sheet. Ideally, it would not use this at all.

To Reproduce
Steps to reproduce the behavior:

1. Xcode project configured with Amplify and Cognito plugin. here & here.
2. Configure AWS Cognito with "Sign In with Apple" as explained here.
3. Run on a real device.
4. Tap on 'Sign In With Apple' button. which calls

Amplify.Auth.signInWithWebUI(for: .apple, presentationAnchor: window,listener: completionHandler)

A web view is shown that is loading appleid.apple.com, and then the native "Sign in with Apple" action sheet overlay is shown.

Expected behavior

The web view would not be shown at all, it would directly go to the native sheet.

Environment(please complete the following information):

• Amplify Framework Version: 1.6.1
• AmplifyPlugins/AWSCognitoAuthPlugin (1.6.1):
• Dependency Manager: Cocoapods
• Swift Version: 5.0
• CLI Version: 4.45.1
• Include any relevant log output under ~/.amplify/logs/amplify-cli-<issue-date>.log

Device Information (please complete the following information):

• Device: iPhone 11 Pro
• iOS Version: 14.4.1

Additional context

The mechanism for this is described in this comment by @palpatim. This could arguably be considered the same bug.

I'm curious if there is a way to use Sign in with Apple without needing to use ASWebAuthenticationSession at all. It leads to a sub-par user experience, and other problems like the blank web view when you cancel the Sign in with Apple process as described in #1027. This would of course necessitate a different API than signInWithWebUI.

When I use a native SwiftUI SignInWithAppleButton the web view isn't shown at all. I'm not sure if there's a way for Cognito to "intercept" this though.

[jgale]

I came across this Auth0 documentation on how they implement Sign in with Apple without a browser-based flow. It shows the sequence diagram that could work. Obviously this would be a lot more effort on your part.

[ameedsayeh]

It would be great if they support this.

and other problems like the blank web view when you cancel the Sign in with Apple process as described in #1027.

this behaviour is really annoying 👍

[palpatim]

Thanks for the feedback. We'll take this on as a feature request and discuss with the Cognito team. As you identify, it would be a fairly different type of flow from the standard OAuth flow. We'll update this issue if and when we have any information to share.

[mattcat10]

+1 to this. Somewhat related.. currently we have a need to clear all authentications on a fresh install and if a user signs in with apple with the web ui with .preferPrivateSession() option set, then uninstalls our app, reinstalls, we call Amplify.signOut and lose context of the privateSession and prompts the user with the " Wants to Use to Sign In" prompt. This is a really bad experience for the user and probably can be avoided by not using a web view for apple sign in.

[michaeljajou]

Any update on this issue? This is very important and i've seen a lot of other Github posts about this specific issue, even with some users having their app rejected by Apple for using a web view.

I've been looking for a solution everywhere, and all i've seen is the Amplify team saying they will consider this feature (however i've seen posts dating back to two years ago stating this.)

[palpatim]

Any update on this issue?

We don't have any updates to report at this time.

This is very important and i've seen a lot of other Github posts about this specific issue, even with some users having their app rejected by Apple for using a web view.

I'm aware of one reported app rejection because of a blank page, but not specifically because of using a web view. Can you add some links to the GitHub posts you're referring to?

[github-actions]

This issue is stale because it has been open for 14 days with no activity. Please, provide an update or it will be automatically closed in 7 days.

[pareshios]

+1 Getting the same issue. Its been a long time, Any update on this?

[kewur]

any updates?

[JJANGSOON]

Any updates?

[azhong-git]

Any updates?

[RadekNov]

Any updates?

[harsh62]

We don't have any updates to report on this issue at the moment. We are discussing the feature request with Cognito team and will post an update on this issue.

[ghost]

Any updates on this issue?

[abdallahshaban557]

Hello @luiabrah - we are still discussing this with the Cognito team, we will provide updates when we are confident of our next steps.

[kerekesmarton]

Any updates on this? I've read about the escape hatch solution, but not sure if after using the escape hatch, Amplify would have a session?

https://aws.amazon.com/blogs/mobile/federating-users-using-sign-in-with-apple-and-aws-amplify-for-swift/

Thanks!

[harsh62]

Any updates on this? I've read about the escape hatch solution, but not sure if after using the escape hatch, Amplify would have a session?

https://aws.amazon.com/blogs/mobile/federating-users-using-sign-in-with-apple-and-aws-amplify-for-swift/

Thanks!

Amplify would have a valid session object containing Identity Id and Temporary AWS Credentials which is federated into the Identity Pools.

Amplify would not have any details about the User Pool Tokens because the API federates into Identity Pools and NOT User Pools.

[kristjan97]

Any updates on this? This issue is 3 years old now. This is something that should have been implemented a long time ago, no reason why sign-in with Apple has to be a terrible looking web ui for user pools.

[harsh62]

The inclusion of this feature in amplify-swift remains a top priority, and we are actively engaging with the service team to advance its development for the benefit of our customers. Rest assured, we will furnish an update promptly. We regret any inconvenience caused by the delay and sincerely appreciate your patience as we work towards its prioritization.

[g-laures]

Any update? Looking forward this being implemented, especially on Mac where it does not ask for your fingerprint.

[XingZhaoDev]

I have impletemented Apple SignIn in my app, then I called "plugin.federateToIdentityPool()" and it is successful and I am able to fetch the credentials as well. BUT, when I called Amplify.Storage.uploadData(); I got error ""AuthError: Users Federated to Identity Pool do not have User Pool access.\nRecovery suggestion: To access User Pool data, you must use a Sign In method". Could you please help? I only wanted to have Apple SignIn in my app and do not want to create a custom SignIn flow or use User Pool.

[kewur]

I believe this is a cognito feature request, more than it is an amplify request. I don't see a way to authenticate through direct cognito calls at all using apple tokens, which is what amplify would use.

what amplify COULD do however, is to create a custom flow that accepts apple tokens. and create this feature for customers, before they all leave cognito/amplify for something that actually can pass IOS app store requirements (no web ui sign in is allowed)

Where is the customer obsession and insists on highest standards? this is clearly not meeting the bar.

[kristjan97]

@harsh62

[harsh62]

Update:

We have not yet received an update from the Cognito service team regarding the prioritization of the feature request. Please be assured that the Amplify team is in contact with them and is actively advocating for the prioritization of this request. We are committed to keeping you informed and will post any new information as soon as it becomes available.

[CyprienRicque]

This comment from @palpatim mentions

2. Identity Pools, using a server-side process to invoke Apple's Sign In With Apple REST API to refresh the identity token and deliver it back to your app. The app can then pass it to the client library as if it were refreshed in a local API call. We are working on documentation and code samples to demonstrate this flow and will update this ticket when we have something to share.
Note that in addition to a refresh token, the SIWA REST API requires you to set up and periodically refresh a "client secret", and that it is not appropriate to store or deliver that secret to a client device.

Is this something that might work? or that would not be successful and that's why there is no follow-up on it?
If you can confirm this should work, I am interested in creating the code samples.
@harsh62

[harsh62]

@CyprienRicque would you be able to share what you are trying to do? If you can share the use case, may be I can try providing an updated recommendation of what are your possible options.

[CyprienRicque]

Thank you for your reply!
Ultimately I am just trying to implement SIWA with a native experience. And so I try to figure out what is the best method to do it. I am using Cognito user pools.

Currently I am trying with custom lambda triggers.
My starting point is this: https://nickjones.tech/aws-cognito-siwa-native/
But for some reason my signin function returns
AuthError: Incorrect username or password.
Instead of bypassing the password check and using the custom challenge instead.

Also I wonder, even if it ends up working, would a user then be able to login to the same account with the hosted ui apple login and my custom setup?

If you have some demo code for this method I am interested!

[harsh62]

But for some reason my signin function returns
AuthError: Incorrect username or password.

I think this error is returned, may be the Lambda has not been setup correctly.

My starting point is this: https://nickjones.tech/aws-cognito-siwa-native/

The solution looks good, although I would make sure all the edge cases have been accounted for. Using Custom Auth is the only way to achieve this solution without direct support from Cognito.