Tag Archives: Authentication

Google Ads API Introducing New Error Codes for Invalid Developer Tokens Starting April 28, 2025

Previously, if any Google Ads API request had an invalid developer token, the API returned an OAUTH_TOKEN_HEADER_INVALID error, which is also used for other invalid request header values. To make it clear when the authentication error is specifically caused by an invalid developer token, we are changing the API to return a new error code, DEVELOPER_TOKEN_INVALID, for version v19.1 of the Google Ads API. All API versions before v19 will handle invalid developer tokens by throwing a DEVELOPER_TOKEN_NOT_APPROVED error instead. If you are using version v19 of the API with our client libraries, you will need to update to the latest version of the client libraries after the v19.1 release. These changes will be effective starting April 28, 2025.

Anyone who has already set up the Google Ads API to make successful calls are highly unlikely to be affected by this change. It is mainly meant to improve the experience of new developers onboarding to the API.

If you have any questions, please ask them in the Google Ads API forum. We're here to help!

Upcoming changes to CustomerService in Google Ads API

We are introducing several changes to the CustomerService.CreateCustomerClient method to align the Google Ads API with how Google Ads UI handles new account creation functionality. These changes will take effect on March 17, 2025.

New error codes for policy enforcement
In order to limit abuse, the Google Ads API introduced two new error codes in the version v19 of the API for the purpose of policy enforcement.
  1. Google Ads manager accounts that do not have a certain threshold of spending or a certain number of active child accounts without policy issues (for example, not suspended or closed for policy violations) will be ineligible to create child accounts under them. Developers will receive a CustomerError.CREATION_DENIED_INELIGIBLE_MCC error code in the upcoming version v19 of the Google Ads API. To fix the issue, link a Google Ads account that is compliant with the Google policies and meets the threshold spending levels under your manager account.
  2. Google Ads manager accounts that have been flagged for policy violations related to account creation will no longer be able to create child accounts under them. Developers will receive a CustomerError.CREATION_DENIED_FOR_POLICY_VIOLATION error code in the upcoming version v19 of the Google Ads API.
In both these cases, existing API versions (v18 and older) will throw a ContextError.OPERATION_NOT_PERMITTED_FOR_CONTEXT error instead.

Quota limits for account creation
The Google Ads API will enforce limits on creation of new Google Ads accounts. Developers will receive a QuotaError.RESOURCE_EXHAUSTED error once the limits are reached. The retry_delay field of the quota_error_details contains additional details on how long you should wait before retrying the API call. We do not expect most developers to be affected by these limits.

What do I need to do?
If your application uses the Google Ads API to create new Google Ads accounts, you should review your code to ensure that your application correctly handles these new error codes.

If you have any questions or need help, check out the Google Ads API support page for options.Reach out to the Google Ads product support team for any questions related to account policies.

Consent unbundling in Ads APIs

What’s changing?
Starting the week of May 1 2025, we will roll out consent unbundling for OAuth user authentication to all Google Cloud projects which were created before 2019. If you own an application that uses an Ads-related API through a Google Cloud project created before 2019, you may need to update your application to handle unbundled user consent before May 1 2025.

Background
Consent unbundling for OAuth user authentication flow allows users to customize which specific OAuth scopes they want to authorize your application for, rather than an all-or-nothing approach. All the Google Cloud console projects created since 2019 have this feature turned on, whereas all the projects created before 2019 have this feature turned off.

The following screenshot shows the difference between an all-or-nothing consent prompt, and an unbundled consent prompt. Figure 1: All-or-nothing consent screen. Users aren’t allowed to choose from a list of OAuth scopes.

Figure 2: Unbundled consent screen. Users are allowed to choose from a list of OAuth scopes.

Who is affected by this change?
You will be affected by this change if ALL of the following conditions are met:
  1. Your API application uses a Google Cloud Console project that was created before 2019.
  2. Your application implements the OAuth 2.0 user consent flow – an authentication workflow where the user logs in with their Google account and grants one or more permissions that your application is requesting.
  3. Your application uses more than one Google API, and one of the APIs is an Ads-related API listed below.
