Transcript
[ Music ]
[ Applause ]
>> 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.
[ Applause ]
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.
[ Applause ]
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.
[ Applause ]
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 ]