Sign In with Apple using Native Experience?

[rigocarbajal]

State your question
We are currently working on adding Sign In with Apple support using Hosted UI. However, what we'd prefer is to implement a native experience. As far as we can tell, this is currently unsupported using Cognito User Pools, for the reason that it bypasses the user creation process. Is this a correct assumption? If a native implementation is possible, can you please shed some light on how we might achieve this? And if it is not currently possible, are there plans to add support for a native experience in the future? Thanks for your help with this.

Which AWS Services are you utilizing?
AWS Cognito - User Pools
Environment:

• SDK Version: AWSMobileClient (2.13.3) AWSAuthCore (= 2.13.3) AWSCognitoIdentityProvider (= 2.13.3)
• Dependency Manager: Cocoa pods

[wooj2]

Hi @rigocarbajal ,

You are correct, unfortunately sign in with apple support is only supported with HostedUI, and we do not support a way to support this via a native UI. At the moment, I am unaware of any plans with regards to supporting a native sign-in experience with sign in with apple.

Best of luck!

[BillBunting]

@wooj2 , I have an app using AWSMobileClient.default().showSignIn() that has been in production for two years. Your comment suggests that anyone using showSignIn() needs to switch to the HostedUI ? Are there plans to deprecate the showSignIn() ? Without Apple sign-in support, Apple will reject the app in the future.

[iofluxdev1]

The drop in UI user experience is horrendous (Regular expression error messages etc). I hope your stance regarding this changes in the future @wooj2 otherwise the drop in UI needs some work rather urgently. No work has been done on it for a while now.

[wooj2]

@BillBunting
Thank you for bringing this to our attention. We have started work on supporting Apple sign-in for drop-in UI. Unfortunately we do not have an estimated time of completion or when this feature will be released, but we consider this to be one of our top priorities. We will update this thread when we have a better estimate on when we think we can get this fix released.

@iofluxdev1
Sorry to hear that you find the hosted UI as horrendous. Would you be willing to help us better understand how we can make it better? Are you fundamentally against using webviews, or are there suggestions on how we can improve the UI?

[eanntuan]

Does this mean that we are unable to connect Sign in with Apple for native iOS and sync with Cognito user pools? I'm in a similar boat, where I'm able to successfully SIWA on the hosted UI, but I have my own native UI login page and am adding a SIWA button.

After successfully authenticating with Apple via func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization), I send the appleIDCredential to AWS Cognito and attempt to sign in (able to successfully getIdentityId but not connect to my Cognito User Pools):

