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

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