Sign in with Apple: Let’s SIWA-t all the fuss is about

June 22, 2020

If you’ve ever used an Apple product or service, whether to download music, stay connected via Facetime or develop an iOS app, you probably have an Apple ID. Previously, this account was used solely to manage your various Apple services and keep data synced across devices. Now, with the release of iOS 13, Apple has introduced Sign in with Apple (SIWA), providing the opportunity for any application to support sign in using an Apple ID.

Why should you care?

As a user

As with most third-party login services, one of the main appeals of SIWA is convenience—bypassing account forms or email verifications and instead, using an account that already exists. It’s like having your basic information tied up in a neat little bow.

Now the next question, why might you choose to use SIWA over other third-party services such as Facebook or Google? For one, Apple puts emphasis on privacy and security. Apple’s two-factor authentication process is automatically applied to any account created with an Apple ID. Additionally, if you have face or touch ID enabled, you can take advantage of those sign-in methods when logging into a SIWA account on both native iOS apps and in Safari.

If you are someone who hesitates to share your email address when signing up for a new app or website, Apple created its private email relay service with you in mind. As it is, only a user’s name and email address are shared when signing in with Apple, however, users also now have the option to hide their email on a per-app basis. When selected, a random email address is generated as a stand-in. Apple then handles the forwarding of any communication to your true email address, allowing you to keep your address private, but still receive account correspondence.

As a developer

If you currently have an app in the App Store or are planning on submitting one, you may have to include SIWA as a login option. Updates to Apple’s review guidelines state conditions under which SIWA support is required.

The good news is, if your iOS app exclusively uses your own sign-in workflow, you should be able to continue on your merry old way. If you currently use any third-party login services, you now also have to support SIWA as an alternative login option. The deadline for adhering to these new requirements for both new and updating apps has thankfully been extended to June 30, 2020.

Getting Started

Apple has made it relatively easy to implement SIWA with its AuthenticationServices framework and available button resources. In-app modals make the workflow feel pretty smooth and the necessary configuration in your Apple developer account is even a breeze. Simply enable the SIWA capability for your App ID.

Not only can this new framework assist with handling a new SIWA button, but an automatic prompt can now also be displayed that allows the user to log in with either their Apple ID or a saved keychain password. While this ability to handle keychain passwords requires a bit more logic behind the scenes to manage efficiently, it is yet another way to provide a convenient login experience.

Something to note is that SIWA is only available for iOS 13 and up.

If your app supports versions lower than 13, you have a couple of options:

• Versions of iOS lower than 13 can support SIWA with an implementation similar to Android and other platforms (keep reading to find out more about that).
• SIWA buttons can alternatively be hidden or disabled on devices with older versions provided there is still an additional login method for those users.

Due to Apple’s focus on protecting personal information, a user’s name and email address are only made available when a user grants your app permission to said data. After that, Apple assumes the user has already created an account on your platform and thus, you no longer need that user data. The only way to get a second shot at acquiring this data is for the user to revoke app permissions in their account settings. Finding a way to communicate this with the user should be considered when determining workflow and error messaging to ensure a positive user experience. Keep this in mind if implementing SIWA on platforms other than iOS as well.

So What About Other Platforms?

Adding this functionality to iOS is one thing, but what if you are developing a project that is cross-platform? Can you add SIWA to Android apps and websites? Yes, but it may not be quite as straight forward. For platforms other than iOS, Apple has provided a JavaScript library called Sign in with Apple JS and a REST API, but the documentation leaves something to be desired. Alternatively, Firebase also now supports SIWA for iOS, Android and web.

Now, while there’s no explicit deadline, and it might feel odd adding SIWA to platforms other than iOS, it’s the use case that should be considered. The goal is always to offer users the best experience, which wouldn’t be the case if they were restricted to one platform based on their preferred login method. The most obvious solutions to remedy this restriction are providing some sort of account migration to a different login method or adding SIWA as an option.

For the sake of simplicity, I won’t be going too in-depth on the specific implementations of adding SIWA to Android or web. If you are trying to incorporate this functionality, I will point out some of the potential roadblocks and decisions:

Additional Configuration

Prior to implementation, you will need to create a Service ID in the developer console. This new ID will essentially act as a link between your existing App ID and corresponding apps or websites. During set up, it is crucial to have all the appropriate site domains and redirect URLs added to the configuration. These cannot be an IP address or localhost. Only the domains added here will be granted permission to request user info. Make sure these are domains you either have control over or you completely trust in.