@available(iOS 13.0, *)   
func finishedWithAuth(auth: ASAuthorizationAppleIDCredential!, error: NSError!) {
    if error != nil {
        print(error.localizedDescription)
    } else if let idToken = auth.identityToken {
        // Force the SDK to obtain new credentials
        clearCredentials()
        updateCredentialsProvider()
        let idTokenString = String(data: idToken, encoding: .utf8) ?? ""
        let logins = ["appleid.apple.com": idTokenString]
        let customIdentityProvider = CustomIdentityProvider(tokens: logins)
        let identityPoolId = Configuration.cognitoIdentityPoolId.value
        let region: AWSRegionType = .USWest2
        let credentialsProvider = AWSCognitoCredentialsProvider(regionType: region,
                                                                identityPoolId: identityPoolId,
                                                                identityProviderManager: customIdentityProvider)
        let configuration = AWSServiceConfiguration(region: region, credentialsProvider: credentialsProvider)
        AWSServiceManager.default().defaultServiceConfiguration = configuration
        credentialsProvider.getIdentityId().continueWith { (task: AWSTask!) -> AnyObject? in
            if task.error != nil {
                print("Error: " + (task.error?.localizedDescription)!)
            } else {
                // the task result will contain the identity id
                let cognitoId = task.result
                logit("Cognito ID : \(cognitoId ?? "")")
            }
            return nil
        }
    }
}`

[bumbleparrot]

I think this is a highly requested feature. The reason is that when the “sign in with” experiences are demoed by Apple at big events like WWDC, users expect that native experience.

My post here details what I understand the experience to features trade offs are using Cognito.

@rigocarbajal , in short if you want the truly native experience for any “Sign in With” provider, you have to use Identity pools federated identities and manage your own user profile data (via a Database)

[VadimRupets]

Hello there. We've been using HostedUI with Sign in with Apple for couple of month on production. But last week we received a rejection from Apple Review team with the following message:

"From Apple
Guideline 2.1 - Performance - App Completeness

We discovered one or more bugs in your app when reviewed on iPad running iOS 13.6.1 on Wi-Fi.

Specifically, when using "Sign in with Apple” the app will open an iCloud login page instead of following the correct "Sign in with Apple" procedure."

@wooj2
This blocks our release and puts us in a difficult situation as we cannot deliver anything until the issue is resolved. Is there a way to fix that with as less backend and mobile changes as possible? Have you planned or prioritized working on "Sign in with Apple" through native functionality, since you haven't updated this thread since late June?

[palpatim]

@VadimRupets To verify: Is Apple objecting to you using a native button styled like a "Sign in with Apple" native control, but launching a HostedUI web flow, or using a HostedUI web page to host all of your social providers, of which SIWA is one?

Also, the line about "the correct 'Sign in with Apple' procedure" is a bit ambiguous. Did Apple clarify what they meant by that?

[VadimRupets]

@palpatim I don't think we are on the same page. To clarify what "Sign in with Apple" procedure means is to use Apple's AuthenticationServices framework to get JWT token signed by Apple. In order to do that we need to use something like

@available(iOS 13.0, *)
    @objc private func performSignInWithApple() {
        let request = ASAuthorizationAppleIDProvider().createRequest()

        request.requestedScopes = [.fullName, .email]

        let controller = ASAuthorizationController(authorizationRequests: [request])
        controller.delegate = self
        controller.presentationContextProvider = self
        
        controller.performRequests()
    }

extension LoginViewController: ASAuthorizationControllerDelegate {
    
    func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) {
      // handle authorization result
    }

After that we need to perform federated sign in, if I understood that right.

So my question is are you planning supporting "the correct "Sign in with Apple" procedure" out of the box?

[palpatim]

@VadimRupets The HostedUI flow is part of Cognito User Pools. It is not supported to use the native Sign in with Apple process with HostedUI. Native SIWA flows (like Facebook & Google) return tokens that are used for Cognito Federated Identities (Identity Pools), and that process is currently supported (although please see #2513 for a discussion of a token refresh issue that is impacting that flow).

[MatejBalantic]

@palpatim since it's clear from @VadimRupets's experience that Apple is actively rejecting apps that use WebViews ("HostedUI") to present SIWA to users, are there any plans to support native SIWA flow with Cognito User Pools?

Since adding SIWA is a requirement for us, it seems that at this point we only have a choice between switching away from Cognito, or using "HostedUI" (a.k.a WebView) to present SIWA.

Considering that the latter option might get our app rejected and is also breaking expected UX paradigms I do hope this is a top priority for you to resolve?

[MatejBalantic]

Just to add something to my previous post: We are already using Cognito Users Pool REST API for native authentication within our iOS app, so all we would need at this point is a REST endpoint that exchanges SIWA id token for Cognito User Pool id token.

[BillBunting]

I have integrated and am successfully using Apple sign-in with the drop-in UI with federated identities ( AWSMobileClient.default().showSignIn()) It is working very well and Apple will approve my next release (Apple rejected my last release because I offered FB and Google sign-in but not Apple; but, Apple gave me a one time pass to release without SIWA to get out a bug fix. I can not release again without SIWA) I currently have Apple sign-in for the drop-in UI in a public beta of automodlist. The only issue is that users need to sign-in more frequently than with other social providers. The user experience is good, just a little annoying that sign-in is required so often.

Please continue to support and work to resolve issues in SIWA with the iOS drop in UI via AWSMobileClient.default().showSignIn() - I need it to continue to work. I have no plans to switch to the HostedUI as I want a native sign-in experience for federated identity pools. Thank you.

[BillBunting]

Quick update, Apple accepted my app with SIWA using AWSMobileClient.default().showSignIn(). It is live in the app store now. Unfortunately, Apple initially rejected it because it collected phone number as a non-optional Cognito user pool attribute for username/password accounts. I removed the ability to create new Cognito accounts as I want my users to have the best native experience (and because there is no easy way to make a user pool required attribute such as phone number optional without creating a new user pool). It was easier to drop support for allowing users to create their own new username/password Cognito user pool accounts. User pool users may still sign in. I reworked the showSignIn() sign in screen to emphasize SIWA as the preferred choice (moved it more to the center and compressed the username password fields and cleaned up the appearance of the showSignIn() screen.

The SIWA user remains signed in for periods longer than 10 minutes and up to 24 hours or longer (not sure what changed here). Re-authentication has a good user experience (especially with Face ID).

I do need the ability to get the Apple user's name and email upon initial Apple sign-in which I have done by exposing ASAuthorizationAppleIDCredential as property of AWSAppleSignInProvider. I have asked for this as a feature request in
#3143 (see for details).

[palpatim]

Please see #2513 (comment) for a discussion of the current state of Cognito support for Sign In With Apple. Please feel free to comment there if there are any outstanding questions about Cognito & SIWA.

As @BillBunting noted, his change in #3308 also exposes the credential for the initial sign in.

I am closing this issue to consolidate remaining conversation.

[michaeljajou]

Are there any updates on this issue? It seems that everywhere I look, no one has given a concrete answer as to how we should implement a native sign in with Apple experience. All I am reading is "we are working on this," yet i've seen posts from 2 years ago that say this exact thing. This is such a stressful experience, and other cloud services do not have this problem (Firebase & Realm both support native sign in with Apple.) This is very concerning given the fact that Apple is very adamant on providing a good SIWA experience.

[henryouang]

Are there any updates on this issue? It seems that everywhere I look, no one has given a concrete answer as to how we should implement a native sign in with Apple experience. All I am reading is "we are working on this," yet i've seen posts from 2 years ago that say this exact thing. This is such a stressful experience, and other cloud services do not have this problem (Firebase & Realm both support native sign in with Apple.) This is very concerning given the fact that Apple is very adamant on providing a good SIWA experience.

Agreed. Can we get an update on this? This seems to be a core feature that hasn't been looked into at all...

[jacobsapps]

Wait, this still doesn't exist??

[mozadeh]

this is a very poor user experience AWS is enabling here for customers, the fact that this is not available yet doesn't show "Customer obsession"

[orestesgaolin]

Also wondering what is the current status of native support of SIWA.

[los-ko]

Why is this issue even closed? Please re-open since this has not been fixed. The WebView solution doesn't get accepted by reviewers at apple, also if it would its still a really bad ux.

[michaeljajou]

Why is this issue even closed? Please re-open since this has not been fixed. The WebView solution doesn't get accepted by reviewers at apple, also if it would its still a really bad ux.

Is it true that the web view solution will not be accepted by Apple reviewers?

[los-ko]

"We discovered one or more bugs in your app. Specifically, all three features “Sign In with Apple”, login with Facebook and Google were implemented but did not function on their UI. Please review the details below and complete the next steps."

This is what they sent to us, we are waiting for the clarification of what "it did not function on their UI" means.

[michaeljajou]

"We discovered one or more bugs in your app. Specifically, all three features “Sign In with Apple”, login with Facebook and Google were implemented but did not function on their UI. Please review the details below and complete the next steps."

This is what they sent to us, we are waiting for the clarification of what "it did not function on their UI" means.

Gotcha, please let us know

[Albert-Gao]

It's not about Apple, it's about the UX, the web view version has worse UX than the native Apple-Signin, that's all. I do not think we even need to argue with it....

What's blocking this issue for 2 yrs? How can I help to make it happen? :)

[jacobsapps]

Hi @rigocarbajal ,

You are correct, unfortunately sign in with apple support is only supported with HostedUI, and we do not support a way to support this via a native UI. At the moment, I am unaware of any plans with regards to supporting a native sign-in experience with sign in with apple.

Best of luck!

It's been 1.5 years since this has been requested. I've been speaking to users and potential users and I have confirmation that people are dropping off specifically due to the clunky web-view sign-up flow. Firebase does it, Realm does it, I don't understand why you don't want to be at the minimal feature parity?

Can anyone from Amazon please explain when we can expect this to be delivered?

And can anyone not from Amazon outline a reasonable contingency plan for how to transition away from Amplify/Cognito without losing half my users? Am I forced to make them all reset their passwords?

[philipheinser]

@palpatim Is there any plan to support Native SignInWithApple. If not not we have to switch to another Auth provider :(

[juskek]

Any updates on this? Would appreciate any help!

[ekurutepe]

Any updates on this?

[tvongerlach]

Is there an update on this? Feels really bad to show users that web view. What's the best plan of action as of May 2023?

[abdallahshaban557]

Hello, we are working closely with the Amazon Cognito team to allow Sin in with Apple natively, without needing the hostedUI Web view. We will provide further updates as we have clarity on the timelines and path forward.

[JUSTINMKAUFMAN]

Any update on this? We very much need a solution ASAP.

[abdallahshaban557]

Hello @JUSTINMKAUFMAN - we do not have an update yet. We are deeply engaged with the Cognito team to enable this as soon as we can.

[iwishApp]

So what are the current options if:

1. you don't want to show ugly web ui to User
2. you can't afford logins every 24h
3. you have all the infra set up on AWS.

Only painful full infra Firebase migration?

[philipheinser]

@iwishApp yes migrate they don't seem too care at all. they know about this issue since 2020. Also its against Apples guidelines to use the non native flow. Apple might ban our app. Seems like false advertising when they say on their website they support singing with apple but on the only platform that's relevant iOS they don't.

[hdworld11]

Hello, we take your feedback very seriously and are trying our best to get this feature to you as soon as possible. Unfortunately, because of dependencies, we are unable to provide any update at this time.

We will provide an update here as soon as we have more information. Thank you for following up!

[aaorlov]

that's the biggest cons to use Cognito compared to other services =/

[dreamwieber]

Anyone have an alternative? This is a huge blocker. Is there really no way to do this without the bloat of Amplify?

If you have the verified identity provider info from Apple, why can't you just hit cognito HTTP api directly for this?

[harsh62]

why can't you just hit cognito HTTP api directly for this?

Cognito User Pools doesn't have any public API that supports federation.

[flodaniel]

Hello @JUSTINMKAUFMAN - we do not have an update yet. We are deeply engaged with the Cognito team to enable this as soon as we can.

Any updates over half a year later? There a dozens of open tickets across all amplify SDKs and still no movement on this issue, while competitors have it figured out for years now :/

Is there anything we can do to raise priority on this?

[ethan021021]

It's incredibly unfortunate that this is not currently supported.

Could we possibly skip the hostedUI presentation all together and instead authenticate with the hostedUI endpoint directly?

[philipheinser]

Hello, we take your feedback very seriously and are trying our best to get this feature to you as soon as possible. Unfortunately, because of dependencies, we are unable to provide any update at this time.

We will provide an update here as soon as we have more information. Thank you for following up!

Thanks for trying your best. Did you still not get any updates?

[ekurutepe]

Folks, if you can use amplify-swift I have a fork where native SIWA works.

[ethan021021]

Folks, if you can use amplify-swift I have a fork where native SIWA works.

I'm currently using amplify-swift.

Does your native SIWA use a federated login with the escape hatch method? If so you can't use cognito user groups which Amplify uses by default for auth

[ekurutepe]

Sorry I don't know what federated login and escape hatch are. We do use Cognito for our auth.

It's this branch: https://github.com/Fika-Media/amplify-swift/tree/keychain-access-group-support

[ethan021021]

Sorry I don't know what federated login and escape hatch are. We do use Cognito for our auth.

It's this branch: https://github.com/Fika-Media/amplify-swift/tree/keychain-access-group-support

Thanks for sharing!

Where in the branch did you implement SIWA? I'm not seeing it in the commit history

[ekurutepe]

Please disregard my link. I am sorry for the false alarm. That was how we got amplify-swift to work nicely with iOS extensions. It's been a while since we implemented this stuff.

Looking at our code, what we do is to handle SIWA locally with the native interface, grab the SIWA JWT token, create a Cognito user with the email in the SIWA JWT token and then to some customSRP kung-fu at our backend to finish signin and get the Cognito tokens.

[ethan021021]

Please disregard my link. I am sorry for the false alarm. That was how we got amplify-swift to work nicely with iOS extensions. It's been a while since we implemented this stuff.

Looking at our code, what we do is to handle SIWA locally with the native interface, grab the SIWA JWT token, create a Cognito user with the email in the SIWA JWT token and then to some customSRP kung-fu at our backend to finish signin and get the Cognito tokens.

Thanks for the reply,

When you are getting the cognito tokens from the backend how are you authenticating the user with Amplify?

[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.

Please track the amplify issue for further updates on this.

[ethan021021]

Please disregard my link. I am sorry for the false alarm. That was how we got amplify-swift to work nicely with iOS extensions. It's been a while since we implemented this stuff.

Looking at our code, what we do is to handle SIWA locally with the native interface, grab the SIWA JWT token, create a Cognito user with the email in the SIWA JWT token and then to some customSRP kung-fu at our backend to finish signin and get the Cognito tokens.

Hi!

To get around this issue did you fork Amplify and pass the tokens your backend gives you into the SDK itself? Going through this process at the moment any insight would be greatly appreciated!

[kewur]

this is a lot of work, and if you have any options I would recommend not using cognito but, there might be a way to do this with custom auth flows.

basically, get a token using native SIWA, and authenticate using custom auth flow with a custom lambda on cognito. You would of course then need to store your accessTokens on your own, basically doing everything cognito/amplify is supposed to be doing yourself. Which at that point might as well write your own auth system and save money lol

but here's maybe how someone might be able to do this, basically pass the auth token with clientMetadata. Or you can directly call your own lambda/api gateway, to verify the tokens and pass down cognito tokens instead.

https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-challenge.html