Aaron Parecki
No, I would have expected the name and email to come back in the ID token the way that OpenID Connect normally works.
Alex Gheorghian
If I am a bank who is considering implementing this feature, and I am currently relying on obtaining email, device ID and IP address (among other things) in order to determine if any of these fields are associated with fraudulent activity, it sounds like I am going to be blocked from ascertaining this information both upon initial account creation as well as subsequent logins. Apple’s literature has a high level blurb about being useful in fighting fraud, however I feel that this feature will take away our ability to detect fraud. Am I missing something? Are there any workarounds? It seems like this feature favors fraudsters.
Redth
Great post! Unfortunately it looks like this service is very finicky. I keep running into the issue where I get to the page just after 2FA where I’m asked to continue (either with or without the name/email consent) whenever I click continue I just get a HTTP 500 error and the page shows “Your request could not be completed due to an error. Try again later.”. I feel like I’ve tried every variant of the authorize url (scope, no scope, etc) nothing seems to work. Is Apple’s implementation just messed up right now?
Redth
In case anyone else runs into this, I’ll share… Basically Apple’s configuration site lets you input redirect uri’s without a scheme. I put in <a href="http://blah.com/callback" rel="nofollow noopener" title="blah.com/callback">blah.com/callback</a> which it allowed. Then I had to use <a href="http://blah.com/callback" rel="nofollow noopener" title="blah.com/callback">blah.com/callback</a> as the redirect_uri which sort of worked but eventually failed with a HTTP 500 error. After I went back and reconfigured my urls to be <a href="https://blah.com/callback" rel="nofollow noopener" title="https://blah.com/callback">https://blah.com/callback</a> I could start using that as the redirect_uri and things started working.
tl;dr need to use full uri with scheme in the apple configuration portal otherwise things will fail silently with no good errors 
ticoli
Hello! That helps me a lot.
What is the best practice to develop, or to make automatic test?
For instance, facebook allows localhost for developpers.
Nikolay
Yes, it does matters. It doesn’t work with an Enterprise account.
Mohammed Shahid
Hey Aaron Parecki ,
Does the Email address of the user change on Signout/Signin with this Sign in With Apple Flow?
Siddharth
This is definitely a concern. Stopping email ID being shared would effectively prevent cos to maintain a list of fraudsters etc.
Charles
Hey everyone, trying to sort this out as the next version of my app is going to allow user profiles and I want to just jump straight into using apple to sign in!
The issue I am having is that when I return to the example redirect url, it works fine ish. But when I return to my apps dedicated redirect url I am getting the error “Authorization server returned an invalid state parameter” because the states are not matching.
Any insight as to why this might be happening?
Thanks!
Charles
To clarify more, I understand what the issue is, but I do not understand why it is happening. The app is not live by any means and the url is so out of this world I have no concerns like above mentioned ‘someone could e trying to trick your app’.
I have gone to the extent to output the $_SESSION[‘state’] and $_GET[‘state’] in a legible manner and verified they do match, but when the apple website callback to my domain the $_SESSION[‘state’] returns nothing, zip, doesn’t exist?
Further to note, this problem has occurred on two different macbooks, an imac, an iPad, and 2 iPhones
Any help is appreciated.
Charles
Gemma
Hey great post! I found the user data so thought I’d share 
The user email and name are returned only the first time you make the request. In the authorize request you get it back like:
{“name”:{“firstName”:“YourFirstName”,“lastName”:“YourLastName”},“email":"randomstring@privaterelay.appleid.com”}
where email can be either real or fake.
The token request will also make this data available with the first request, you can access it with claims[“email”] for example
Hope this helps someone!!
Aaron Parecki
wow thanks for tracking that down! That’s super buggy on their end!
Dgol Hoot15
@disqus_aOpjLqq5Hj:disqus this sounds promising, but can you please clarify on how you were able to get the user context back? The first authorize endpoint is called when clicking on “Sign in with Apple” and then you’re immediately redirected to Apple’s servers to sign in. After signing in you’re redirected back to your server with the code. But when making the request to auth/token, the response does not carry any user info…
Gemma
Hi! The redirect contains this user info the first time it is used for that user along with the code as long as you have added them as the scope in the authorize request. The best way to force the ‘first time’ is to go to https://appleid.apple.com/a… and under Security → APPS & WEBSITES USING APPLE ID remove your app. This means that Apple will treat the next time that user uses Apple sign in for the app as a new user.
Also when authorizing the user for the first time using the ‘code’ you received the user token which will contain ‘email’ when you decode it Again, to force this first time experience you can remove your app from your user.
Dgol Hoot15
Ah, I see it now - thanks!
Martin Poirier Théorêt
I am planning to implement Apple Sign In really soon (like now) and I have a flow that I am not sure will work.
I’ll explain the flow we have on facebook that I am trying to mimic.
On any app (Apple, Android, Html/Javascript) we are using the sdk to connect the person. Once they have the connection token they call our api endpoint to connect “via facebook” and they send me the token. From there I call facebook and get the facebook id, email, etc… That I need and configured via the scope.
From there I find/create the associated user, generate a app token for that user and we use this token. After that we don’t care about the facebook token since we are using our token. If someone log off and log in again we will use a new facebook token and will be able to find it via the facebook id.
Now, from what I read in this thread there is no Apple API to get the name, email, etc… ? From the server point of view I would want only to receive the token and fetch the information from apple. But the flow with the redirect url would provide this information only on the redirect/first request… That doesn’t seem to be a option with the flow I am explaining, there is no server side redirect involve everything is done client side.
Max EJ #23
Hi !
So far this post helped me so much, however, I now get a “invalid_grant”.
Following : https://developer.apple.com… I understand that I have absolutely no idea about what’s this error about 
Does anyone have this issue? I am not that familiar with Apple and I have no idea in which direction should I go to track that bug down…
Max
Jeff
Excellent write up, thank you!
Алиса Руденко
Thanx you for the article, couple weeks ago I implemented the flow and everything worked fine. But now API doesn’t return email on first time auth. It can’t also be found in id_token. So if you’re trying to implement the feature now and don’t find user email, don’t be scared, this problem isn’t on your side. I’m sure that this depends on that new releases will be soon so they are in the middle of something.
Алиса Руденко
and one more thing-a page which allows you to hide or show your email doesn’t appear anymore.