Implementing a Seamless Way to Sign In … with Apple

7 min readDec 12, 2019

At WWDC 2019, Apple came up with a seamless, yet secure way to let users sign in. This Sign In with Apple solution is now required for all app developers that uses other social sign-ins such as Facebook, Google and others. Adding Apple’s solution on top of existing options sounds like a UI design nightmare for most major services.

However, it turned out that a lot more users preferred Apple’s solution over others in the project I worked on. In this entry, I want to summarize the benefit of Apple’s solution, and highlights from the talk at WWDC 2019 about its implementation steps. Before moving into Apple’s solution, I want to recap what other third-party solutions do and what Apple is trying to solve.

Why ‘Sign in With Apple’ Beats Passwords and Facebook | WSJ

Recap of other social sign ins

Instead of creating a new account with a unique username and password for each service, social platforms like Facebook, Google, and Twitter have provided sign in options to third-party apps using their accounts. For instance, when a user chooses to sign in with Facebook, the app will ask them to log in with their Facebook account instead of a unique one to the app.

Once their Facebook account is verified, a verified token will be provided to the app from Facebook to access the available information about the user. Typically, the information is the most basic information such as their name and email address. Users no longer need to fill their basic information with this social sign in.

How To Build Your User Analytics Funnel With Social Login | Auth0

Apps can ask for more private information like locations or their activities on social platforms. Although users can manage what information to share, many users may not bother changing those settings nor be able to find the option to do so.

User experience with Apple’s solution

Sign in with Apple is a more seamless experience on native iOS apps compared to other social media sign-ins. On iOS devices, users should have already logged in with their Apple account in order to download apps. After tapping the Sign In with Apple button, the modal shows up to choose if the user allows the sharing of their name and email to the app developer. After verifying with either Face ID or Touch ID, they should be signed into the account. It’s only a few taps without typing, and that’s it!

Requesting names and emails are optional for app developers, so these options should be suppressed unless they are essential to the service. Less requests make for a more seamless user experience. Even when a user gets a new device, they should be able to sign back into their same account easily, so apps should check for an existing account on the app’s initial startup.

What does hiding email address do:

When a user chooses to hide their email, Apple will generate a random email address that forwards mails to this user’s actual personal email address. Apple only shares this generated address to the app developer, so the personal email address will be private. In this way, this user can simply disable this generated email if the app developer starts to send spam emails.

Preventing duplicating accounts:

Many app developers have already had users create their accounts using different methods, and this new sign-in button could risk users creating a new account instead of signing into their existing account. The check-in process becomes especially tricky when a user chooses to hide their real personal email, which may be the common input to tie their accounts.

ASAuthorizationPasswordProvider class will detect and offer keychain credentials that the system already knows about, and the system will alert the user if there is an existing account that can be authorized with the password in the keychain. The user will simply need to confirm to continue.

In case there is an existing Sign In with Apple credential:

case let credential as ASAuthorizationAppleIDCredential:let userIdentifier = credential.user

In case there is an existing account in password keychain:

case let credential as ASPasswordCredential:

Apple also recommends App developers to provide a method for users to stop using other social accounts. There is no method provided by Apple to handle the migration, but it’s up to app developers to structure it.

Implementation

Adding Sign in with Apple button:

The implementation of the button is simple. You only need to 1) initialize the ASAuthorizationAppleIDButton class, then 2) add an action to this button.

Although the button’s appearance is customizable, Apple’s Human Interface Guidelines give suggested rules and styles for the implementation. Ultimately, it’s more important to design when to ask users to sign in, and how to explain the benefits of creating an account.

For example, creating an account may be beneficial for users when they want to:

customize the experience or product
save (bookmark) products
use products in cross-platforms (app and web)
submit something (opinion, images, or products)

Requesting authorization:

When the app requests authorization, it can optionally ask for users’ names and email addresses, as previously mentioned. These options have to be defined as the initialized request’s scope before performing it. Once it’s performed, the app will present the authorization UI to check with FaceID to return its verification results.

Getting verification and responses:

didCompleteWithAuthorization method will get an authorization object with the successful verification. When there is an issue with the communication or if a user pauses an action, didCompleteWithError method will return instead with an error. With didCompleteWithAuthorization, responses include the following items.

User ID — Unique, stable, team-scoped user ID
Verification data — A short-lived token for existing auth system or communication with Apple ID server.
Name and verified email (Optional)
Real person indicator — Apple judges if the user is likely a trusting human being or not.

Receiving responses with didCompleteWithAuthorization:

Handling state changes:

Apps should check if the credential state has changed each time they launch, such as when users sign out the Apple ID from the device, for example. getCredentialState method can be called to query this credential state using the user ID that the app retrieved in the initial sign in process. The method returns three states either .authorized, .revoked (when the state has changed, then the app should sign out from the Apple ID and lead them to sign back in through the Notification Center, for example) or .notFound (when there was no previous relationship found with this user ID).

Signing users back in to another device:

In the future, users who have created an account with Sign In with Apple may get a new device. To make the user experience smooth, Apple prepared an API to perform a request to check authorization through an Apple ID credential and a password stored in the iCloud keychain. This should be handled in app’s startup after the download.

Creating requests with Apple ID and keychain passwords:

let requests = [ASAuthorizationAppleIDProvider().createRequest(), ASAuthorizationPasswordProvider().createRequest()]

didCompleteWithAuthorization method returns with which credential was used to perform:

case let credential as ASAuthorizationAppleIDCredential:let userIdentifier = credential.user// Sign the user in using the Apple ID credentialcase let credential as ASPasswordCredential:// Sign the user in using their existing password credentialdefault: break

Cross-platform implementation

So most of the applications do not work only on iOS devices. Many provide some form of web services and some in other mobile platforms like Android. Apple provides Apple JS, the JavaScript SDK, which redirects users to an apple page where they can enter Apple credentials. With Safari, the web page opens up a native sheet, so users can sign in with a simple Touch ID to get verification in the case of Mac. As a result, the application expects the same values as you would get from the native API.

Implementing Apple JS for web

Include the library in HTML file:

<script src=”https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js">

Place a button div and optionally customize the style:

<div id=”appleid-signin”></div>

Configure request parameters and redirect URI where the results will be posted:

AppleID.auth.init({   clientId : ‘com.example.webapp’,
   scope : ‘name email’,
   redirectURI: ‘https://example.com/redirectUri',
   state : ‘state’});

Original post: http://www.ta-kuma.com/programming/implementing-a-seamless-way-to-sign-in-with-apple/