One of the more interesting new features in iOS 13 is “Sign in with Apple,” which allows you use your Apple ID to sign into 3rd party apps, and even websites. This will let anyone with an Apple ID and a trusted device use this feature on any app or website that supports it.
Using “Sign in with Apple”
From a user perspective, Sign in with Apple is virtually identical to any 3rd party OAuth-based SSO. You enter your credentials and verify it’s ok for the app (or site) to use your information (and what information they should have access to).
From a developer’s perspective, there are 3 ways to implement Sign in with Apple:
- Native App Integration – use AuthenticationServices framework for native iOS, macOS, tvOS, and watchOS apps.
- Browser Integration – Use Sign in with Apple JS which is a JavaScript framework to handle using Sign in with Apple directly in a web browser.
- REST based – use Sign in with Apple REST API to allow REST-based authentication flow. The user still signs in via a browser session, but instead of using Apple’s JS framework the authentication points are server-side.
For this blog post, we’ll focus on option 3, because it’s the easiest way to get started (and functionally, the same as 1 and 2). Getting your first successful integration can take a bit and going the REST path reduces the complexities and lets you use the server-side language of your choosing.
Implementing “Sign in with Apple”
Implementing Sign in with Apple is fairly straightforward via REST, which follows an OAuth protocol. But there are a few things you’ll need to setup before we get to the actual REST call:
- Setup an App ID and Service ID in your Apple Developer Account. The Service ID information is then used as the client ID for getting the access token in the OAuth flow.
- Display a “Sign in with Apple” button
- Create a link from the button to the authorization URL, passing the following info:
- Redirect URL to handle the callback from Apple.
- Scope being requested, name, email or both.
- Service information that defines what App ID/Service ID is being used to handle the authorization.
When the user clicks the link, they’ll get a login prompt to enter iCloud credentials. If this is the user’s first time using this process at a specific site, a 2FA code will be sent to the user’s Apple-trusted device(s) with an authorization code. Below, we see it showing up on Apple Watch. This code is then entered into the website.
The login process then asks the user if they want to share the information (name and/or email) the website is requesting.
Users who want to share their name can change it without affecting their iCloud info—which is nice. This allows the name sent to the website to be just about anything.
If the website asks for email address, the user may share the actual email address in iCloud, or a “relay” version of it. The great thing about this as a user is that you can disable the forwarding if you end up getting a lot of unwanted spam.
In Browser We Trust?
One of the first steps in completing the Sign in with Apple process is to decide if you want to trust the browser you’re using. If you trust the browser, then for the next 30 days you won’t be required to use the 2FA code to get in. For me, this is a big no-no since 2FA is one of the key things that makes Sign in with Apple more secure.
Luckily, there’s a “Don’t Trust” button which, if selected, will never ask you again if you want to trust this browser, and simply requires you to use a 2FA code every time. Better to err on the side of caution. Keep in mind that if you click “Trust,” you’ll have to clear your cookies and cached browser data to get it to prompt you for a 2FA code again before the thirty days are up.
So, the end result of all this is that the callback URL will get a POST from Apple with some information about the user, which looks like:
You’re going to be getting some attributes back, which are:
code: An authorization code you need to validate with Apple
id_token: A jwt token for the user. You can easily decode this to get some (limited) information about the user:
user: Information the user shared. Save this! Save this! Save this! This information only comes back on the initial “Login with Apple” flow so make sure you save it. I haven’t seen any way to get this information back, other than in this initial first step when the user enters their Apple ID for the first time.
email: Either the user’s actual email address or the id of an Apple relay address. This allows apps/sites to send info to a user’s Apple ID email address without having the actual address. Users may disable this relay address at any time.
The last step is to validate the ‘code’ that comes back in the json to your callback url. This means you need to call Apple’s validation server with the ‘code’, along with your OAuth client id and client secret, and you’ll get a response back. Something like:
The access_token is pretty much useless right now. Even Apple docs state you don’t get access to anything other than name and email. So don’t worry about this one. I’m guessing in the future this will become significant.
The id_token is what you’re interested in. When you decode the token, you’ll get the unique ID for the user signing in or the subject/sub field in the decoded token. Even if someone disables access for their Apple ID, and uses it to sign in later, this ID will always be the same, so it’s meant as the primary key for the user signing in.
The only other interesting attribute is “refresh_token,” which you can use to validate if the jwt token is still valid. If you make a call to Apple’s servers and you get an error around validating the refresh_token, you should consider the other user info invalid. This would happen due to the user revoking rights for Sign on with Apple to the site that was previously signed into it.
Revoking Access
Gaining easy access to websites and apps without creating a new userid/password every time is great. The flip side is maintaining control over which websites and apps have access once the account is created. This is very easy to manage with your Apple ID.
By going into your Apple ID details, you can view which apps have access to your Apple ID and then revoke that access by clicking “Stop Using Apple ID.” The next time Sign in with Apple is attempted, it will start the whole authentication process over, as if you had never used it. Apple will also return an error if any existing refresh tokens are used in a validation call after you hit “Stop Using Apple ID.”
Another nice thing is that if you need to change your Apple ID password, it won’t affect any existing sites you’ve signed into. The next time you go to one of the sites, you’ll simply enter the new password, and even the app/website won’t know the difference. When you change your Apple ID password, the id_token remains the same, which is the unique key for a user.
Wrapping up
Being able to use your Apple ID on multiple websites and apps without creating different accounts for each one is a big plus. And since virtually all Apple users already have an Apple ID, the need for using a third party SSO is eliminated.
Apple ID is secure, since it comes with 2FA, which must be enabled to use Sign in with Apple. And if your password is somehow compromised, you can always just change your Apple ID password without going into every account tied to it.
Using Sign in with Apple makes valuable content more accessible to Apple users by providing a quick and easy way to gather user information before giving access to premium content, such as whitepapers, etc. This reduces friction and makes it more likely new users to your site will use Sign in with Apple and remain engaged for a longer period of time. Want to take advantage of this great new Apple offering? When you’re ready to enable your website for Sign in with Apple, give us a call. We’d love to help you out.
Share on
