[MUSIC PLAYING]
NIHARIKA ARORA: Hi.
I'm Niharika, a developer relations engineer at Android.
DIEGO ZAVALA: And I'm Diego, a product manager also
in Android.
Today we will be talking about how
to reduce the reliance on passwords
by adding passkey support for Android apps.
Let's get started.
Authentication provides a secure way for users
to access personalized, high-end experiences they love.
They want to see what's the latest from their friends
and family on social apps and post updates
from their accounts.
They want to order from their favorite restaurants
without needing to enter your address and payment
method every time.
To support these and many other experiences,
apps provide accounts to users who authenticate
to get their content.
But there are challenges.
Passwords are not always secure or seamless.
They can be fished or leak in a server breach.
Users often forget their passwords
or reuse them on apps and sites.
Because of those security challenges,
many services require a second factor
of authentication, further increasing
friction along the authentication journey.
In addition, sign-in methods have proliferated.
It's no longer only about passwords,
but it's possible to sign in with federated authentication
like sign-in with Google, email links, one-time passcodes,
and so on.
And users carry the burden of remembering,
did they sign in with a password, sign in with an OTP?
Authentication can also be complicated for developers.
There are many options for handling the sign-in methods
that users like.
And developers don't know about any consolidated solutions.
The result is a need to support multiple integrations and APIs,
increasing the effort required to set up and maintain
user journeys.
To address these issues on Android,
passkeys will be the preferred sign-in method moving forward.
And we will roll out a new unified API called credential
manager to bring together support
for passkeys with traditional authentication methods.
Let's learn more about these changes starting with passkeys.
So what are passkeys?
Passkeys are a new form of passwordless authentication
built on industry standards.
They are based on public cryptography
and offer a significantly simpler and safer replacement
to passwords and other phishable authentication methods.
How do they work?
When creating a passkey, the user's device
generates a private-public key pair.
The public key is sent to a server
while the user's device keeps the private key.
Then when the user wants to sign in again,
the private key is used to prove to a server
that the user has it.
All the user needs to do is use their device's screen
lock, like fingerprint or face unlock.
The user's chosen password manager,
such as Google password manager, keeps passkeys synchronized
across the user's Android devices
so even if the user loses their phone,
they won't lose their credentials.
Passkeys make the sign-in experience simpler,
enabling a seamless flow where the user just
focuses on selecting the right account without needing
to remember username or passwords,
copy/paste a one-time code from SMS,
or tap on a link in their email inbox.
Passkeys leverage familiar patterns,
like a biometric check or a screen unlock,
and provide multifactor authentication in a single tap,
allowing for quicker sign-in experiences for users
and increased sign-in rates for developers.
Passkeys also make sign-in more secure
and offer phishing-resistant protection by design.
As the sign-in is only authorized
if the user requests it on an authorized app or site.
Also, the private key is never sent to the app server,
making passkeys less prone to breaches.
And the best part, passkeys give users access to their apps
wherever they want.
This is possible because passkeys
are based on the Fido standard and are
supported by major platforms and browsers.
To support passkeys on Android, we
are rolling out a new API called Credential Manager.
Credential Manager brings together
passkeys and traditional sign-in methods,
such as passwords and federated sign-in,
into a consolidated interface for the user
and a unified API for developers.
This has several benefits.
Users will enjoy seeing all their credentials
in one place--
passkeys, passwords, and federated credentials,
such as sign-in with Google--
without needing to tap on three different places.
We know too many choices when logging in
can get confusing for users.
That's why Credential Manager makes the log-in experience
simpler by consolidating the sign-in methods
for each account and surfacing only the safest and simplest
authentication method.
So if a user has a password and the passkey
for a single account, they won't need
to decide between them when signing in.
Rather the system will propose using the passkey, the safest
and simplest option.
That way users can focus on choosing the right account
they want to use instead of the underlying technology.
On devices running Android 13 or lower,
passkeys and passwords are saved and retrieved
from Google Password Manager.
That way if a user loses their Android device,
they can restore their passkeys on another Android device
by signing in with their Google account.
On devices with Android 14 or higher,
credential manager will support multiple password managers
at the same time.
We are excited to announce that several leading password
managers and credential providers, such as 1Password,
Dashlane, Keeper, and Okta, will be available
when Android 14 launches.
And we expect many more to be available shortly afterwards.
For developers, Credential Manager
supports multiple sign-in mechanisms within a single API.
It brings support for passkeys and Android apps,
enabling the transition to a passwordless future.
And at the same time, it also supports passwords
and federated sign-in like sign-in
with Google, simplifying integration requirements
and ongoing maintenance.
Credential Manager is already available to integrate
with on existing devices and will fully
launch with Android 14.
Passkeys are the future of online authentication.
They are more secure and convenient than passwords.
That's why many developers like Kayak, Amazon, and PayPal,
among others, are already working to support passkeys
on their Android apps.
Let's take a look at how Kayak implemented passkeys using
Credential Manager on Android.
Kayak searches hundreds of travel sites
to show travelers the information
they need to find the right flights, hotels, rental cars,
and vacation packages.
To improve their authentication journeys,
Kayak is rolling out passkey support
on their Android app using Credential Manager.
Matthias Keller, chief scientist and SVP,
told us that passkeys make creating an account lightning
fast by removing the need for password creation
or navigating to a separate app to get a link or code.
Let's see this experience in action.
On an Android device, I go to the Kayak app
and create an account.
After typing my email, I'm prompted
to create a passkey for the new account in two simple steps.
Confirm that I want to create a passkey
and authenticate with biometrics.
The passkey is created and stored
to Google Password Manager.
And with that, the account to use Kayak is created.
Very easy.
If I then sign out, I can easily sign
in again using that passkey.
I just need to confirm the account
I want to use and authenticate using biometrics.
This passkey is also available in Chrome on Android.
So if I go to kayak.com, I can use the passkey to sign in.
I just need to tap on the username field,
select the passkey in the autofill suggestion,
complete a biometric check, and I'm in.
Passkeys created on an Android device
can also be used to sign in on other platforms.
On desktop, I go to kayak.com, select Sign-in,
tap on the username field, select
Use a Passkey From a Different Device, and pick my device.
Then on my Pixel, I authorize the sign-in.
Once I do that, I'm signed in on my desktop, too.
Over to you, Niharika.
NIHARIKA ARORA: Now let's talk about the API integration
on the developer side and see how to create
passkeys for existing users.
Let's start on how to register credentials
using Credential Manager.
The first step to enable support for passkeys for your Android
app is to associate your app and the website.
To do so, host a Digital Assets Link JSON file on your website
and add a link to the JSON Asset Link file to your app's
manifest.
This demonstrates that you own both the website and the app.
To learn more about Digital Assets Link,
check out the links in the description.
For registered passkeys for existing users,
the user needs to be signed in on your app.
They will do that using traditional authentication
methods such as passwords or federated identity.
A good time to ask users to create a passkey
is just after the sign-in, asking
if they want to enable a simpler method for the next time they
access your app.
The same can be done when they are signing out.
To create a passkey, there are three elements required.
First, a backend server that can handle Fido authentication
flows.
There are many libraries that can help with this.
Second, an Android app that implements the credential
manager API.
And third, the user needs a password manager
that supports passkeys, such as Google Password Manager.
Once the process is started, the user's device
sends a signal to the backend to retrieve the required
information.
This is the information returned from the backend.
Several fields to pay close attention to
are challenge is a server generated random string
to prevent replay attacks.
Public key credential params is a list of allowed algorithms
and key types.
And you see here a key named residentKey.
This is required to generate a passkey instead of
traditional nonsyncable Fido two credential.
Check out the link in the description
for more about each field.
Based on that information the app calls the Create Credential
Method, this is what the Create Credential Call looks like.
At this stage, a bottom sheet is shown to the user asking
them to create a passkey.
And this call is a suspend function.
Once the request is successful, you get the result
and you can let the user know that the passkey was
successfully created.
The generated passkey is saved in the user's
preferred password manager.
And the public credential information
is returned to the app as a credential object.
The public key credential object contains
several important properties, such as attestation object,
which is a string that embeds a relying party, ID, flags,
a public key, among other values.
ID helps determine whether a matching passkey is already
stored on the device during authentication.
Check out the link in the description
for more about each field.
Finally, the registration is completed
by linking the public key and credential ID to the account
and saving it in the backend.
This information is verified on the backend,
and only then the process is complete.
This is how the end-to-end process
is presented to the user.
The user is prompted to create a passkey.
They authenticate through biometrics.
And the passkey is created.
Quite convenient, isn't it?
Now since the user has created the passkey,
they can use it to authenticate every time
they sign into your app.
Similar to registered user credentials flow,
we have the same components during authentication.
First, we get information from the backend.
This is the info returned to the app.
To prevent replay attacks, generate a new challenge
every sign-in attempt and disregard it
after a certain duration or after a sign-in attempt
fails to validate.
The rpId, which is a reliant party identifier,
must match exactly the rpId that the password manager specified
during registration.
Then call get credentials with this information and your app
doesn't need to prompt the user to perform this step.
This is what the call takes in as parameters.
You can retrieve all the passkeys and passwords
that are associated with the user's account.
Pass these options to build the sign-in request, which
is credRequest.
As soon as the request is successful,
the user is prompted to authenticate
with the passkeys or passwords that are
associated with their account.
The prompt appears as a bottom sheet.
Once the user selects the passkey and authenticate,
the credential, including the signature,
is returned to the app.
The public key credential object contains additional properties,
such as the following.
Authenticated data, which embeds information such as rpId.
Signature is the core of the credential
and needs to be verified on the server using the previously
stored public key.
User handle represents the user ID given during registration.
Check out the documentation in the description to learn more.
To complete the authentication, the app sends these credentials
to the backend, which verifies the signature using
the stored public key.
That's it.
This is what your sign-in flow looks like.
The user taps on Sign-in.
They are prompted to use the saved passkey.
And they choose the passkey.
After the user performs these steps,
the sign-in process is complete.
To facilitate the integration, Firebase authentication
and Google Cloud Identity Platform
are bringing passkey support to developers soon.
Developers will be able to provide a modern and secure out
of the box authentication solution
for apps they are building.
Major mobile and web platforms will be supported.
So if you are interested in trying out
this passkey support, you can express interest
to the Firebase developer relations
team via the link in the description.
To help developers implement the credential manager API,
we curated a list of resources, including
Android's official documentation, a sample code
base, and also a codelab with step-by-step instructions.
And that's it.
Our aim is to simplify the way developers interact
with Android and help users seamlessly and securely
access their accounts across Android apps and websites.
We are committed to bringing features and tools that
help you, the Android developer community,
build more secure apps.
Summarizing what we discussed in this session,
Credential Manager API is great for both users and developers.
It's ready for you to try out.
We appreciate your time today.
If you want to know more about how you can integrate passkeys
on Chrome, check out the web session Passkeys, a Simpler
and Safer Sign-in, by Eiji.
Link mentioned in the description.
[MUSIC PLAYING]