What's New in Authentication

Hello, everyone. My name is Ricky Mondello, and I am so excited to be here to today to tell you about What's New in Authentication on Apple platforms, including some very exciting and new APIs in the Authentication Services framework. My goal is to help you get your users signed into your apps as quickly and securely as possible.

We're going to talk about five topics today starting with Sign In with Apple.

Sign In with Apple is an easy and secure way for users to sign into your apps. Signing in is as quick as a few taps and a face ID check. Sign In with Apple is a private alternative to other single sign-on providers that you might be aware of.

And you probably already get the gist of what this capability is about. But what I want to do is emphasize a few key points related to how Authentication works already in your apps.

And the first is that for your users, Sign In with Apple is easier to use than passwords. People generally don't love managing passwords. And when users don't have a password, that password can't be a bad password, and it can't get phished, which is good for your users, but it's also good for you.

And for you specifically, these accounts are great accounts. Every single one of the accounts that can be used with Sign In with Apple has strong two-factor authentication that's already used to protect their Apple ID. This two-factor authentication involves the user's circle of trusted devices and strong biometrics. Having a user start off with this much security is a lot easier than trying to bolt it on after the fact to a password-based account. And to help you with fraud, there's information included in the API about how Apple is confident about the account being from a real user, which you're going to really appreciate. And the third point that I want to emphasize about Sign In with Apple is that it is across platform experience, across all of the user's devices. If they're signed into their Apple ID, signing into your app is as easy as a quick face ID or touch ID check. And thanks to the web and web technologies, Sign In with Apple is available elsewhere.

And don't worry. We're going to help your users not create a second account for your app if the user already has one that works for them. On app launch, your app can check for an existing password-based account saved to the iCloud Keychain even before you show your standard login interface so that users do the right thing.

If you have a service with user accounts, you and your users can benefit from Sign In with Apple. To learn more about it, including how to adopt it on the web, watchOS, tvOS, the Mac, iPadOS, and iOS, check out Introducing Sign In with Apple in the WWDC app.

And that's Sign In with Apple, a convenient and private alternative to password-based authentication.

And password-based authentication is actually my next topic because even in a world with a great, private single sign-on option, passwords are still going to be a part of our lives. And that's why iPhone has Password AutoFill, which makes it quick and easy for users to sign in to your apps on the existing login screens that you already have.

Today, I am very excited to tell you that Password AutoFill is available for iPad apps for Mac with an interface that is specifically tailored to the Mac. Thanks. For users to get this deluxe experience that you see right here, where the exact right credential that the user wants to sign in with is in the list, there's just one thing that you have to do. Once you've brought your app to the Mac, it'll have a new app ID, and that app ID has to be listed on your server in order to tie your app and your website together.

If you're using webcredentials to do this, your Apple app site association file might look something like this. And all you're going to do is add the app ID to this app's array. Super easy.

But if you're using universal links, you'll add the new app ID here as part of the new app ID's key that can take a list. This key is new to iOS 13 and macOS Catalina.

To maintain compatibility with iOS versions before 13, you'll want to keep this apps key with the value of an array and the app ID key that lists your existing iOS app. You really want to do this in order to ensure that universal links keep working for your users who are running iOS 12.

There are a bunch of new features and universal links this year, including more powerful URL matching. And to learn more about those, I encourage you to check out the What's New in Universal Links video in the WWDC app.

Whether on the Mac, iPad, Apple TV, or iPhone, Password AutoFill makes it easy for users to get signed in to apps on your existing login screens. But let's take a closer look at this screen right here. The user's current task of getting signed into your app? The answer to the problem is here. It's a small part of the keyboard. And this is great, because AutoFill is accommodating the username and password field combination pattern that we've seen for even before when iPhone existed.

But your app can have an even more streamlined and intentional experience, and with iOS 13, it's easier to do this than ever before. The same sign-in experience I showed you earlier in the context of Sign In with Apple, is available to all apps that use passwords. And it's available through the authentication services framework.

The same API and functionality is also available on macOS Catalina.

Let's talk about how to add this functionality to your apps. The first step is to write some code using the AuthenticationServices framework. You'll create an AuthorizationController using a password request. The AuthorizationController is the same object that you'll use for Sign In with Apple. But here we're just using a different kind of request.

Then you'll set up a delegate as well as an object that will help coordinate presentation of the interface. And then it'll tell the controller to perform the request.

When the user has selected the account that they want to use, the API will call the delegate, and you can take it from there to complete the sign-in. If didCompleteWithError is immediately called for you, it might mean that your user doesn't have any passwords saved in their iCloud Keychain for your app and website. And then you should just fallback to showing your normal sign-in screen. The user can take it from there.

But if you're sure that you have credentials on a test device and you're seeing the error handler get called, you're going to want to back to checking your associated domains. If you've never tied your app and website together before through associated domains, Introducing Password AutoFill for Apps has a step-by-step tutorial that'll take you through it. It's pretty easy. And for universal links, once again, you're going to want to check out the Universal Links video that's in the WWDC app.

Something about this API that is really awesome is that you can request multiple types of accounts at the same time using the AuthorizationController. And this is super handy if you want to check for both a password-based account and Sign In with Apple right around app launch.

If you do this, you're going to want to make sure that you handle both types of credentials in the CompleteWithAuthorization delegate method.