It’s also important to note, for a web implementation, that the redirect URL sent as part of the authorization request must match the domain that the SIWA button lives on. Mismatched URLs will result in loss of the response sent back from the authorization request.

Web

When beginning implementation for web, you must decide to what extent, if any, you want to take advantage of Sign in with Apple JS. While Apple encourages the use of its resources, there are times when it might be more beneficial to try and handle more of the workflow in a custom manner. Whichever approach you settle on, both have their own potential hurdles to be conquered.

The manner in which Apple’s login page is displayed could potentially lead to one of these roadblocks. If choosing to redirect the current page to Apple’s login and eventually back, you will run into the loss of any session values that had initially been set. Most importantly, in this case, the state value.

Along with the request to Apple’s authorization endpoint, you’ll want to include a state*.* This value will act as a unique session identifier to later compare to ensure the returned response hasn’t been tampered with. If those session values are lost on redirect, so is the valid state needed for said comparison. While there are various ways this issue could be resolved, one alternative approach is to use Sign in with Apple JS and the dialogue it defaults to for login credentials. When using a separate pop-up, the session values remain intact and ready for when you need them.

Workflow aside, if you choose to use Sign in with Apple JS, be sure to test your implementation in a variety of browsers. As is to be expected, this library is optimized to work best on both desktop and mobile versions of Safari and includes the ability to use facial and touch identification when signing in with Apple. While in most cases, this library seems to work effectively but the most recent version of Sign in with Apple JS (at this time - v1.5.2) may cause some grief in Internet Explorer 11. Some of the JavaScript used is not supported by this browser.

While this is an older version, and use of it is lower than in other browsers, you must consider who your audience is and how many users this might affect. Could the fact that SIWA may fail on IE 11 have a negative impact on your product? Is it beneficial to continue to support it?

There is the possibility that Apple will remedy these issues in a future version, however, if not, you may have to handle any necessary adjustments. For example, Apple’s library uses CustomEvent, which is not supported by Internet Explorer. In this case, a polyfill may be used to support this object on incompatible browsers.

Android

Somewhat similar to web, when implementing SIWA on Android you must determine:

1. Whether you will use Sign in with Apple JS.
2. If not, what response_mode best serves your needs.

If choosing to use Sign in with Apple JS, the workflow essentially consists of:

• passing control over to a web domain (whichever one you set in the Service ID),
• allowing it to handle the login workflow in a web browser window,
• receiving the response at the chosen redirect URL,
• adjusting it to a format that Android can understand,
• and pass control back to the app.

Thanks for bearing with me there!

This approach requires communication and implementation on both the app and the web end of things. Once the redirect URL has reformatted the response, control can be granted back to the app using either an intent or a custom URL scheme if you have one established.

If you are leaning away from using Apple’s JavaScript library, you have the option to just directly use the API; however, it can result in a workflow very similar to using the library, depending on the values you use as part of your request. Apple’s authorization endpoint has various required parameters, which you can read more about here. I’m going to focus mostly on the response_mode.

The default value for response_mode is “form_post”. If this value is set, a POST request with the user data and an access token is sent to the redirect URL following a successful user login (this is also the case when using the JavaScript library). Android can’t directly handle a POST request very well, hence the need for logic existing at the redirect URL to reformat the user data before control is passed back to the app.

Unfortunately, it’s not always possible or desirable to make implementation changes to the web domain being used. This is where the “fragment” value for response_mode comes in handy. With this approach, instead of a POST, the login result is returned as a fragment at the end of the redirect URL you provided. If taking this approach, a WebView can be used to display Apple’s login page in-app. After a successful login, it is possible to then extract the appropriate data from that URL fragment that Apple has sent.

Now, like the previously mentioned approaches, this one also comes with a few cons. If using the form post approach, the user can be taken out of the app to a separate browser window to enter their login credentials. With this method, to be able to intercept that redirect URL, an in-app WebView will need to be used, which some may argue isn’t always a smooth experience.

Additionally, for security reasons, a user’s email and name can only be acquired if response_mode = “form_post”, not “fragment”. If this user data is a requirement for creating an account on your platform, it may be necessary to only allow sign-in with SIWA and not sign-up on Android. This is again where that effective user messaging I mentioned earlier might come into play.

To wrap it up

While SIWA is very convenient from a user’s point of view, it can bring about a set of new challenges for developers, potentially affecting products on various platforms. It isn’t as simple as adding a new button, as it may appear at first glance. This situation highlights the importance of finding a balance between a timely and effective response while still providing the best possible experience for your users.