Amplify-js: Sign In with Apple failure

[ghost]

Describe the bug
Using signin with apple is returning error Invalid+user+attributes%3A+email%3A+The+attribute+is+required%0A+&error=invalid_request

Additional context
We have recently implemented amplify sign with apple successfully in our app. I have been doing some testing lately and followed the below steps:

• deleted app
• deleted the apple user from Cognito
• removed the Apple ID Login for the app from the iOS setting
• cleared cache and cookie from Safari iOS

All of the above was to perform a clean test for sign In with apple. Since then I cannot get logged in. I receive the above error. I have seen something similar before with facebook federation where we do not have access to the email address (user signed up with phone). The errors are nearly identical yet, I know that the account is granting permission with the email, as I see an apple screen with the following message before we navigate back to the app - Do you want to continue using <app name> with your Apple ID <apple id>. Also, before the above steps, all worked fine and the user was created in Cognito.

Any ideas?

[markmckim]

I can replicate this also.

I have managed to narrow it down as follows:

1. My initial testing was done on simulator
2. When I click "Sign in with Apple" in my app, I get switched over to the browser, asked to login with username, password (because I don't have FaceID on the emulator). I then get prompted for Apple's MFA 6 digit code, then I get asked to share/don't share my email address and proceed
3. I get navigated back into my app and a new user has been created in Cognito
4. Login succeeds
5. I jump over to my real iPhone, and now try to login to the same Apple ID, this time using FaceID and it DOES work
   This flow works as expected

If I then delete my "Sign in with Apple" permission from iOS settings for a "fresh start", but this time I sign in "for the first time" using the real physical device (and FaceID):

1. Launch app on real iPhone
2. Click sign in with apple
3. Device opens browser and navigates to apple.com
4. Prompts me for FaceID
5. After FaceID prompt there is not a request to share email address
6. I am redirected back to application but get an error message and a user has not been created in Cognito

I can recreate this consistently, and can delete my Sign in with Apple permission from iOS settings and switch between these two test cases as often as I wish.

In summary, the issue seems to be related to Signing in with Apple for the first time using a real device.

One other point of note, which may be related - When using the simulator, the apple.com prompt says "do you wish to sign in to ", but when testing on a real physical device, the FaceID prompt says "do you wish to sign in to null"

[markmckim]

I also just wondered if it was a "debug" vs "release" Xcode issue, or an local vs bundled React Native issue. But I tried a bundled, release build on the simulator and it still works as expected.

So far seems related to initial sign up on a real device

[markmckim]

Possibly getting a little closer...on a real device, when I get the FaceID/TouchID prompt, if I select "sign in with a different Apple ID"....which causes me to use username/password login instead of FaceID/TouchID, then it DOES work.

It seems like whatever way the Safari in-browser FaceID/TouchID prompt is getting / sending back the app data is not working. (which would explain why the app name is null).

Anyone from Amplify have any ideas? Or can replicate?

Another note which may/may not be relevant - This app is not live in the App Store yet. (Just in case that is the root cause with the in-browser FaceID/TouchID prompt). Would be good if someone else could verify.

[markmckim]

I wondered if the fact that app was not live in the App Store yet was a factor, so I tried with this one of our live apps and still was getting the same issue. So it doesn't appear that this is related.

[ghost]

Cheers for the help on this @markmckim! Looks like I'm having the exact same issue! In native Face ID prompt has null for the app name. Using the web client to sign In with apple also seems to work!

Hey @elorzafe can I also suggest some Labels - Auth React Native

Hope this gets looked at soon! Ive had to disable Apple Login for now

[jovdipp]

Same issue using React JS on Safari. No user created in cognito when using Touch ID but does work if I use "sign in with a different Apple ID" as stated by @markmckim.

[sunnyqin]

Same issue when using Face ID and it does work when using username/password

[aaxx]

Confirm, same issue when using Face ID and it does work when using username/password. Our app has been rejected from publication in AppStore because of this issue

[iamdavidmartin]

Same issue. Things work great on the simulator, but break on the real device.

I'm using Expo. For a code sample, check out the amplify docs under the section called "A note for Expo users": https://aws-amplify.github.io/docs/js/authentication

[camin-mccluskey]

This is blocking us from pushing updates to a live app and in fact Sign in with Apple is just broken in production. Does anyone from the Amplify team have an update? @elorzafe?

[camin-mccluskey]

Hi @iartemiev any update on this? Happy to provide more information or help in any way.

[markmckim]

Without knowing if the Amplify team are even looking at this issue, (and a similar experience a few months back with zero communication on general availability of Sign in with Apple), it's becoming harder to justify continuing to use Amplify / Cognito.

I'm also in the position that I cannot release my app to the store because of this. I've had to disable Sign in with Apple until this defect is fixed, which in turn means I cannot release my App due to Apple's requirements for Sign in with Apple support.

@sarahcec I believe you commented on the original Sign in with Apple issue stating that you are the PM for the Cognito product. Would you be able to confirm if anyone is looking into this issue as this has become a blocker to the point that I am going to have to switch to a different provider just to get this functionality working so that I can release my app to the store. Thanks!

[sarahcec]

Thanks for the tag, @markmckim! We have replicated the behavior, and we've reached out to Apple to try to debug together.

One of the causes for this is that Cognito user pools can be configured to require an email address, and Apple only sends an email address on the first login. Apple has no way to know whether a user has been deleted from a Cognito user pool or not, so if a user is deleted, Apple will not send the email attribute when that person attempts to recreate the account, and Cognito will not be able to recreate the account. Cognito user pools CAN be configured not to require an email address, but that configuration can't be changed after the pool is created.

We think there's more going on here, particularly with Face ID, so we're still digging, but I hope that helps.

[camin-mccluskey]

@sarahcec can you explain how this is related to Apple not sending the email past the first login? Auth0 handles this by sending the email on each login regardless. In addition users (new, existing, deleted but recreating etc) CAN sign in as long as they don't use touch or Face ID - as demonstrated in this issue tracker by @markmckim, @aaxx, @iamdavidmartin myself and others. All in all Amplify and Cognito is a fantastic product, but the timescales to respond to seriously breaking issues are unacceptable for those of us trying to build production applications. I think we're all sympathetic to unknown timelines when debugging software but can I please ask that we're at least kept in the loop regarding any possible fixes. As before, I am happy to provide any information or help in any way to resolve this as quickly as possible! Thanks.

[markmckim]

Great. Thanks for the feedback @sarahcec . Good to know you guys are actively working this issue as a priority. If I know it will be a short term (days rather than weeks) then I'll hold off migrating to another auth provider.

I do agree with @camin-mccluskey that Cognito is a great product, but some more timely feedback on at least acknowledging defects and that they are being investigated would help have a lot more confidence in using this for a production system.

And I also echo @camin-mccluskey 's points that regardless of 1st, 2nd, nth login, in any combination of configurations...it works every time using username and password, but never using FaceID. Hopefully this extra info is helpful.

Thanks!

[agustinavarela]

In case it helps anyone else, this post fixed my Invalid State/RelayState provided.error: https://forums.aws.amazon.com/thread.jspa?threadID=310618

[camin-mccluskey]

@sarahcec @iartemiev Is there any update on this? We are completely blocked on pushing updates to our iOS app. Thanks

[iartemiev]

@camin-mccluskey The Cognito team is actively working on this issue with Apple. As soon as we have an update, we will post it here.

[rafaeh1]

any update? my team and I we are stuck to publish in App Store

[iartemiev]

Just spoke with the Cognito team and they are planning on releasing a fix in the near future. Will post another update once I get word that it's been deployed.

[camin-mccluskey]

@iartemiev thanks for the update, it's greatly appreciated! Can I ask what sort of timescale you might estimate - days, week(s)?

[markmckim]

Thanks @iartemiev - Should we expect a transparent update to Cognito server side that requires no action on our part? Or an updated version of Amplify to integrate into our apps? Thanks!

[lsale]

@sarahcec @iartemiev as this is an issue impacting many of us, we would appreciate a date or a date for a date at least. It's blocking app submissions and we need to plan accordingly.

[iartemiev]

@camin-mccluskey @markmckim @lsale - I've gotten confirmation that the Cognito team has deployed their change. Will update this issue when the change has been propagated and enabled in all regions

[camin-mccluskey]

hi @iartemiev thanks for the update! We're still seeing the same failure on our production app, I assume the change had to be rolled back? Any further update on this would be appreciated

[iartemiev]

@camin-mccluskey you are correct. The Cognito team had to roll back the change due to an unrelated issue. They're currently shooting for the end of next week for the fix to be rolled out to all regions

[markmckim]

@iartemiev @sarahcec Any update here? I really can't hold off much longer on this. Thanks!

[camin-mccluskey]

@iartemiev @sarahcec Could we get an update? Some of us have been blocked for over 2 months with this issue.

[rafaeh1]

I had to create a new "User Pool" with no email required because "Sign In With Apple" doesn't send name or email or both in some cases, I had to migrate all of my environments, now Apple approved my app.

[camin-mccluskey]

@rafaeh1 That is certainly an option but we do want the user's email if they choose to provide it and also we dont want to migrate all our users into a new user pool if we don't have to. Cognito should (and did in the past) deal with this situation so I'm hopeful they can figure out a solution without this workaround.

[sarahcec]

Hi all,

Product manager for Cognito checking in here. We've fixed the unexpected sign in errors.

For those who are curious what happened:
Apple was expecting percent URL encoding in scopes, and we were using “+” per the w3c standard. We've switched our input to percent URL encoding, and that has resolved the issue.

Thanks for your patience!

[camin-mccluskey]

@sarahcec Thanks for the update. Unfortunately we're still seeing the some of the same issues. The scopes do now seem to be correctly requested but the app name is still null and the redirect to a logged in url is not happening. Please see the screenshot attached.

[markmckim]

@sarahcec @iartemiev - Just tested and issue still persists for me. Exactly the same behaviour @camin-mccluskey is seeing.

Sorry, I can't afford to wait any longer on this. I'm going to start migrating off Cognito on Monday morning. I really wanted this to work, but the turnaround on such a critical production impacting issue such as this has been 2.5 months and counting.

For an organisation as big as AWS, this really should have been fixed in days, not months.

I'll give it until Monday but this has impacted me for so long, that it's now having a business impact and I have to migrate to a different provider.

[photodialectic]

I do believe there are two separate issues at play:

1. More than one scope requests would break auth flows because of the encoding used by Cognito for a space delimiter(+) while the encoding supported by iOS is (%20) - so iOS was reading the scopes as name+email which is not a scope instead of name email. As @sarahcec noted, this has since been fixed 🎉 .

2. "Do you want to sign in to null" - this I believe is an iOS constraint. My guess is the under the hood its using ASWebAuthenticationSession to initiate a login - which is essentially a WebView but more dedicated and as such striped down. My (no evidence) guess is the native dialog pulls the value of the "sign in to" name from the referrer header and ASWebAuthenticationSession likely either strips that value or pays no attention to it. This is why when you're in mobile safari and you initiate a login you see the dialog and the URL of the site, but when you try to do it within a native app you see null

Similar to other complaints here, this was a deal-breaker for us at BuzzFeed. As such, we decided to not use Cognito infrastructure for our iOS App implementation (we do intend to use it for mobile and desktop web) and instead wrote our own handling where our App handles the Apple auth flow and passes the Apple id_token to our backend which we then validated and process the user.

I acknowledge that our flexible architecture allows us to solve in this way and I'm not proposing it as The Solve ™️ I just wanted to share how we got unstuck - my main point is more I suspect this is an intentional design constraint on Apple's part. I think Apple wants apps to use the native implementation and not web implementations. I don't think it's a thing Cognito can solve.

[camin-mccluskey]

@sarahcec @iartemiev
This has been a major issue for us and continues to be. Thank you for finding and fixing the scope issue, I am curious how that became an issue since the OIDC standard is to use spaces between the scopes. Nevertheless it makes me wonder, have you properly reproduced the error all of us are seeing? Since you must (I hope) have tested it internally before you rolled out a "fix", yet the sign into null issue persists and a proper redirect is not occurring.

As a reminder (and maybe a help in debugging) the simulator works fine - I would focus some attention on the role either the device or Face/TouchID play.

Running the app attached to a debugger shows the failure we see. It looks to be exactly the same issue as the one originally outlined. The email attribute is required.

This is really disappointing as, on the whole, the Amplify ecosystem is a great. However, I could not in good conscience recommend Cognito as an identity provider in an enterprise environment. Bugs happen but the level of communication and the timescales involved are unacceptable at this point. We will be forced to migrate to Auth0 as we cannot block production releases any longer waiting for a tested and complete fix.

[oliverandersencox]

is there really no info on how we call fix the 'null' showing on apple login with a hybrid app??

[bhaweshtanna]

Any update on "null" showing on apple login. we need to go to apstore and we fear that the app will be rejected for this reason

[camin-mccluskey]

Just tried to debug by using the hosted web UI on my browser. Inspecting the network packets I noticed the call to the /oauth2/authorize endpoint contained a request with an empty scope array, when signing in with Apple - which doesn't seem correct. I couldn't manage to verify the scopes sent for Google or Facebook but the sign in occurred nominally (as it does using the SDK).

However when I look into the url params set it seems that in both the Facebook and SIWA case there is actually comma (%2C) delimiting between the scopes, I thought space delimiting (%20) was the expected behaviour? In any case, replacing the commas with spaces in the url params does not affect the login behaviour - Facebook and Google sign in continues to work but SIWA does not. Indeed I was wondering if FB and Google could handle any delimiter between the scopes and found they're perfectly happy to accept + also. So again, not really sure why this was thought to be the issue.

It would appear the scopes are not being sent correctly for SIWA and, for those of us who have configured email as a required attribute on our UserPools, this is causing sign up to fail.

[camin-mccluskey]

We resolved our issues - potentially this might be of help to everyone here. Our team had test accounts with iCloud accounts registered for the app but no Cognito users (because of the earlier issues). This left the sign in, in a broken state whereby to Apple any attempted login was not a first login and hence the email was not being sent back, causing a failure to add a new user to the User Pool. Removing our iCloud accounts from the app resolved the sign in issues. We will continue to test.

To deregister your iCloud from your app - on iOS.

Settings > tap your name at the top > passwords & security > Apple ID logins > App-Name > Stop using Apple ID

Hopefully this will be of help to at least some in the thread!

[markmckim]

Thanks @camin-mccluskey unfortunately this isn't our issue. I did spot this a while back and even deleting our previous sign-ins makes no difference unfortunately.

Edit: I actually tried deleting my user from Cognito AND my Apple device and now I do seem to be able to Sign In using Apple....progress!!

However I am still seeing a blank icon and "null" for the app name. Any ideas?

[camin-mccluskey]

@markmckim Great news! We still have the "null" for app name issue but our logo is populated. I'm not sure if there is some undocumented config we're missing or something like that. Again, it is strange that the "null" issue only happens on Face/TouchID authentication. Switching to iCloud email + password and you see the app name.

[markmckim]

Thanks! Yeah if we can figure out these last few issues and hopefully get some feedback around ETA for future issues, it might be enough for me to pause the migration to Auth0 and stick with Cognito. I really want Cognito to work, but turnaround on issues like this are a concern for me on production systems. Other than that, it’s a great product!

[rachitdhall]

Thanks for reporting the null app name issue. We are investigating it and will update here as we learn more.

If you are still facing an issue with scopes, please open a new Github issue as we will be using this one for the app name.

Rachit
Amazon Cognito

[alexabidri]

I am also facing the issue with the "null" app name and created a topic in the apple community

https://forums.developer.apple.com/thread/129899

Please guys support this thread to raise the issue to Apple as I truly believe this is a native issue from iOS

[lucianomlima]

Now we have a deadline: https://developer.apple.com/news/?id=03262020b

[t-moedano]

Any news about the null issue? It is still happening to me

[t-moedano]

It is been close to a month that the null issue is know by the team I see no answer for this problem. We are concerned that Apple will not accept the app showing null in the Sign In. Could anyone please give if at least we have a progress on that ?

[alexabidri]

@t-moedano I opened a ticket to apple through https://forums.developer.apple.com/thread/129899 + https://feedbackassistant.apple.com/
They may reply me soon.

Just to let u know, my company has the issue since 5 months, still our app got approved many times. I would be surprised if you got rejected for this issue.
From what I conclude, this issue is an iOS issue. FYI, I even dont use aws amplify. Apple should fix it by themselves. We just need to be patient!

I will update this topic as soon as I receive response from Apple.

[t-moedano]

@alexabidri Thank you very much for the information! I saw the thread in Apple also but it is good to hear that someone is looking at this problem. And it is a relief that Apple is not reproving for that.

Thanks again for clarification =)