And that's how easy it is to use the new Authentication services APIs to make the process of getting signed into your apps even more streamlined than password AutoFill was able to.

As long as we have passwords, there needs to be a healthy way to use them, a safe way to use them. And that's why iPhone has Automatic Strong Passwords, which encourages users to use a strong, unique password for every single one of their accounts, which greatly improves their security while also being easier to do than making the mistake of trying to create a password by hand.

But what if one of your users already has a password that's kind of weak? Now, in Safari 13 and iOS 13, when a user signs into a website and Safari notices that the password they just used was weak, Safari will prompt the user to go and visit the website to change the password. And this is at the moment of sign-in where the user might be thinking about what the account means to them. If the user accepts Safari's offer, they'll be taken over to Settings where they can change their password. And with Automatic Strong Passwords, it's just a few taps to get upgraded. And, of course, this feature is on the Mac as well with Safari 13.

This flow is at its best when your user is taken directly to your website's Change Password page rather than to the homepage of the site. And what's really cool is that this is completely in your control and super easy to implement. Websites like Twitter, GitHub, and WordPress.com have already adopted it. All you have to do is put a redirect at this path on your server that takes the user to your Change Password webpage, and that's it. The redirect can be implemented either as a client-side redirect or a server-side redirect. You can learn more about the well-known URL for changing passwords, which is a proposed standard at this URL.

You'll also find it pretty easily if you search the web for it.

And that is how iOS 13, iPadOS, and Safari 13 help users upgrade their weak passwords.

Some of your apps authenticate using a third-party web service, and if you're doing this, you're probably using a standard like OAuth. The Authentication's Services frameworks ASWebAuthenticationSession is the best way to do this kind of authentication. Once a user confirms that they're OK with signing in, the AuthenticationSession will use existing signed-in accounts through Safari's cookies and data in order to let the user sign-in even faster. Sometimes the user will already be signed in to the identity provider, and all they have to do is agree to signing into your app. And once they do that, they're in. Nice and easy. I am so happy to be able to tell you today that this API is now available on macOS Catalina. On macOS Catalina, this API uses the user's preferred web browser for signing in if that web browser supports it. And this is really great, because it means that all of your users will have their browser's password manager or password manager extension available to them in order to help get them signed in.

If you're using the AuthenticationSession API, it has a few new features for you to use this year. And the first is a more private kind of sign-in.

Because the AuthenticationSession shares website data with Safari, ASWebAuthenticationSession enables a single sign-on experience. New to iOS 13, your app can choose to deliver a more private experience, an experience that won't leave users logged into the identity provider in their web browser after they've signed into your app. If your app asks for this experience, users won't see this dialog. Instead, they'll be taken directly to the identity provider in order to get signed in.

To do this, set the prefersEphemeral WebBrowserSession property on the session to true before starting the session.

By doing this, you give your users more privacy and avoid that confirmation dialog, which overall might be a better experience for your app.

Next, supporting multiple windows.

In iOS 12, the AuthenticationSession API didn't need any information about view or windows from you in order to display its interface. This is because the API was iOS only, and almost all apps drew into a single window. But now with iPadOS and macOS support, you're going to have to help us out a little bit to figure out where to draw the interface.

First, you'll give the session a presentationContextProvider, and that presentationContextProvider will provide a window via the PresentationAnchor method. This is a really easy change and one that you're definitely going to want to make. One more thing about OAuth. ASWebAuthenticationSession has a deprecated predecessor called SFAuthenticationSession. It's from the Safari Services framework. If you haven't already, you're going to want to take a moment to switch over. ASWebAuthenticationSession has the new features that we just talked about, and it's available on the Mac. It's, basically, the non-deprecated drop-in replacement for the old API. And that's it for OAuth.

This year, macOS supports USB security keys in Safari through the WebAuthentication standard. I am really happy about this support, especially because I know that a number of you have been asking for it. Depending on who or what you're protecting and the threat models that you're concerned about, you might consider tying user authentication to the physical presence of some kind of hardware device. Safari 13 supports USB-based FIDO2-compliant devices with the WebAuthentication standard. It's available as an experimental feature in Seed 1 of macOS Catalina, and it'll be on by default in Seed 2. You can also try it out right now if you download Safari Technology Preview. If you're interested in supporting USB security keys, it's really important to offer a great account recovery story, just in case your user's key gets lost, stolen, or broken.

And designing account recovery systems when a hardware token is involved is really important, but it's not always straightforward. So unless you are already in this business or were seriously considering getting into it, it's more likely that one or more of the other areas that I cover today will be more relevant for your users, your apps, and your websites.

If you develop an app with user accounts, I have three takeaways from what we've talked about today.

First, strongly consider adopting Sign In with Apple. For your users, the best password is no password, especially when it's backed by two-factor authentication and great biometrics.

Two, make signing into your app a one-tap experience using the Authentication Services framework. Users don't even need to see a keyboard anymore to get signed in. And finally, implement the well-known URL for changing passwords. It's really easy to do, takes just a moment, and it makes a huge difference when Safari is going to try to help your users upgrade their passwords.

You'll find more information about what I covered today and more in the WWDC app or on the web. And that is it for me. Thank you all so much. I really hope you've been having a wonderful WWDC. [ Applause ]