Notes on Sign In with Apple

Sign In with Apple is an authentication service by Apple similar to Facebook Login or Google Sign-In. Here are my notes on integrating it with website sign-in while working on a WordPress specific implementation.

Sign In with Apple is targeted at companies and services with existing iOS or macOS apps since the authentication flow uses the app icon from the primary App ID. While currently it appears to be working with new App IDs that don’t have a published app, that could change.

At core it uses standards such as OAuth and JWT which is awesome!

Requirements for Sign In with Apple

I didn’t have an Apple Developer membership until yesterday so I had to create and configure everything from scratch and it took a while. Here it is step by step:

Note that the authentication flow uses the app icon from your main App ID so I’m not sure how Apple intends this to work with sites that don’t have an associated app. Here is the authentication prompt:

Sign In with Apple login page after clicking on the Sign In button
Sign In with Apple authentication prompt with missing app icon.

Two-Factor Authentication

Apple users accounts must have two-factor authentication enabled to actually sign-in with their Apple ID. Visit your Apple ID account on your device or on the web to enable the Two-Factor authentication.

Sign In with Apple JS

Sign In with Apple JS is a simple integration for adding the actual Sign In with Apple button or link to the page. All it does is generates the authentication link based on the Service ID and the return URL specified in the <meta> tags in the page <head>.

The official JS library will also enable native Sign In experience on Safari (from 30 minute mark of this Apple video):

Native Sign In with Apple dialog in Safari on macOS.
Native Sign In with Apple dialog in Safari on macOS.

Your website or app will still have to include custom logic to capture the authentication responses from Apple and create users or sign-in users based on the response data.

Sign In with Apple REST API

Sign In with Apple REST API is used for fetching the Apple’s public key for validating the authentication responses.

How to Review and Delete Authenticated Websites

Websites using your Apple ID for sign-in can be reviewed and removed under the Security section of your Apple ID profile:

List of apps and websites using your Apple ID.

Related Research and Links

Open Questions

How to Access User Name and Email?

Currently the id_token in JWT response includes only subject or sub field with a unique user identifier. The JWT reponse doesn’t include user’s name or email even when they’re requested in scope.

{
  "iss": "https://appleid.apple.com",
  "aud": "net.kaspars.mycustomid",
  "exp": 1559646675,
  "iat": 1559646075,
  "sub": "001111.532aa1f2229d4b70985bdbf913bb1ca1.2222"
}

Normally the authenticated name and email would be included as separate fields in the decoded id_token.

3 Comments

  1. Yura says:

    An authenticated name and email will never be included as separate fields in the decoded id_token because (quote):

    The modified name is only shared with your app and not with Apple, and hence isn’t included in the ID token.
    https://developer.apple.com/documentation/signinwithapplerestapi/authenticating_users_with_sign_in_with_apple

    Instead they should be present in json response under separate key ‘user’. Note, it will be there only the first time user logs in as per (quote):

    The API collects this information and shares it with your app the first time the user logs in to the app using Sign in with Apple. If the user then uses Sign in with Apple on another device, the API doesn’t ask for the user’s name or email again.
    https://developer.apple.com/documentation/signinwithapplerestapi/authenticating_users_with_sign_in_with_apple

  2. Nikodem says:

    I believe that something changed since this article and email is now included in the idToken along with email_verified and optional is_private_email fields. These two additional fields are booleans transferred as strings. This first one was always true for me (Apple does verify all e-mails used in AppleID so I expect this field to contain true every time) and the second one appeared only when I decided not to share my own e-mail address with the website/app (therefore using Apple’s private relay and ending with is_private_email being always “true”).

    I’m not sure if it stays, cause it’s not documented and I still haven’t released the Sign in with Apple feature to production, but all my test idToken’s included the email field.

Leave a Reply