Closed ghost closed 3 years ago
I can replicate this also.
I have managed to narrow it down as follows:
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):
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
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
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.
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.
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
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.
Same issue when using Face ID and it does work when using username/password
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
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
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?
Hi @iartemiev any update on this? Happy to provide more information or help in any way.
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!
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.
@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.
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!
In case it helps anyone else, this post fixed my Invalid State/RelayState provided.
error: https://forums.aws.amazon.com/thread.jspa?threadID=310618
@sarahcec @iartemiev Is there any update on this? We are completely blocked on pushing updates to our iOS app. 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.
any update? my team and I we are stuck to publish in App Store
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.
@iartemiev thanks for the update, it's greatly appreciated! Can I ask what sort of timescale you might estimate - days, week(s)?
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!
@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.
@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
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
@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 @sarahcec Any update here? I really can't hold off much longer on this. Thanks!
@iartemiev @sarahcec Could we get an update? Some of us have been blocked for over 2 months with this issue.
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.
@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.
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!
@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.
@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.
I do believe there are two separate issues at play:
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 🎉 .
"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 @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.
is there really no info on how we call fix the 'null' showing on apple login with a hybrid app??
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
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.
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 @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?
@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.
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!
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
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
Now we have a deadline: https://developer.apple.com/news/?id=03262020b
Any news about the null issue? It is still happening to me
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 ?
@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.
@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 =)
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.
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:apple
user from CognitoAll 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?