We have a game that provides a mechanism to log into the game with Sign in with Apple in a direct integration between the game and Apple (first mechanism). We also provide a mechanism to log into the game using OpenID connect with authorization from Apple but using a server in the middle that drives the process (second mechanism). It is important to mention that both mechanisms use the same oauth client.
We have been able to switch from the first mechanism to the second successfully, but there is a problem with id_token.
In the second mechanism we request the scopes "email", "openid" and "name", but in the retrieved id_token there is no information about the email. It happens for all users who previously signed in with Apple using the first mechanism (therefore there is a current link between the game and the user in AppleId). It does not happen with users who had no link between the game and the user and use the second mechanism, in this case we can retrieve the user information in the callback of the first call and the email in the id_token, as stated in the documentation.
However, if users who had a link between the game and the AppleId delete the app and then log back in using the second mechanism, then we can get the email information with the exact same request.
The request we use to obtain the authorized endpoint information (https://appleid.apple.com/auth/authorize) has these parameters:
- response_mode: query
- scope: email openid profile
- nonce: ...
- state: ...
- response_type: code
Then we get the authentication code and get an id_token like this:
{
"iss":"https://appleid.apple.com",
"aud":"{aud}",
"exp":1705584621,
"iat":1705498221,
"sub":"{sub}",
"nonce":"7f-PqBoXgxeDMOEu5Ysov0FjE9GvSYfq",
"at_hash":"3kLcPBlwZP6aj_mscww5zA",
"authentication_time":1705498218,
"nonce_supported":true
}
Is there a way to retrieve the email for users who had the link and don't want to delete it or log back into the app? In the official Apple documentation it is stated that the id_token should have the email but this is not the case.
