App Store Guidelines with iOS 12.4 and lower

Apps with SDK version below 13.0 can use Sign in with Apple JS.

Hi Dima,

Can you clarify if we'll be blocked from releasing our apps if we only support Sign In With Apple for the iOS 13+? Is Sign In With Apple JS a required implementation if we support iOS versions lower than iOS 13.0?

Thank you,
David

Sign in with Apple Guidelines

Apps that use a third-party or social login service to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. As you plan and design your app or website for Sign in with Apple, make sure to follow these guidelines. In addition, the Human Interface Guidelines include downloadable left-aligned, center-aligned, and logo-only buttons. New apps must follow these guidelines starting April 30, 2020. App updates must follow these guidelines starting June 30, 2020.

• For iOS 13 and later, macOS 10.15 and later, tvOS 13 and later, and watchOS 6 and later, use the AuthenticationServices framework as referenced here.
• For iOS 12 and eariler, macOS 10.14 and earlier, tvOS 12 and earlier, and watchOS 5 and earlier, as well as web applications which cannot directly access Sign in with Apple JS framework, you must manually control the sign-in request as referenced here.
• For web applications which can directly access Sign in with Apple JS, use the Sign in with Apple JS SDK. For communication between your web server and the Apple ID servers, use the Sign in with Apple REST API.

Additionally, as of 04 March 2020, the App Store Review Guidelines states the following—

4.8 Sign in with Apple

Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. A user’s primary account is the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.
Sign in with Apple is not required if:

• Your app exclusively uses your company’s own account setup and sign-in systems.
• Your app is an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account.
• Your app uses a government or industry-backed citizen identification system or electronic ID to authenticate users.
• Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.

I came across this post to implement sign in with Apple on iOS 12. Apparently, the two answers (from @ppinkney  and @dima_beliy) are in conflict:

For iOS 13 and later, macOS 10.15 and later, tvOS 13 and later, and watchOS 6 and later, use the AuthenticationServices framework as referenced here.
For iOS 12 and earlier, macOS 10.14 and earlier, tvOS 12 and earlier, and watchOS 5 and earlier, as well as web applications which cannot directly access Sign in with Apple JS framework, you must manually control the sign-in request as referenced here.
For web applications which can directly access Sign in with Apple JS, use the Sign in with Apple JS SDK. For communication between your web server and the Apple ID servers, use the Sign in with Apple REST API.

The above implies that Apple JS isn't for pre-iOS 12, but rather for other platforms.

Apps with SDK version below 13.0 can use Sign in with Apple JS.

The above states otherwise. Are they the same? Looking at the docs, it does not look like that.
As I last checked, App Review guidelines do not speak about this point at all.

In any case - I followed the link in the @ppinkneys post, and I get that in order to authenticate using Apple:

• GET (with params) must be issued to https://appleid.apple.com/auth/authorize using Safari (native iOS openLink API)

• The developer server callback URL will receive a POST or QUERY in the safari, wherein code and id_token are contained. At this point, past verifying the id_token, control must be handed back to the app.

Is this understanding correct?

If yes, according to this:

• there should not be any calls to token verification endpoint

• Also, none of this can be performed in WKWebView and must be done via Safari?

This is the most confused part of the documentation and is also crucial for managing our apps. If our app gets disapproved because of this, it is very time consuming to re-engineer, as it pertains to server code.

It will be desirable to have proper clarity on the steps involved. AuthenticationServices is great, but it just doesn't serve pre-iOS 13, where it is too easy to go wrong.