Hi. I'm Niharika,
a Developer Relations Engineer at Android. And I'm Diego,
a Product Manager, also at Android. Today, we will be talking about
how to reduce 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 their 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 phished
or leaked in a server breach. Users often forget their passwords
or reuse them on apps and sites. Because of these 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 I sign in with a password,
Sign in with..., or 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
a 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 multi-factor 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 a 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
on 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 on 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. 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. To register 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 a traditional,
non-syncable FIDO2 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 key credential information is returned to the app
as a credential object. The public key credential object
contains several important properties such as "attestationObject" 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
the register 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 the reliant party identifier must match exactly the rpId that the password manager
specified during registration. Then call .getCredentials
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 authenticates 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 your interest
to the Firebase developer relations team via the link in the description. To help developers implement
the Credential Manager API we created a list of resources,
including Android's official documentation a sample codebase 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.
