So @aaronpk actually provides an example of users being able to edit their names at least in the JS. This makes me feel MUCH MORE comfortable with it. https://twitter.com/aaronpk/status/1137149365120786432
WeChat ID
aaronpk_tv
-
rabble
https://twitter.com/rabble
•
Jun 8
I hope I’m wrong. Looking at the ui it shows users being able to not provide it but I can’t find info in the code about that.
Their docs are wrong in a few places and are missing a lot of info. -
rabble
https://twitter.com/rabble
•
Jun 7
@aaronpk Am i correct in reading through the apple sign in that they're protecting the privacy of your email address with a proxy but then giving everybody who asks for it your full legal name?
They actually have a way you can edit the name that's sent back to the app!
-
Rory Macdonald
https://twitter.com/tworymacdonald
•
Jun 7
Nice write up 👍 Did you find the anti-fraud Real User Indicator capability surfaced using JS API? Available as credential.realUserStatus property in native.
Nope, haven't found that yet! It's missing from their docs too. I'm going to keep playing with it though. -
-
David Waite
https://twitter.com/dwaite
•
Jun 6
@aaronpk Most surprisingly interesting thing I got from https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple - you managed to get http://example-app.com -
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
Just for the uniqueid. Verify that the uniqueid is not modified.
verify where? The unique ID comes back in the ID token not the access token. (also happy to take this to DM) -
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
So talked with the Apple engineers here at WWDC:
They don't have that endpoint, they also will not expose user_info or a revocation endpoint. The user_info will only be sent once and only once then you will only get a unique id again. Only scopes available now are name and email
Another question, if there is no `user_info` endpoint, what are the access token and refresh tokens for? -
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
Yep. That seems like a bug. If you forget it well you are left without it. You should be able to request new scopes...
Progress! I now get the screen which lets me edit my name and choose the email to share. I only see that the first time, all subsequent requests show a confirmation only.
Still no luck actually getting the email address back in the ID token though. -
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
That is not a bug that is feature. They told me they will only give you the info once. Probably why scope won’t matter after your first invoke.
I will go test this out with new app credentials though to confirm. Thanks for the lead!
-
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
That is not a bug that is feature. They told me they will only give you the info once. Probably why scope won’t matter after your first invoke.
interesting. well the bug is that I have *never* gotten it, because I didn't request it the first time, and now I can't request it ever again.
-
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
So talked with the Apple engineers here at WWDC:
They don't have that endpoint, they also will not expose user_info or a revocation endpoint. The user_info will only be sent once and only once then you will only get a unique id again. Only scopes available now are name and email
Just verified again, and I don't get back name or email address when I request "name email" scope.
I did find a bug where apparently Apple is ignoring the "scope" parameter after the very first time you authorize an app though, so could be related. -
Wizages - Sam Patzer
https://twitter.com/Wizages
•
Jun 6
So talked with the Apple engineers here at WWDC:
They don't have that endpoint, they also will not expose user_info or a revocation endpoint. The user_info will only be sent once and only once then you will only get a unique id again. Only scopes available now are name and email
Brilliant, thanks for the info!
Have you been able to successfully request name and email scope yet? It wasn't working in my testing. -
Thank you! You helped me track down a deeper problem!
It turns out that you're right, having `scope` in the request causes Apple to return a 500 server error when confirming the login on their site before it redirects back to the app.
**However**, the really weird part is that Apple apparently completely ignores the `scope` parameter the second time you log in to an app, so there is no error.
The very first time I logged in to an app while testing this code I didn't include the `scope` parameter, so it worked. Then I added the parameter to see if I could get it to return an email address, and it didn't. It also didn't fail, because I had already logged in once.
I was having trouble logging in with a new App ID I created, and this is the reason! I just tried removing the scope from my attempt and now I'm able to log in with new App IDs.
This is very inconsistent behavior by Apple, so I hope they fix it later.