[cabeaulac]

I also have the null app name. Looking forward to a fix!

The other login failure issue after removing your cognito user is "expected behavior" and there's a reference to it here.
https://aws.amazon.com/blogs/security/how-to-set-up-sign-in-with-apple-for-amazon-cognito/

If you decide to increase the requested scopes and want the additional information from existing users, those users will have to go to appleid.apple.com and, under Apps & Websites Using Apple ID, select the application, select Stop using Apple ID, and then federate again using Sign in with Apple.

[manusharian]

We hit the same problem. After configuring the apple service and cognito user pool we face the same null problem when trying to sign in (there is also no icon). This happens in an expo project (standalone app). After entering the passkey or password (we did not test on face/touch id yet) we got redirected to our app but receive the following error: RedirectUri is not registered with the client, under signIn_Failure event from HUB. The new user is created in cognito pool. The same error does not appear when we test the app within expo, where we receive signIn event from HUB and everything is ok, expect the null and icon problems.
Cognito settings: we followed this thread and created a new user pool with no attributes required. In sign in with apple we put our service, team and key id + the private key and checked email and name scopes.
Apple service: we put for the url and redirect : doman.auth.eu-central-1.amazoncognito.com and https://domain.auth.eu-central-1.amazoncognito.com/oauth2/idpresponse
We also checked the sign in with apple feature in our app id. We also try with federated identities since we use those for facebook and google but there we hit other problems.
Any advise is appreciated!
Edit: in TestFlight the logo appears, but yet again the signIn_failure is present.

