amplify-js: Sign In with Apple failure

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!

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?

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

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

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 <MY APP NAME>”, but when testing on a real physical device, the FaceID prompt says “do you wish to sign in to null”

Why is this stale? I experience the same issue and don’t find any solution provided here.

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

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

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

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 !!

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.

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!

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.

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.

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

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

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

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

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

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

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

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

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

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!

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

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

Guys, I had similar problem. Namely: error_description=Invalid+user+attributes%3A+name%3A+The+attribute+is+required%0A+&error=invalid_request

Cognito + Apple Dev Console were set up correctly. The issue was actually in collaboration between Apple and Cognito User pool.

The solution is to create a new user pool, where no parameters are required! I also added a client app without client secret.

Hope this will help someone. Happy coding!

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?

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.

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

@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?

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

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+

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.

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

@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

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

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

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