Tag Archives: passkeys

Introducing Restore Credentials: Effortless account restoration for Android apps

Posted by Neelansh Sahai - Developer Relations Engineer

Did you know that, on average, 40% of the people in the US reset or replace their smartphones every year? This frequent device turnover presents a challenge – and an opportunity – for maintaining strong user relationships. When users get a new phone, the friction of re-entering login credentials can lead to frustration, app abandonment, and churn.

To address this issue, we're introducing Restore Credentials, a new feature of Android’s Credential Manager API. With Restore Credentials, apps can seamlessly onboard users to their accounts on a new device after they restore their apps and data from their previous device. This makes the transition to a new device effortless and fosters loyalty and long term relationships.

On top of all this, there's no developer effort required for the transfer of a restore key from one device to the other, as this process is tied together with the android system’s backup and restore mechanism. However, if you want to login your users silently as soon as the restore is completed, you might want to implement BackupAgent and add your logic in the onRestore callback. The experience is delightful - users will continue being signed in as they were on their previous device, and they will be able to get notifications to easily access their content without even needing to open the app on the new device.

An illustration the process of restoring app data and keys to a new device, highlighting automated steps and user interactions.  The top row shows a user signing into an app and a restore key being saved locally, while the bottom row shows the restore process on a new device.
click to enlarge

Some of the benefits of the Restore Credentials feature include:

    • Seamless user experience: Users can easily transition to a new Android device.
    • Immediate engagement: Engage users with notifications or other prompts as soon as they start using their new device.
    • Silent login with backup agent integration: If you're using a backup agent, users can be automatically logged back in after data restoration is complete.
    • Restore key checks without backup agent integration: If a backup agent isn't being used, the app can check for a restore key upon first launch and then log the user in automatically.

How does Restore Credentials work?

The Restore Credentials feature enables seamless user account restoration on a new device. This process occurs automatically in the background during device setup when a user restores apps and data from a previous device. By restoring app credentials, the feature allows the app to sign the user back in without requiring any additional interaction.

The credential type that’s supported for this feature is called restore key, which is a public key compatible with passkey / FIDO2 backends.

A diagram shows the device-to-device and cloud backup restore processes for app data and restore keys between old and new devices.  Steps are numbered and explained within the diagram.
Diagram that depicts restoring an app data to a new device using a restore credential, including creating the credential, initiating a restore flow, and automatic user sign-in.

User flow

On the old device:

    1. If the current signed-in user is trusted, you can generate a restore key at any point after they've authenticated in your app. For instance, this could be immediately after login or during a routine check for an existing restore key.
    2. The restore key is stored locally and backed up to the cloud. Apps can opt-out of backing it up to the cloud.

On the new device:

    1. When setting up a new device, the user can select one of the two options to restore data. Either they can restore data from a cloud backup, or can locally transfer the data. If the user transfers locally, the restore key is transferred locally from the old to the new device. Otherwise, if the user restores using the cloud backup, the restore key gets downloaded along with the app data from cloud backup to the new device.
    2. Once this restore key is available on the new device, the app can use it to log in the user on the new device silently in the background.
Note: You should delete the restore key as soon as the user signs out. You don’t want your user to get stuck in a cycle of signing out intentionally and then automatically getting logged back in.

How to implement Restore Credentials

Using the Jetpack Credential Manager let you create, get, and clear the relevant Restore Credentials:

    • Create a Restore Credential: When the user signs in to your app, create a Restore Credential associated with their account. This credential is stored locally and synced to the cloud if the user has enabled Google Backup and end to end encryption is available. Apps can opt out of syncing to the cloud.
    • Get the Restore Credential: When the user sets up a new device, your app requests the Restore Credential from Credential Manager. This allows your user to sign in automatically.
    • Clear the Restore Credential: When the user signs out of your app, delete the associated Restore Credential.

Restore Credentials is available through the Credential Manager Jetpack library. The minimum version of the Jetpack Library is 1.5.0-beta01, and the minimum GMS version is 242200000. For more on this, refer to the Restore Credentials DAC page. To get started, follow these steps:

    1. Add the Credential Manager dependency to your project.