Who isn’t affected by this change?
  • Existing refresh tokens: This change doesn’t affect user authentications that you already have in place. Your existing refresh tokens will continue to work without any changes or re-authentication.
  • Single scope applications: If your application uses only one Google API scope, your application isn’t affected by this change, since there aren’t multiple OAuth scope to unbundle.
  • Single user applications / Manually authenticated applications: Your application doesn’t have an explicit OAuth user authentication flow implemented. Instead, you use a manual authentication script such as GenerateUserCredentials, gcloud CLI or OAuth Playground to authenticate the user, and then use those credentials for a long period of time. Since you select all the scopes that your application requires while authenticating, your application isn’t affected by this change.
  • Service accounts: If your application uses a service account to authenticate your API calls, you won’t be affected by this change

What do I need to do?
You need to ensure that your application can handle partial user consent. To do this,
  1. Request the list of OAuth scopes that the user consented to by including the include_granted_scopes parameter in your OAuth flow.
  2. Examine the actual list of OAuth scopes that the user consented in the OAuth response.
  3. Implement incremental authorization in your application.
Review our OAuth granular consent guide to learn about the requirements and best practices to handle granular consent.

How do I test this feature?
There are two ways to test this feature:
  1. Create a new Google Cloud project: New Google Cloud projects have enabled OAuth consent unbundling. So you can create a new Google Cloud project, and use it for testing your application.
  2. Enable consent unbundling in your existing project: You can set the enable_granular_consent parameter to true in your OAuth authorization request.
Which API scopes are affected?
The following APIs related to Ads are affected by this change.
API OAuth Scope
Google Ads API https://adwords.google.com/api/adwords
Google Ad Manager API (SOAP API, Beta) https://www.googleapis.com/auth/dfp
https://www.googleapis.com/auth/admanager
Bid Manager API https://www.googleapis.com/auth/doubleclickbidmanager
Content API for Shopping https://www.googleapis.com/auth/content
Display and Video 360 API https://www.googleapis.com/auth/display-video-mediaplanning
https://www.googleapis.com/auth/display-video-user-management
AdMob API https://www.googleapis.com/auth/admob.report
https://www.googleapis.com/auth/admob.googlebidding.readwrite
https://www.googleapis.com/auth/admob.monetization
AdSense for Platforms API https://www.googleapis.com/auth/adsensehost
https://www.googleapis.com/auth/adsense
https://www.googleapis.com/auth/adsense.readonly
Google Analytics API https://www.googleapis.com/auth/analytics
https://www.googleapis.com/auth/analytics.readonly
https://www.googleapis.com/auth/analytics.edit
https://www.googleapis.com/auth/analytics.manage.users
https://www.googleapis.com/auth/analytics.manage.users.readonly
https://www.googleapis.com/auth/analytics.provision
https://www.googleapis.com/auth/analytics.user.deletion
Campaign Manager 360 API https://www.googleapis.com/auth/ddmconversions
https://www.googleapis.com/auth/dfareporting
https://www.googleapis.com/auth/dfatrafficking
Search Ads 360 API https://www.googleapis.com/auth/doubleclicksearch
Google Tag Manager API https://www.googleapis.com/auth/tagmanager.delete.containers
https://www.googleapis.com/auth/tagmanager.edit.containers
https://www.googleapis.com/auth/tagmanager.edit.containerversions
https://www.googleapis.com/auth/tagmanager.manage.accounts
https://www.googleapis.com/auth/tagmanager.manage.users
https://www.googleapis.com/auth/tagmanager.publish
https://www.googleapis.com/auth/tagmanager.readonly
Real time bidding API https://www.googleapis.com/auth/realtime-bidding
Authorized Buyers Marketplace API https://www.googleapis.com/auth/authorized-buyers-marketplace
https://www.googleapis.com/auth/adexchange.buyer

How to get help
If you have any questions or need help, reach out to your respective API’s support team with your questions.

Improved support for service accounts in the Google Ads API

Google Ads has rolled out a new feature that allows Google Ads account administrators to grant access to a service account. Once the access has been granted, you can use the service account credentials to make API calls to that Google Ads account and other accounts in that hierarchy, if applicable. Refer to the service account guide to learn more about this option.

This new approach simplifies the Google Ads API authentication process in two important ways:

  1. If your application works entirely offline without any user interaction, then you no longer need to generate a refresh token. This means you can also avoid other steps such as configuring an OAuth consent screen and performing OAuth App verification.
  2. The new service account flow doesn’t require you to be a Google Workspace user or configure the service account for domain-wide impersonation.

We hope this simplifies your experience when working with the Google Ads API.

How to get help

If you have any questions or need help, check out the Google Ads API support page for options.

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!

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: