Why isn't the user data being returned every time?

I am implementing Sign in with Apple using the JS framework.

When the user (me, right now) signs in for the first time, I get data I need!

The parameters look like this


Parameters:

{"state"=>"[state]", "code"=>"[code]", "id_token"=> "[jws token]", "user"=>"{\"email\":\"[the email I need]\"}"}

My scope is just "email," I don't need (or want) their name.


Next, I try signing in again (same everything)


But, I get this option

When I click "continue" the data looks like this


Parameters:

{"state"=>"[state]", "code"=>"[code]", "id_token"=> "[id token]"}

As you can tell, there is no user object, no email, nothing I can use!



If I do the code response and get an access token, I can't use it. There's no public, known endpoints to just get the email they used. There's no point in storing the email if I can never check for it the next time they sign in.


This is happening on multiple browsers on macOS 10.14.4.



On my iPhone running iOS 13 developer beta 3, every time I click the button, I get the option to "share" or "hide" my email (even though, as shown above, I've sign in before), and sharing the email actually shares it, while hiding it.. well hides it.

However, the user data is always there.



This bug(?) only appears when clicking Continue, which I can assume appears on devices that aren't running iOS 13. It's quite a problem on devices that aren't this small set of devices, so I hope this is either known, easily fixable, or something! Thanks for any help you can provide.

Hello guys.

Any update about this topic? How was it supposed to match to the same user if the email is not provided every time? Do they provide an trust-able id? I don't really get how it's supposed to work...
I got the same issue, It's unfriendly to our web application
We're hitting the same wall that you guys have hit. It's so annoying that user information is not getting back in the response at every time. Any update on this Apple?

We are to able to extract email from identity token in subsequent api call as mentioned in documentation. However it is encouraged that you use user identifier to uniquely identify users.

While Apple provides the user’s email address in the identity token on all subsequent API responses, it doesn’t include other information about the user, such as their name. When you receive user information from the API response, immediately store it locally so your app can access it again in the event of a process or network failure.

https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple#:~:text=While%20Apple%20provides,or%20network%20failure.

I know this thread is fairly old, but the issue still exists. On that note, I'm frustrated because Apple enforces the use of their sign in solution on anyone who wants to include other social sign in services such as a Google or Facebook. Sign in with Apple is probably the most unsupported sign in service available. Terrible documentation, lack of SDKs for multiple languages and issues such as the issue described in this thread are all evidence of this.

This apple sign in is horrible and I am stuck when apple ask to use sign in with apple id as equivalent because I am using google sign in. I face the same issue here. If we store it locally to the mobile we are able to detect in database which email is sign in. and update the time login or use it for other purpose. But the problem is when user change their device and try to sign in with the same apple id, how we know that the sign in is from the same apple id as before since the sign in response like email only return once for the first time ? This is not a good experience and workflow to sign in.

Worst decision ever: Both Google and Facebook make no distinction between the SIGN-IN and SIGN-UP, but Apple YES. In this case, instead of handling both situations in one shot (LIKE WE DO WITH ALL OTHER SERVICES), we have to distinguish both cases:

  1. SIGNUP (Praying that everything will work in your backend because in case of db connection errors you are lost): Take from ajax POST request the fields: name,email,token_id -> Validate token_id using apple api, check if the user already exists on db and if not exist insert and generate your app token, if exist just create and pass your app token.
  2. SIGNIN (Praying that signup has been completed without errors):
    Take from ajax POST request the only available field token_id -> Validate token_id using apple api and check if the user already exist. If not exist return error, if exist generate and return your app token

Sorry Apple but i consider a BUG not indicating here https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/configuring_your_webpage_for_sign_in_with_apple the real difference between SIGNIN and SIGNUP. You can't hide this huge conceptual difference within the single "Signin" term. By the way: this is the crucial JS part for those people going mad understanding the flux with this chaotic documentation AppleID.auth.signIn().then((data) => { if('user' in data){ alert("SIGNIN"); console.log(data.user.name.firstName); console.log(data.authorization.id_token); } else { alert("SIGNIN"); // data.user object DOESN'T EXIST, only authorization console.log(data.authorization.id_token); } }); When you are testing the SIGNUP case you have always to delete the permission inside your apple device Settings->Click on your account name->Password & Security-> App that use Apple ID-> Choose the app id associated to your site-> Stop the use of apple id.

4 years after the inital post we are still stuck on this issues. Apple please, HOW ARE WE SUPPOSE TO MANAGE ERRORS WITH YOU SIGN IN SYSTEM ?

oh hell, I hope nobody could read (again) my public name and fake email 😅 this is the "remove charger from the box" of developer experience, btw the solution of remove from icloud is not working for me

Why isn't the user data being returned every time?
 
 
Q