Implementing “Sign In with Apple” easily in your app.
What is Sign In with Apple?
“Sign In with Apple” is a new authentication feature in iOS 13. It helps both developers and users to sign up and go into apps with an easy, simple and secure way.
Do I have to add it?
If you are using some third-party login methods like Google or Facebook, then the answer is yes — you have to use it, otherwise, your app may be rejected and won’t pass Apple review process.
Adding Sign In With Apple Capability
Under the Xcode project file, there is Signing & Capabilities available. Press on the + and add the “Sign In with Apple” capability. Adding the capability will create appropriate entitlements file and the right framework.
Adding the Button
First we need to import a framework called “AuthenticationServices”
AuthenticationServices was added to the SDK last year in iOS 12 and is used to handle passwords saved in the keychain. Now it’s also responsible of the Sign In with Apple Feature.
After that , adding the button is very simple — Just create a button from class ASAuthorizationAppleIDButton. ASAuthorizationAppleIDButton actually inherited from UIControl and not UIButton but it doesn’t really matter since all we need to do is adding a target and an action to it and that’s all, like in all UIControl’s. All the other button issues such as highlighting, titles, etc are already being take care for you under the hood
There are no official ways to customize this button, but you can change it’s dimensions.
After we add the button, a target and an action, we need to response to user tap.
Open the Dialog
The response for the button tap contains 7 steps:
- Create an instance of ASAuthorizationAppleIDProvider. This provider is responsible for generating requests for authentication based on AppleID.
- From this provider, call “createRequest ()” method.
- Define what scopes you want to receive from the user. Currently, only Email and Full name are available.
- Define the controller delegate, so you can respond to the user actions in the dialog.
- Provide a presentationContextProvider, so the controller can tell from what window to open.
- Create an AuthorizationController from those requests.
- Call performRequests method.
This will open a dialog for the user, but with some issues, you need to be aware of:
- The user can edit his first and last name before sharing it with the app.
- If the user has several email addresses associated to his account, he can choose each one of them.
- The user can choose to hide his real email from the app and Apple will generate a random email for him. Now, the user can’t see the random email Apple generated for him and the app can’t see the real email for the user. Also, Apple generates the same email next time; the user will try to sign up/into your app. This is extremely important since a lot of apps are base their users account on email addresses.
Response to user Authorization
The delegate we set for the controller has 2 methods: One is success (didCompleteWithAuthorization) and other is error.
Let’s go over the “didCompleteWithAuthorization”.
So besides the controller itself, this method has an additional parameter called “authorization” from type “ASAuthorization”. This object contains all the required data from the authorization process
We need the extract the credential from the authorization object and there we have it — the user data.
What’s included here?
First of all, we have the basic data — Full Name and Email, and just to remind you, it doesn’t have to be the real name and email of the user.
On the other hand, we also have some more info which you may find useful. For example, we have a user identifier. You should save it in your app keychain.
Handling Changes in Apple ID State
We know that the user can sign out from his Apple ID account or not letting the app permission to use it. Fortunately, we have an explicit notification for that, which is called NSNotification.Name.ASAuthorizationAppleIDProviderCredentialRevoked.
You need to listen to this notification and then get the credential state for the user ID you got when the user logged in by using ASAuthorizationAppleIDProvider.
If your user signed using email and password before and the password is attached to his keychain, then it will also offer the user to sign in using his existing email address and password.
In order to handle the response, just check the authorization.credential in the didCompleteWithAuthorization delegate method and in the case from type ASPasswordCredential, you know that the user signed in with a saved email and password.
Creating a Generic Solution for Sign In with the Third- Party Provider
Now, that we have Google, Facebook, and Apple ID login. You should think of creating a robust and unified solution for signing and logging to your app.
One of the methods of doing that, is to create a connector for each one of your login methods, which conform to some “authentication connector protocol”. So all you will have to do is to call that connector with some connect () protocol method and received success or failure with an email and a name.
That will make your work much simpler.
This is a tricky part — if currently, your app is using some third-party authentication service, such as Google or Facebook; you will have to implement Sign In with Apple method. This is Apple guidelines and if your app is cross-platform, for example, if you have a web version of your app, it means that you probably will have to implement Sign In with Apple on your web as well.
Remember, the user can share a fake email with you and he will have to do it also on the web.