What is Sign in with Apple?
In 2019 Apple announced their new sign-in solution, Sign in with Apple, which is a requirement for all iOS apps that offer another third party sign-in solution (for example Google or Facebook). The deadline for this requirement is 30 June 2020 for all new apps and app updates submitted to the App Store.
One of the advantages is enhanced privacy as users do not have to share their personal email address with app developers. Apple provides a unique and random email address that automatically relays messages to their personal email address. We take data privacy very seriously at the Guardian and seek to uphold the highest standard of personal data protection. We continue to follow our privacy stance.
To create a consistent sign-in experience for users, Apple recommends offering their new Sign in with Apple solution across non-Apple platforms and the web.
At the Guardian implementing Sign in with Apple on iOS only was not a choice. Given the architecture of our account management, it was something that we would need to offer across both platforms and the web.
Whilst Apple does offer some documentation for non-Apple platforms, we were unable to find one place that summarised the options available to Android developers seeking to implement Sign in with Apple, so we wanted to share our experience.
What are the options available to Android developers?
Apple provides a few different options to allow developers to integrate Sign in with Apple:
a framework for Apple engineers to integrate with iOS, macOS and tvOS
a Javascript API for web platforms
for other platforms another API is provided by Apple to allow the sign in process to open in another web flow.
The best option for Android developers is most likely using the API provided for other platforms. The workflow of this API is fairly simple: a URL will be opened for the user in a web view, allowing them to securely sign in to their Apple account. Once complete, the relevant data will be sent back to the Android app to complete the login process.
For some products the number of users using both Apple and Android devices may be small, so it seems sensible to explore pre-existing options that could reduce development time. Below we explore the other implementation options we have found.
Firebase authentication
Firebase provides a Sign in with Apple solution as one of their extensive authentication options. The Firebase team has helpfully summarised the work you might have had to do within their SDK.
If you are already using Firebase authentication in your app, this is an ideal solution. However, as this option is tightly coupled with Firebase it won’t be appropriate if you do not make use of it, or you have your own bespoke registration system.
Third party SDK
Some helpful Android developers have already attempted to implement a version of Apple’s Other Platforms API and then open sourced their work for other developers to use.
This library has some benefits, but when you need access to personal data from Apple, such as a user’s e-mail or names the data is sent back to you in a POST request. This cannot be handled solely via an Android app and will require a server side application to ingest that information.
We spent some time looking into this library, and whilst it did not quite meet our needs at the Guardian we still think it is useful for understanding how you might want to design your implementation.
After we looked into the options above, we decided that our own bespoke implementation would be the best approach, which we outline in the next section.
How did we implement Sign in with Apple at the Guardian?
We implemented Apple’s documentation for Other Platforms, which uses the OAuth framework. Aaron Parecki, a Security Architect, gives a great overview of how the Apple OAuth flow works on the Okta Developer blog.
When a user clicks “sign in with apple” the sign-in flow is started by opening the authorization URL in a WebView with the required parameters [1].
To create an account at the Guardian we require a name and email address. In order to retrieve this information we use the scope query parameter, which allows us to access this information. We set the response_mode to be form_post, as per the documentation: “If you requested any scopes, the value must be form_post” [2]. Apple returns the values of these parameters to the redirectURI in the body of a POST request [3].
The Android app uses the shouldOverrideUrlLoading and onReceivedHttpError functions in a WebViewClient to intercept requests and handle errors within the context of a WebView.
However, the shouldOverrideUrlLoading cannot see the body of a POST request; this means the app cannot handle data provided by Apple on its own.
Instead, our redirectURI goes to a server handled by our identity team so that they can securely receive the response of the scope query parameters.
Once we had established how to pass data back from Apple in the Guardian’s domain, we had to understand how to pass data from the context of an Android WebView into our normal authentication flow.
We decided the best approach would be to encrypt the data on the server side, pass the data out of the WebView via a URL and then pass the (still encrypted) data into our conventional social sign in flows.
This led to a kind of ping-pong game where the identity team encrypts the data, sends it to the Android application [4], which then returns the encrypted parameters to the server [5]. The Android application is then provided with a Guardian authentication token and the user is signed in [6].
Quick GuideHow do I join The Guardian Product & Engineering?
Show
Where can I find open positions?
Apply for one of our open positions here.
What can I expect from the interview process?
We aim to be as fair and transparent as possible in our hiring process. Similar to other organisations, there is a CV screening, coding exercise and a face to face interview. Read more about what to expect and apply now here, and read more about our department here.
Conclusion
There are a few different options for developers seeking to implement Sign in with Apple on Android, including Apple’s JS option, Firebase and this open-sourced third party SDK.
For those who choose to implement using Apple’s documentation for Other-Platforms, we hope this article has been helpful in illustrating how you can go about receiving the user’s name and email address from the HTTP body, which is inaccessible from a webview.