Thanks Alex. Where do you see the biggest gap that will help you push forward?
I have so many questions for you! I was able to create a proof of concept, but would love to know some of the missing details. The current documentation is not complete enough to make a working app, I had to guess things based on my knowledge of OIDC.
Excellent thread - just to clarify with another example since Google do identity & calendar - if my app needs OAuth to (say) read playlist data specifically from Spotify via their dev API & do nothing whatsoever user ID related with them, I don’t need “Sign In With Apple”?
Yes that is my understanding reading their guidelines. Of course this remains to be seen how it will play out in practice.
@aaronpk This is a great resource, thanks! Is sign-in still working for you, though? I'm seeing the Apple sign-in page throw an error in my testing after I authenticate (though it's possible there's an error in the setup).
It's working with the first app I registered in the portal, but hasn't worked with new app IDs I've made since! I'm guessing some weird Apple but that they'll probably fix soon. This is all clearly very early beta right now.
Sorry @aaronpk, I got a bit confused. Maybe my question is very simple, so the purpose of login with apple is for authentication or not? You called it Oauth provider as they don't have a user_info endpoint?
Yes it seems to be designed for authentication only. They do also return an OAuth access token and refresh, though I am not sure what you can do with that yet.
Feels a lot like another way to lock users inside of the Apple world. How is this any better than signing up with any other service like Google or Facebook (for OAuth for example). It has some nice 'privacy' features but it feels like a marketing stunt more than anything imo
It will be set as the default (knowing Apple) and will make all other options so inconvenient that apple users will essentially have one choice. Just like how you can use Chrome on iOS, but they make it as inconvenient as possible to avoid the POS that is Safari.
It's still up to the app to provide the buttons. Check out the sample walkthroughs in that blog post.
you still need a trusted apple device to use Apple 2FA in addition to trusted phone number, don’t you?
I honestly don't know. But also keep in mind this is primarily designed for logging in to iOS apps, so ppl can log in with their Apple account instead of their Facebook account, which is a win for user privacy.
yes and how are you supposed to get through the Apple 2FA protection without an Apple device?
via SMS or phone call
> A trusted phone number is a number that can be used to receive verification codes by text message or automated phone call. You must verify at least one trusted phone number to enroll in two-factor authentication.
If you have a native and a web app, and a user creates their account with Apple sign in through your app, I wonder how you sign in with that account in your web app? Is Apple sign in basically just oauth with a fake email address you don’t know? And what’s your password?
Isn't there a single open standard being used under the hood by most of the big sign in providers now? I was under the impression that they're all OAuth or something?
I've been testing out the new API and it's definitely OAuth/OpenID Connect. But it's true that this will add more work for developers, both just getting this set up and also dealing with a new kind of account identifier.