// build.gradle.kts
implementation("androidx.credentials:credentials:1.5.0-beta01")

    2. Create a CreateRestoreCredentialRequest object.

// Fetch Registration JSON from server
// Same as the registrationJson created at the time of creating a Passkey
// See documentation for more info
val registrationJson = ... 

// Create the CreateRestoreCredentialRequest object
// Pass in the registrationJSON 
val createRequest = CreateRestoreCredentialRequest(
  registrationJson,
  /* isCloudBackupEnabled = */ true
)
      NOTE: Set the isCloudBackupEnabled flag to false if you want the restoreKey to be stored locally and not in the cloud. It’s set as true by default

    3. Call the createCredential() method on the CredentialManager object.

val credentialManager = CredentialManager.create(context)

// On a successful authentication create a Restore Key
// Pass in the context and CreateRestoreCredentialRequest object
val response = credentialManager.createCredential(
    context,
    createRestoreRequest
)

    4. When the user sets up a new device, call the getCredential() method on the CredentialManager object.

// Fetch the Authentication JSON from server
val authenticationJson = ...

// Create the GetRestoreCredentialRequest object
val options = GetRestoreCredentialOption(authenticationJson)
val getRequest = GetCredentialRequest(Immutablelist.of(options))

// The restore key can be fetched in two scenarios to 
// 1. On the first launch of app on the device, fetch the Restore Key
// 2. In the onRestore callback (if the app implements the Backup Agent)
val response = credentialManager.getCredential(context, getRequest)

If you're using a backup agent, perform the getCredential part within the onRestore callback. This ensures that the app's credentials are restored immediately after the app data is restored.

    5. When the user signs out of your app, call the clearCredentialState() method on the CredentialManager object.

// Create a ClearCredentialStateRequest object
val clearRequest = ClearCredentialStateRequest(/* requestType = */ 1)

// On user log-out, clear the restore key
val response = credentialManager.clearCredentialState(clearRequest)

Conclusion

The Restore Credentials feature provides significant benefits, ensuring users experience a smooth transition between devices, and allowing them to log in quickly and easily through backup agents or restore key checks. For developers, the feature is straightforward to integrate and leverages existing passkey server-side infrastructure. Overall, Restore Credentials is a valuable tool that delivers a practical and user-friendly authentication solution.


This blog post is a part of our series: Spotlight Week: Passkeys. We're providing you with a wealth of resources through the week. Think informative blog posts, engaging videos, practical sample code, and more—all carefully designed to help you leverage the latest advancements in seamless sign-up and sign-in experiences.

With these cutting-edge solutions, you can enhance security, reduce friction for your users, and stay ahead of the curve in the rapidly evolving landscape of digital identity. To get a complete overview of what Spotlight Week has to offer and how it can benefit you, be sure to read our overview blog post.

Welcome to Spotlight Week: Passkeys

Posted by Joseph Lewis – Android Developer Relations Technical Writer, and Niharika Arora – Android Developer Relations Engineer

We're kicking off Spotlight Week with a deep dive into passkeys! This week we're partnering with the Chrome team to feature exciting announcements, insightful resources, and expert guidance on how to build seamless and secure authentication experiences for your apps.

Throughout Spotlight Week: Passkeys, we'll share content to help you understand and implement passkeys effectively. Expect technical deep dives, best practices for user experience, case studies from successful implementations, and answers to your questions.

Here's what we'll cover during Spotlight Week: Passkeys:

Monday, Nov 18: Get started with passkeys

We'll start off the week with resources to help you begin passkey integration. Check out these resources to get started!

Key resources include a quick video on passkey basics, updated UX guidelines for Credential Manager and passkeys, and an in-depth server-side implementation guide. We will introduce you to the Identity hub, a comprehensive resource for passkeys, passwords, Sign in with Google, authorization, and much more.


Understand passkeys in 4 minutes

Tuesday, Nov 19: Updated passkeys developer guides

