I'm having the same issue. The first time I used an Apple ID for sign in, the name and mail fields were filled correctly. On every sign in afterwards, the fields are nil.
The different view is ok because you have to accept sharing those details only the first time, but afterwards you just login.
I ran into the same and found this about the name and email: https://forums.developer.apple.com/message/371251#371251.
I think it's intended in the ObjC/Swift framework too. The linked issue also has a reply about how to fake a first login by removing the app from iTunes account managing.
It drived me crazy for about two days as well so hope this helps.
This behaves correctly, user info is only sent in the ASAuthorizationAppleIDCredential upon initial user sign up. Subsequent logins to your app using Sign In with Apple with the same account do not share any user info and will only return a user identifier in the ASAuthorizationAppleIDCredential. It is recommened that you securely cache the initial ASAuthorizationAppleIDCredential containing the user info until you can validate that an account has succesfully been created on your server.
Thanks Patrictk, finally solved my problem
Btw, @Patrict, I'd like to suggest to add this behavior to the document, otherwise this behaivor is quite confusing (comparing to other third party login SDK)
So wait... If for some reason the first redirect from Apple gets lost for one of many VERY common reasons then we've permanently lost that user since there's no other way to get their information. There is NO other way to get this info?
Yeah, I'm having this specific problem. Our app is being used on locations with bad internet connection, and I'm already expecting people stating that they cannot signin right the very first time, and then we won't have their email, which is mandatory to create an account on our system.
weirdly enough even if I logout of iCloud, or remove the app, it doesn't matter. since the very next time they try to signin with Apple, if on the first attempt was unsuccessful, and we havent got their email, we won't be able to register again.
Question to Apple: what is more secure, sending the email / name (depending on the scopes) everytime we request it , or asking the users to "securely cache the credentials" which will leave breadcrumbs of the users identity somehow/somewhere (DB, keychain, some other store...) which probably could be accessable by other applications ?
Another relaeted quick question, if the user used signed in properly with their actual email, but then decide they want to revoke that and use one of the private emails Apple provides, is it possible ? Or after you allow it once , that's it ? It's possible on https://appleid.apple.com/account/manage
what is more secure, sending the email / name (depending on the scopes) everytime we request it , or asking the users to "securely cache the credentials" which will leave breadcrumbs of the users identity somehow/somewhere (DB, keychain, some other store...) which probably could be accessable by other applications ?
Or if something goes wrong downstream, we would have the customers complaining and support will tell them to go into AppleId website to revoke the permission, so they can properly register again. I believe this will be a poor experience and will make people not using this login mechanism if they start having this sort of problems.
Probably on places with good internet this wont be much of a problem, but our app is used on places with low coverage (3G even) and network calls do fail quite often, so the register flow could fail once or twice, and it could lead to problems
I'm having a problem with scopes.
When I request individuals scopes works normaly.
For example: "scope" => "email" or "scope" => "name".
But I need both. Email and name.
I already tried everything... "scope" => "email name" or "scope" => "name email" or "scope" => "email fullName".
No user data was received. No email neither name.
How can I get both?
It seems we just got this working after submitting a technical issue.
When you put the scope in the URL it must be percent encoded:
Ours was sending scope=name+email, which while in spec, was not working for some users.