[asp3]

having the same problem: Do you want to sign in to null. Looking forward to a fix as the apple deadline is approaching!

[oliverandersencox]

Is there really still no fix for this?

[allens01]

Any update on this issue? I am still seeing the sign in to null issue and the Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0Aemail%3A+The+attribute+is+required%0A+

[ehtulhaq]

One of the many reasons i'll have to reconsider amplify in the future projects

[undefobj]

All - As others have stated this is an underlying iOS issue outside of Amplify control. However it appears that it is on it's way to being resolved, if you try to test on iOS 13.6 beta you should no longer see the "null" issue.

[ehtulhaq]

@undefobj I checked on v14 beta and I still see null in place of app name. Can you link to the apple issue where this is being tracked?

[timoschlueter]

@undefobj I can confirm that this is still an issue on iOS 14 Beta.

[alexabidri]

@t-moedano I opened a ticket to apple through https://forums.developer.apple.com/thread/129899 + https://feedbackassistant.apple.com/
They may reply me soon.

Just to let u know, my company has the issue since 5 months, still our app got approved many times. I would be surprised if you got rejected for this issue.
From what I conclude, this issue is an iOS issue. FYI, I even dont use aws amplify. Apple should fix it by themselves. We just need to be patient!

I will update this topic as soon as I receive response from Apple.