We'll share updated passkeys developer guidance, including migration guides, a new troubleshooting guide, and more. Highlights include a guide on migrating from legacy APIs to Credential Manager, technical details on FIDO2 attestation format changes, and a troubleshooting guide for common Credential Manager errors. 

Developers can also share feedback through a passkeys survey to influence future improvements.


Wednesday, Nov 20: New Credential Manager features

We'll go over some of the new Credential Manager capabilities, including improvements to autofill, single-tap sign-in, and the new Restore Credentials feature. Key updates include showing Credential Manager results as autofill suggestions, single-tap sign-in, Signal API for Chrome desktop and a Restore Credentials feature, which allows users to conveniently recover their saved login information in case of device loss or upgrades, ensuring uninterrupted access to their accounts. With Android 15, these additions streamline user authentication and reinforce security, making it easier for users to manage and access their credentials securely.


Thursday, Nov 21: Passkeys #AskAndroid

On Thursday at 9AM PT Spotlight Week: Passkeys will feature an #AskAndroid session to address your most pressing passkey questions. We'll also share case studies with Tokyu and X, highlighting their successful deployments of passkey authentication.


Friday, Nov 22: Learn more about passkeys

We'll close out the week with learning pathways for passkeys on Android and Chrome, insights from partners, and a new Compose sample app for Credential Manager with Android best practices and built using Compose.


We hope you'll join us in exploring these resources to learn how to elevate your app's security and user experience. We're excited to share this journey with you!

Passkeys Spotlight Week begins November 18th

Posted by Joseph Lewis – Technical Writer, Android Developer Relations

Tired of headaches with passwords? Ready for a future where online authentication is both faster and more secure? Then mark your calendars for Passkeys Week, November 18-22! Passkeys are an easier and more secure alternative to passwords, and are increasingly becoming the industry standard. Google is proud to support passkeys across Chrome, Android and beyond.

Part of our Spotlight Weeks series, this is your opportunity to dive deep into the world of passkeys – the revolutionary technology poised to replace passwords for good. Whether you're an Android or web developer, a security researcher, or just curious about the future of online identity, this week has something for you.

What are passkeys? They're a new type of credential that are far more secure than passwords and much easier to use. Imagine logging in with your device lock you already have set up, such as a fingerprint scan or a face scan, instead of typing out a complex string of characters. No password is used or stored on a server that could be compromised, keeping you safe from phishing attacks. And since there's no password, there' s no arcane string of characters to remember. That's the power of passkeys.

What you'll get out of Passkeys Spotlight Week

    • Gain expert insights: Join a video roundtable with Google identity experts to hear how passkeys are transforming the sign-in experience. Ask your questions on social media tagged with #PasskeysWeek, or submit your questions using our form.
    • Sharpen your skills: Explore informative blog posts and practical code samples to learn how to integrate passkeys into your own Android apps and websites.
    • Discover cross-platform solutions: See how passkeys work seamlessly across different operating systems and devices for a unified login experience.
    • Stay ahead of the curve: Get the latest updates on passkey advancements and learn about modern identity integration solutions.

We're showcasing content designed to enhance your developer experience and help you get started with adopting passkeys. These items will include:

    • In-depth blog posts covering various aspects of passkey implementation and best practices.
    • Practical code samples to help you get started with passkeys integration.
    • A video roundtable where we answer your questions about passkeys, answered by Google experts.
    • Case studies from developers who have already implemented passkeys.

How to participate

Passkeys Spotlight Week will happen entirely online at web.dev, developer.chrome.com and developer.android.com, and across Android and Chrome's Developer’s social media channels:

Follow us for the latest updates, spread the word about Passkeys Spotlight Week, and use #PasskeysWeek on your favorite social media platforms to ask questions and share your passkeys projects with the community. Check the Android Identity developer page on Monday, November 18, 2024 to read our next blog post with full details!

Don't miss this opportunity to learn from the best and be part of the passwordless revolution. Join us for Passkeys Spotlight Week and help shape the future of online authentication!

Chrome on Android to support third-party autofill services natively

Posted by Eiji Kitamura – Developer Advocate

Chrome on Android will soon allow third-party autofill services (like password managers) to natively autofill forms on websites. Developers of these services need to tell their users to toggle a setting in Chrome to continue using their service with Chrome.


