iOS must be able to send email / name

[aehlke]

Since as you write Apple only provides email or name on first sign in, it's the iOS client's responsibility to store that data securely (keychain) locally until it's able to confirm that it's been transmitted and processed by your backend. Or, your backend needs to be ok with never receiving those in case a user has network trouble or the app crashes or your backend is down and doesn't recover before successfully sending it from iOS.

In that case, I am having difficulty wrapping my head around what the Django endpoint should look like. How can I re-inject email into the payload sent to the backend? Or I suppose I can evaluate being ok with sometimes having no email and sending it separately afterwards once the client & backend can connect.

[lukaswuerzburger]

Hey, @aehlke! I'm glad you ask.

The iOS app only transmits a temporary authorization code from the Apple ID API to your backend. Then your backend gets the email and name from a separate call to the Apple ID API. The iOS client is not responsible to transmit email or name to your backend and won't need to store that in the keychain either.

If your request from iOS to your backend fails, then your backend won't perform this 'initial authorization' request and your app has as many tries as you want until your backend finally performs this initial request. You could only have a problem if you don't handle the response from the Apple ID API on the backend correctly.

Does that answer your question?

Best,
Lukas

[aehlke]

Ah, so the logic is that Apple continues to supply email (and/or first/last name) to the iOS authorization SDK response as many times as you call it, up until your backend uses the authorizationCode (and identityToken, tho I guess you're saying it's also unneeded) to connect with Apple.

I'm designing with network failure in mind (such as the backend making a request to apple but failing to get the response from Apple for whatever reason - such as a network failure on the response, or my python server getting restarted in the middle of a request to Apple; then the user trying again and the backend expecting Apple to supply the email but it doesn't this time).

But that's good if the window of failure is that backend request to Apple, not also the iOS app's request to Apple to the time that it completes sending it to your backend and having it processed.

Thanks for the help

[aehlke]

I'm seeing references from Apple saying otherwise about this, btw.

[lukaswuerzburger]

I'm seeing references from Apple saying otherwise about this, btw.

@aehlke could you reference them here, so we can further discuss?

[lukaswuerzburger]

Ah, so the logic is that Apple continues to supply email (and/or first/last name) to the iOS authorization SDK response as many times as you call it, up until your backend uses the authorizationCode (and identityToken, tho I guess you're saying it's also unneeded) to connect with Apple.

What I said ("your app has as many tries as you want until your backend finally performs this initial request") is based on the fact that you don't need the email and name that the AuthenticationService framework gives you on the app side, because that's for a different kind of authentication process. There are apps that don't do server-side authentication, thus, they use the email and name from that response. However the authentication process described in this repo is based on server side authentication and therefore the email and name from AuthenticationService framework is not needed.

If you want to use the name and email from iOS for your backend as a fallback, i guess you can create your own provider for django oauth, but i'm no backend expert. (@Seb0, @tuky ?)

[Seb0]

Hi, sorry I'm not currently involved in these topics, do you even have any more questions at the moment @aehlke ?

[tuky]

My first thought on using name and email from iOS is, that it makes your app vulnerable to malicious users spoofing that information.