Confirming @undefobj message, the issue is now fix on the lastest 13.6 public beta. After having this issue for more than 8 months and contacted Apple many times, it has been resolved by them now!

If it still doesnt work on iOS 14 Beta, this is mainly due because IOS 14 beta has been released to deliver brand new changes and features, not currently to fix this type of issue. 13.6 beta is there for that. I am almost sure that Apple will bring the fix in the official ios 14 release!

[joebernard]

Does this mean the app could still be rejected by Apple if it targets any iOS version below 13.6?

[timoschlueter]

@joebernard our app has been accepted by Apple even with the problem. The app is live on the App Store and shows „null“ to every user using „Sign In with Apple“.
Maybe we were lucky, but the bug has not been an issue for us other than users asking for an explaination.

[undefobj]

I'm unsure about iOS 14 as thats still in preview mode, not public beta. iOS 13.6 beta is what we've tested that seems to resolve the issue.

[hashamhabib]

Any update on following issue.

react native = 0.61.4
aws amplify = ^2.2.5

Hub.listen('auth', async ({ payload: { event, data, message } }) => {

event =[parsingCallbackUrl] Data = [{"url":"app://signin?error_description=Invalid+user+attributes%3A+email%3A+The+attribute+is+required%0A+&state=&error=invalid_request"}] message= The callback url is being parsed
event = [signIn_failure] message= The OAuth response flow failed
event = [cognitoHostedUI_failure] message= A failure occurred when returning to the Cognito Hosted UI
event = [customState_failure] message= A failure occurred when returning state

[kbokarius]

Kudos for fixing the null issue. We have one User Pool that works with Apple Sign In (for staging), but when we created a new user pool for production, we now get this error with a real iOS device:

error_description=Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0A+&error=invalid_request"

Similar to the one in the post above but with email instead of name. The two user pools are configured exactly the same and they point at two different Apple Service IDs. Seems like another Cognito/Apple bug.

[Reenagrg100]

@kbokarius I'm also facing the exactly same issue. In my case it is only working on "Dev" not on "staging" and "prod".

Did you get any update on this? Please share!

[kbokarius]

@Reenagrg100 unfortunately not. It appears that a user pool created a few months ago works fine, but newer user pools have this issue. I'm hoping AWS folks @sarahcec @@iartemiev have some insight.

[Reenagrg100]

So, what do you think @kbokarius is it the problem with Cognito or Apple? I'm not able to figure it out from which side it is breaking up. Also, any workaround this? then as per the scenario how did you handle it in your app?

[kbokarius]

@Reenagrg100 it's almost certainly Cognito. We have two user pools configured in the exact same way, one of which was created maybe 5 months ago, another that was created a week ago; the older one works fine, the newer one results in this error for Apple Sign In. Everything on the Apple side is configured the same way too, so it's probably a recent Cognito update that broke it.

I don't think there is a workaround. Our plan is to use the old pool that works for production, even though we originally created for staging. We were going to use the new pool for production, but because it fails with Apple Sign In, and if the AWS team doesn't resolve the issue by Oct, we'll be forced to use the old pool instead.

Fortunately we have a pool that works, but if you don't, then you'll probably have to wait until Cognito is fixed.

[Reenagrg100]

Okay, thanks for the descriptive update @kbokarius.
Well, in my case both the pools are created at the same time and for Dev one its working and not for others. It's looking very weird because both have exactly the same configurations.
Btw I'll be exploring more about it today, will update you as well if I get some solution.

[Reenagrg100]

@Reenagrg100 unfortunately not. It appears that a user pool created a few months ago works fine, but newer user pools have this issue. I'm hoping AWS folks @sarahcec @@iartemiev have some insight.

Kudos for fixing the null issue. We have one User Pool that works with Apple Sign In (for staging), but when we created a new user pool for production, we now get this error with a real iOS device:

error_description=Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0A+&error=invalid_request"

Similar to the one in the post above but with email instead of name. We user pools are configured exactly the same and they point at two different Apple Service IDs. Seems like another Cognito/Apple bug.

Hey @sarahcec @iartemiev I read above conversation as well but I'm still facing this issue, please let us know if there is any update on this. It is very urgent to solve this issue quickly else we need to use some 3rd party service other than AWS. I think this feature is need of every app who uses any kind of social authentication. Please provide any solution asap.

[Reenagrg100]

Hey Guys,

I read out the above whole conversation and found that lots of people also faced this kind of issue and I was also facing this similar issue since yesterday morning.
_error_description=Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0A+&error=invalid_request"_

Let me first explain what was the issue in my case:

I'm using 3 different environments DEV, QA, and PROD in my project. First I started with setting-up on DEV, it worked fine. Then I moved to QA, did the same config set-up on both sides: Apple developer's account as well as on Cognito side.
So, before moving to the app integration part, I first started testing it using "Hosted UI" from Cognito/App Integration/App Client Settings. Because we know there is not much on the App's side. So if its working using Hosted UI, it will be working from the app too.
Through Hosted UI, I saw that on my QA environment, when I'm attempting to login, the "authorize" API is a success in the "Network" tab in the console. But, in callback URL which we provide from Cognito/App Integration/App Client Settings, it is showing me this _error_description=Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0A+&error=invalid_request"_
error instead of showing the code="Xyz" which I was getting in DEV configuration in the case of successfully signed up/signed in.

What all I tried to get it to work?

• Created different Service IDs for each DEV, QA with a single private key for all.
• Created different Service IDs for each DEV, QA, and private key for each.
• Created different Service IDs for each DEV, QA, and private key for each.
• Added the domain names for all under "Website URLs" of DEV service Id.
• Disabled and deleted the whole Dev config for apple sign in from Cognito and tried only for QA(single pool at a time).
• Disabled and deleted the whole Dev config for apple sign in from Cognito and re-configured everything on Apple's account side.

So, in all, I tried with all combinations which could be possible because I was not getting at all why I'm facing this issue, so I was just doing hit and try but none of them worked.

Then what is the solution?

So, while doing all these hits and try, one of them converted into a fix.
So, after analyzing and exploring more around that fix I got to know that if a user is already registered via Apple sign-up no matter which is the pool whether the same(QA) or other(DEV) (in my case), what matters is that if it is registered using same TEAM ID/APPLE DEVELOPER ACCOUNT. Also, the service ID doesn't matter.

So, what exactly happening here is that Apple only gives "Name" on the first request (while sign-up) and after that, it won't give us the Name. Although gives all other attributes like email, token id expires in, etc. This all I got to know just by doing research around it, this thing is not documented anywhere neither on AWS side nor Apple.

Please note:
If you want to use multiple environments simultaneously( dev, QA, prod), you can do it either way by creating different service Id for each or by adding all domains for each under a single service ID. Only the thing which needs to note is that we use different accounts every time for each sign-up, no matters if the user is registered under a different pool. Because there is no way till now to get Name again from Apple. So, the only way in our hand is to use a different account, because if you are using the same, if it's in the same pool, it will authenticate the user but if it's in different neither it will be able to authenticate (as the user doesn't exist under that pool) nor it will give us the Name again as it won't consider it as a first request.

So, I request the community to add this point somewhere so that people don't need to dig it into so deep.
Tagging you guys also @kbokarius @sarahcec @iartemiev.

If still anybody has any concerns/questions you are most welcome. I'll try to reply to the earliest.

Thanks !!

[kbokarius]

@Reenagrg100 that makes sense, thanks. So in that case, how do we use multiple different environments with the same Team ID/Apple Developer Account? We obviously want to store the Name in each of our environments (stage, prod), which means that we would need to receive the Name field more than once. Is there a way to force Apple to provide it again? Is there another workaround I'm not seeing?

[Reenagrg100]

Thanks for asking this @kbokarius as I forgot to mention this above. You can now look at my reply again to find the answer to your question.

[manusharian]

I had to create a new "User Pool" with no email required because "Sign In With Apple" doesn't send name or email or both in some cases, I had to migrate all of my environments, now Apple approved my app.

Hello,
I had similar problems but in this thread I found the quoted message which stated that Apple sometimes do not provide name, email or both. If I recall correctly when you login with Apple for the first time you have the option not to share name or email with the app. Therefore the app should consider not receiving this information from sign in.

[Reenagrg100]

@manusharian no this is not the case that sometimes it gives us or sometimes not. It is fully certain that it gives Name only on first time and email every time. even if you are hiding the email, it will auto create an email for you and will return everytime.

[kbokarius]

@manusharian how would you handle a situation where Apple doesn't send back a name? Wouldn't you need to know in advance and not request it?

The problem is that it's not currently possibly to use Apple Sign In for the same iOS app, same Apple ID, but two different Cognito user pools.

[manusharian]

@manusharian how would you handle a situation where Apple doesn't send back a name? Wouldn't you need to know in advance and not request it?

In our case we created the UI for the user to insert their name. We use cognito only to login and keep the password safe. Anyway the name will be display in our app (user profile), so we just ask for name if there is no name. This happened only on Apple, since on FB and G+ we do not faced this.

The problem is that it's not currently possibly to use Apple Sign In for the same iOS app, same Apple ID, but two different Cognito user pools.

I misunderstood the topic, since we asked for the name we did not faced this error, yet.

[kbokarius]

@manusharian how do you determine if there is no name? Does Cognito just pass back an empty string for the name?

[manusharian]

@kbokarius no, it will not pass a name. We use redux and the name will be undefined. We have the following flow, first time the user logs in we launch onboarding sequence and there we ask for the name if not provided (on Apple signing situation), afterwards we use DynamoDB to store info about the user, including their name. Therefore, on next login we already have the name in DDB and we do not relay on Cognito, using it only to see if the user is logged on, refresh tokens, and keep the password safe.

[kbokarius]

@manusharian got it. What's interesting is that on our end, using iOS's native Apple Sign In UI, the user is only asked whether to show their email, not their name. So we always get the name if it's the user's first time signing into one of our Cognito user pools. We still run into the issue of Apple not sending the name again when using a different user pool, but that's a separate issue.

[kbokarius]

We just tested Cognito's Apple Sign In with iOS 14 and we're no longer seeing the native Apple Sign In UI on the device. We're instead seeing the web sign in UI. We went directly to our Cognito Hosted UI page in Safari, tapped the Sign in with Apple button, and instead of seeing native Apple sign in UI we see the web UI.

Is this a known issue? Are others experiencing this?

[ehtulhaq]

Any updates on this? I'm encountering invalid user name attribute error when signing up with Apple and Apple rejects my binary because I can't remove Apple Sign In. AWS cognito doesn't let me change the name to be not a required attribute..AWS team are you even looking at this issue? Last update i see is from Jan that you guys are working closely with Apple. What happened after that?

[rjuevesano]

Hello. Is it possible to show the apple sign in without showing the in-app browser? And how to do that?

[oliverandersencox]

@rjuevesano nope! Even if you use the ionic apple login, and then pass the credentials to the federated login, it still redirects you to the browser which seems ridiculous