Background

Google is the default autofill service on Chrome, providing passwords, passkeys and autofill for other information like addresses and payment data.

A third-party password manager can be set as the preferred autofill service on Android through System Settings. The preferred autofill service can fill across all Android apps. However, to autofill forms on Chrome, the autofill service needs to use "compatibility mode". This causes glitches on Chrome such as janky page scrolling and potentially showing duplicate suggestions from Google and a third-party.

With this coming change, Chrome on Android will allow third-party autofill services to natively autofill forms giving users a smoother and simpler user experience. Third-party autofill services can autofill passwords, passkeys and other information like addresses and payment data, as they would in other Android apps.


Try the feature yourself

You can already test the functionality on Chrome 131 and later. First, set a third-party autofill service as preferred in Android 14:

Note: Instructions may vary by device manufacturer. The below steps are for a Google Pixel device running Android 15.
    1. Open Android's System Settings
    2. Select Passwords, passkeys & accounts
    3. Tap on Change button under Preferred service
    4. Select a preferred service
    5. Confirm changing the preferred autofill service

Side by side screenshots show the steps involved in enabling third-party autofill service from your device: first tap 'Change', then select the new service, and finally confirm the change.

Secondly, enable third-party autofill service on Chrome

    1. Open Chrome on Android
    2. Open chrome://flags#enable-autofill-virtual-view-structure
    3. Set the flag to "Enabled" and restart
    4. Open Chrome's Settings and tap Autofill Services
    5. Choose Autofill using another service
    6. Confirm and restart Chrome
Note: Steps 2 and 3 are not necessary after Chrome 131. Chrome 131 is scheduled to be stable on November 12th, 2024.
Side by side screenshots show the steps involved in changing your preferred password service on a smartphone: first tap 'Autofill Services', then select 'Autofill using another service', and finally restart Chrome to complete setup.

You can emulate how Chrome behaves after compatibility mode is disabled by updating chrome://flags#suppress-autofill-via-accessibility to Enabled.

Actions required from third-party autofill services

Implementation wise, autofill service developers don't need an additional implementation as long as they have a proper integration with autofill services. Chrome will gracefully respect it and autofill forms.

Chrome plans to stop supporting compatibility mode in early 2025. Users must select Autofill using another service in Chrome settings to ensure their autofill experience is unaffected. The new setting is available in Chrome 131. You should encourage your users to toggle the setting, to ensure they have the best autofill experience possible with your service and Chrome on Android.


Timeline

    • October 16th, 2024: Chrome 131 beta is available
    • November 12th, 2024: Chrome 131 is in stable
    • Early 2025: Compatibility mode is no longer available on Chrome

Attestation format change for the Android FIDO2 API

Posted by Christiaan Brand – Group Product Manager

In 2019 we introduced a FIDO2 API, adopted by many leading developers, which allows users to generate an attested, device-bound FIDO2 credential on Android devices.

Since this launch, Android has generated an attestation statement based on the SafetyNet API. As the underlying SafetyNet API is being deprecated, the FIDO2 API must move to a new attestation scheme based on hardware-backed key attestation. This change will require action from developers using the FIDO2 API to ensure a smooth transition.

The FIDO2 API is closely related to, but distinct from, the passkeys API and is invoked by setting the residentKey parameter to discouraged. While our goal is over time to migrate developers to the passkey API, we understand that not all developers who are currently using the FIDO2 API are ready for that move and we continue working on ways to converge these two APIs.

We will update the FIDO2 API on Android to produce attestation statements based on hardware-backed key attestation. As of November 2024, developers can opt in to this attestation scheme with controls for individual requests. This should be useful for testing and incremental rollouts, while also allowing developers full control over the timing of the switch over the next 6 months.

We will begin returning hardware-backed key attestation by default for all developers in early April 2025. From that point, SafetyNet certificates will no longer be granted. It is important to implement support for the new attestation statement, or move to the passkey API before the cutover date, otherwise your applications might not be able to parse the new attestation statements.

