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

Can anyone verify if they're seeing this change active? I'm not seeing any email returned - for subsequent authorizations - inside the JWT or in the body of the POST callback, nor am I seeing it in the ASAuthorizationAppleIDCredential in the native iOS framework.

yes can we parse the name from the /auth/token call?

Hi cooper,

Please file a radar / feedback assistant item if you havent done so already.

Appreciate the feedback, unfortunately I can't provide more information on name being returned during follow up authorizations at this time.

Having email provided for follow up authorizations is great. However, if you are considering to add the authorized user's email of follow up authorizations into ASAuthorizationAppleIDCredentialidentityToken > identityToken, please consider to add it into ASAuthorizationAppleIDCredentialidentityToken > email as well. I am developing a native iOS app, and parsing the email from identityToken is not straight forward in a native iOS app. It will require adding a 3rd party JSON Web Token Parser to my project (as there is no native iOS API for parsing JWT), instead of simply getting it from ASAuthorizationAppleIDCredentialidentityToken > email. This is an extra work that I (and probably many other iOS developers) would much prefer to avoid. Any thoughts?

Have this been deployed yet? thank you!

I'd like to +1 the concerns here. I have a native app with an AppEngine backend.. a RESTfull server. I don't explictly need the email/name for my game though it does help me when users need support. For those developers that do need the data think it should be supplied each time you ask for getCredentialStateForUserID or some similar command (getCredentialForUserID?)

The part I'm scratching my head about is the "credential.authorizationCode". I see we get that on the inital login and I have been able to verify that code with https://appleid.apple.com/auth/token but doesn't that code expire in an hour (at least that's what the return payload suggests)? Wouldn't I need to get the current code from the credential with each REST call to my server so I can verify identity on the other end? That's what I do for Facebook login.. with each REST call from my app I attach the [FBSDKAccessToken currentAccessToken].tokenString] and verify it on my server with Facebook (I do some memcaching on the server side it's not calling the fb servers every time).

How do I continually verify seperate REST calls to my server from a user over time? What's the proposed pattern? If there's a doc page that describes this flow please let me know.

Thanks D

Can you please indicate if there is any update on the deployment date for getting email for follow up authorizations?

We've also stumbled across this problem and would need the email address with every call. I don't think it makes sense to save an additional external Apple ID for the reasons mentioned above (user is lost in case of error). It would be great if you would also send the email in the following calls.

While the email address isn't returned in every call, the JWT containing the email address is.

The email field in ASAuthorizationAppleIDCredential will be blank.

/** @abstract An optional email shared by the user.  This field is populated with a value that the user authorized.
     */
    open var email: String? { get }

However, you can parse the JWT to get the email.

    /** @abstract A JSON Web Token (JWT) used to communicate information about the identity of the user in a secure way to the app. The ID token will contain the following information: Issuer Identifier, Subject Identifier, Audxpiry Time and Issuance Time signed by Apple's identity service.
     */

    open var identityToken: Data? { get }

To parse the identity token, you can use a Swift JWT Decoder library (of which there are many) or decode and parse it yourself.

I was able to retrieve the email each time using this technique.

@dima_beliy - You mentioned that the change to include email in id_token had not yet been deployed. Is that a) confirmed, and b) deployed? I think I might just be seeing some new behavior...

Hey dank,
I am facing the same issue. How are folks solving this? Did you arrive at a conclusion?

@dima_beliy any news when this change will be deployed? Thanks

Solution works great for native, impossible for desktop or mobile web. Apple should require a success confirmation via GET request that data is saved in the callers database before pulling something like this...

Any news on this subject? We also need the email for our solution to be able to have the best possble user expierence...

Thanks for the reply!