For web apps, requesting hardware-backed key attestation requires Chrome 130 or higher to enroll in the WebAuthn attestationFormats origin trial. (Learn more about origin trials.) Once these conditions are met, you can specify the attestationFormats parameter in your navigator.credentials.create call with the value ["android-key"].

If you're using the FIDO2 Play Services API in an Android app, switching to hardware-backed key attestation requires Play Services version 22.0.0 on the device. Developers can then specify android-key as the attestation format in the PublicKeyCredentialCreationOptions. You must update your Play Services dependencies to see this new option.

We will continue to evolve FIDO APIs. Please continue to provide feedback using [email protected] to connect with the team and developer community.

Credential Manager beta: easy & secure authentication with passkeys on Android

Posted by Diego Zavala, Product Manager, and Niharika Arora, Android Developer Relations Engineer

Today, we are excited to announce the beta release of Credential Manager with a finalized API surface, making it suitable for use in production. As we previously announced, Credential Manager is a new Jetpack library that allows app developers to simplify their users' authentication journey, while also increasing security with support of passkeys.

Authentication provides secure access to personalized experiences, but it has challenges. Passwords, which are widely used today, are difficult to use, remember and are not always secure. Many applications and services require two-factor authentication (2FA) to login, adding more friction to the user's flow. Lastly, sign-in methods have proliferated, making it difficult for users to remember how they signed in. This proliferation has also added complexity for developers, who now need to support multiple integrations and APIs.

Credential Manager brings support for passkeys, a new passwordless authentication mechanism, together with traditional sign-in methods, such as passwords and federated sign-in, into a single interface for the user and a unified API for developers.


image showing end-to-end journey to sign in using a passkey on a mobile device
End-to-end journey to sign in using a passkey

With Credential Manager, users will benefit from seeing all their credentials in one place; passkeys, passwords and federated credentials (such as Sign in with Google), without needing to tap three different places. This reduces user confusion and simplifies choices when logging in.


image showing the unified account selector that support multiple credential types across multiple accounts on a mobile device
Unified account selector that support multiple credential types across multiple accounts

Credential Manager also makes the login experience simpler by deduping across sign-in methods for the same account and surfacing only the safest and simplest authentication method, further reducing the number of choices users need to make. 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 instead of the underlying technology.


image showing how a passkey and a password for the same account are deduped on a mobile device
A passkey and a password for the same account are deduped

For developers, Credential Manager supports multiple sign-in mechanisms within a single API. It provides 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.

Who is already using Credential Manager?

Kayak has already integrated with Credential Manager, providing users with the advantages of passkeys and simpler authentication flows.

"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. As a bonus, implementing the new Credential Manager library also reduced technical debt in our code base by putting passkeys, passwords and Google sign-in all into one new modern UI. Indeed, users are able to sign up to Kayak with passkeys twice as fast as with an email link, which also improves the sign-in completion rate."  

– Matthias Keller, Chief Scientist and SVP, Technology at Kayak 

Something similar is observed on Shopify

“Passkeys work across browsers and our mobile app, so it was a no-brainer decision for our team to implement, and the resulting one-tap user experience has been truly magical. Buyers who are using passkeys to log in to Shop are doing so 14% faster than those who are using other login methods (such as email or SMS verification)”

– Mathieu Perreault, Director of Engineering at Shopify

Support for multiple password managers

Credential Manager on Android 14 and higher supports multiple password managers at the same time, enabling users to choose the provider of their choice to store, sync and manage their credentials. We are excited to be working with several leading providers like Dashlane on their integration with Credential Manager.

“Adopting passkeys was a no-brainer for us. It simplifies sign-ins, replaces the guesswork of traditional authentication methods with a reliable standard, and helps our users ditch the downsides of passwords. Simply put, it’s a big win for both us and our users. Dashlane is ready to serve passkeys on Android 14!”

– Rew Islam, Director of Product Engineering and Innovation at Dashlane

Get started

To start using Credential Manager, you can refer to our integration guide.

We'd love to hear your input during this beta release, so please let us know about your experience integrating with Credential Manager, using passkeys, or any other feedback you might have: