Posted by Niharika Arora – Senior Developer Relations Engineer at Google, Thomás Oliveira Horta – Android Engineer at Uber

How Uber is reducing manual logins by 4 million per year with the Restore Credentials API

Uber is the world’s largest ridesharing company, getting millions of people from here to there while also supporting food delivery, healthcare transportation, and freight logistics. Simplicity of access is crucial to its success; when users switch to a new device, they expect a seamless transition without needing to log back into the Uber app or go through SMS-based one-time password authentication. This frequent device turnover presents a challenge, as well as an opportunity for strong user retention. 

To maintain user continuity, Uber’s engineers turned to the Restore Credentials feature, an essential tool for a time when 40% of people in the United States replace their smartphone every year. Following an assessment of user demand and code prototyping, they introduced Restore Credentials support in the Uber rider app. To validate that restoring credentials helps remove friction for re-logins, the Uber team ran a successful A/B experiment for a five-week period. The integration led to a reduction in manual logins that, when projected across Uber’s massive user base, is estimated to eliminate 4 million manual logins annually.

Eliminating login friction with Restore Credentials

The Restore Credentials API eliminates the multi-step manual sign in process on new devices.

There were past attempts at account restoration on new devices using solutions like regular data backup and BlockStore, though both solutions required sharing authentication tokens directly, from source device to destination device. Since token information is highly sensitive, these solutions are only used to some extent, to pre-fill login fields on the destination device and reduce some friction during the sign-in flows. Passkeys are also used to provide a secure and fast login method, but their user-initiated nature limits their impact on seamless device transitions.

“Some users don’t use the Uber app on a daily basis, but they expect it will just work when they need it,” said Thomás Oliveira Horta, an Android engineer at Uber. “Finding out you’re logged out just as you open the app to request a ride on your new Android phone can be an unpleasant, off-putting experience.”

With Restore Credentials, the engineers were able to bridge this gap. The API generates a unique token on the old device, which is seamlessly and silently moved to the new device when the user restores their app data during the standard onboarding process. This process leverages Android OS’s native backup and restore mechanism, ensuring the safe transfer of the restore key along with the app’s data. The streamlined approach guarantees a simple and safe account transfer, meeting Uber’s security requirements without any additional user input or development overhead.

“With the adoption of Restore Credentials on Uber’s rider app, we started seeing consistent usage,” Thomás said. “An average of 10,000 unique daily users have signed in with Restore Credentials in the current rollout stage, and they’ve enjoyed a seamless experience when opening the app for the first time on a new device. We expect that number to double once we expand the rollout to our whole userbase.”

Implementation Considerations

“Integration was pretty easy with minor adjustments on the Android side by following the sample code and documentation,” Thomás said. “Our app already used Credential Manager for passkeys, and the backend required just a couple of small tweaks. Therefore, we simply needed to update the Credential Manager dependency to its latest version to get access to the new Restore Credentials API. We created a restore key via the same passkey creation flow and when our app is launched on a new device, the app proactively checks for this key by attempting a silent passkey retrieval. If the restore key is found, it is immediately utilized to automatically sign the user in, bypassing any manual login.”

Throughout the development process, Uber’s engineers navigated a few challenges during implementation—from choosing the right entry point to managing the credential lifecycle on the backend.

Choosing the Restore Credentials entry point

The engineers carefully weighed the tradeoffs between a perfectly seamless user experience and implementation simplicity when selecting which Restore Credentials entry point to use for recovery. Ultimately, they prioritized a solution that offered an ideal balance.

“This can take place during App Launch or in the background during device restoration and setup, using BackupAgent,” Thomás said. “The background login entry point is more seamless for the user, but it presented challenges with background operations and required usage of the BackupAgent API, which would have led to increased complexity in a codebase as large as Uber’s.” They decided to implement the feature during the first app launch, which was significantly faster than the manual login.

Addressing server-side challenges

A few server-side challenges arose during integration with the backend WebAuthn APIs, as their design assumed user verification would always be required, and that all credentials would be listed in a user’s account settings; neither of these assumptions worked for the non-user-managed Restore Credential keys.

The Uber team resolved this by making minor changes to the WebAuthn services, creating new credential types to distinguish passkeys from Restore Credentials and process them appropriately.

Managing the Restore Credentials lifecycle

Uber’s engineers faced several challenges in managing the credential keys on the backend, with specialized support from backend engineer Ryan O’Laughlin:

• Preventing orphaned keys: A significant challenge was defining a strategy for deleting registered Public Keys to prevent them from becoming “orphaned.” For example, uninstalling the app deletes the local credential, but because this action doesn’t signal the backend, it leaves an unused key on the server.

• Balancing key lifespan: Keys needed a “time to live” that was long enough to handle edge cases. For example, if a user goes through a backup and restore, then manually logs out from the old device, the key is deleted from that old device. However, the key must remain valid on the server so the new device can still use it.

• Supporting multiple devices: Since a user might have multiple devices (and could initiate a backup and restore from any of them), the backend needed to support multiple Restore Credentials per user (one for each device).

Uber’s engineers addressed these challenges by establishing rules for server-side key deletion based on new credential registration and credential usage.

The feature went from design to delivery in a rapid two-month development and testing process. Afterward, a five-week A/B experiment (time to validate the feature with users) went smoothly and yielded undeniable results. 

Preventing user drop-off with Restore Credentials

By eliminating manual logins on new devices, Uber retained users who might have otherwise abandoned the sign-in flow on a new device. This boost in customer ease was reflected in a wide array of improvements, and though they may seem slight at a glance, the impact is massive at the scale of Uber’s user base: 

• 3.4% decrease in manual logins (SMS OTP, passwords, social login).

• 1.2% reduction in expenses for logins requiring SMS OTP.

• 0.575% increase in Uber’s access rate (% of devices that successfully reached the app home screen).

• 0.614% rise in devices with completed trips.

Today, Restore Credentials is well on its way to becoming a standard part of Uber’s rider app, with over 95% of users in the trial group registered.

[UI flow]

During new device setup, users can restore app data and credentials from a backup. After selecting Uber for restoration and the background process finishes, the app will automatically sign the user in on the new device’s first launch.

The invisible yet massive impact of Restore Credentials

In the coming months, Uber plans to expand the integration of Restore Credentials. Projecting from the trial’s results, they estimate the change will eliminate 4 million manual logins annually. By simplifying app access and removing a key pain point, they are actively building a more satisfied and loyal customer base, one ride at a time.

“Integrating Google’s RestoreCredentials allowed us to deliver the seamless ‘it just works’ experience our users expect on a new device,” said Matt Mueller, Lead Project Manager for Core Identity at Uber. “This directly translated to a measurable increase in revenue, proving that reducing login friction is key to user engagement and retention.”

Ready to enhance your app’s login experience?

Learn how to facilitate a seamless login experience when switching devices with Restore Credentials and read more in the blog post. In the latest canary of the Android Studio Otter you can validate your integration, as new features help mock the backup and restoring mechanisms. 

If you are new to Credential Manager, you can refer to our official documentation,

codelab and samples for help with integration.

Posted by Niharika Arora (X and LinkedIn) – Senior Developer Relations Engineer and Vinisha Athwani – Technical Writer (LinkedIn)

In a world where digital security is becoming increasingly critical, passwords have become a notorious weak link – they’re cumbersome, often insecure, and a source of frustration for users and developers. But there’s good news: passkeys are gaining popularity as the most user-friendly, phishing-resistant, and secure authentication mechanism available. For Android developers, the Credential Manager API helps you guide your users towards using passkeys while ensuring continued support for traditional sign-in mechanisms, such as passwords.

In this blog, we discuss some of the best practices you should follow while encouraging users to transition to passkeys.

Understand authentication with passkeys

Before diving into the recommendations for encouraging the transition to passkeys, here’s an overview of the fundamentals of authentication with passkeys:

• Passkeys: These are cryptographic credentials that replace passwords. Passkeys are associated with device unlocking mechanisms, and are the recommended method of authentication for apps and sites.
• Credential Manager: A Jetpack API that provides a unified API interface for interacting with different types of authentication, including passkeys, passwords, and federated sign-in mechanisms like Sign in with Google.

How do passkeys help your users?

There are several tangible benefits that users experience in apps that allow them to use passkeys to sign in. The highlights of using passkey for users are as follows:

• Improved sign-in experience: Users get the same UI whether they use passwords, passkeys or federated sign-in mechanisms like Sign in with Google.
• Reduced sign-in time: Instead of typing out passwords, users use their phone unlock mechanisms, such as biometrics, resulting in a smooth sign-in experience.
• Improved security: Passkeys use public-key cryptography so that data breaches of service providers don’t result in a compromise of passkey-protected accounts, and are based on industry standard APIs and protocols to ensure they are not subject to phishing attacks. (Read more about syncing and security here).
• Unified experience across devices: With the ability to sync passkeys across devices, users benefit from simplified authentication regardless of the device they’re using.
• No friction due to forgotten passwords!

Underscoring the improved experience with passkeys, we heard from several prominent apps. X observed that login rates improved 2x after adding passkeys to their authentication flows. KAYAK, a travel search engine, observed that the average time it takes their users to sign up and sign in reduced by 50% after they incorporated passkeys into their authentication flows. Zoho, a comprehensive cloud-based software suite focused on security and seamless experiences, achieved 6x faster logins by adopting passkeys in their OneAuth Android app.

What’s in it for you?

When you migrate your app to use passkeys, you’ll be leveraging the Credential Manager API which is the recommended standard for identity and authentication on Android.

Apart from passkeys, the Credential Manager API supports traditional sign-in mechanisms, simplifying the development and maintenance of your authentication flows!

For all of these sign-in mechanisms, Credential Manager offers an integrated bottom-sheet UI, saving you development efforts while offering users a consistent experience.

When should you prompt users to use passkeys?

Now that we’ve established the benefits of passkeys, let’s discuss how you should encourage your users to migrate to passkeys.

The following are a list of UX flows in which you can promote passkeys:

• User account registration: Introduce passkey creation prompts at key moments, such as when your users create their accounts:

Contextual Prompts during account creation
• Sign in: We recommend you encourage users to prompt passkeys in the moment after a user signs in with an OTP, password, or other-sign in mechanisms.

Prompt passkey creation during sign-in
• Account recovery: The critical user journey (CUJ) for account recovery is one that historically presents friction to users. Prompting users to adopt passkeys during account recovery is a recommended path. Users who adopt passkeys experience a familiar account recovery experience as during sign-in.

Account Recovery flow
• Password resets: This is the perfect moment to prompt users to create a passkey; after the frustration of a password reset, users are typically more receptive to the convenience and security passkeys offer.

Create a passkey for faster sign-in next time

How should you encourage the transition to passkeys?

Encouraging users to transition from passwords to passkeys requires a clear strategy. A few recommended best practices are as follows:

• Clear value proposition: Use simple, user-centric prompts to explain the benefits of passkeys. Use messaging that highlights the benefits for users. Emphasize the following benefits:
• Improved security benefits, such as safety from phishing.
• No need to type out a password.
• Ability to use the same passkey across devices/platforms.
• A consistent authentication experience.

Passkey prompt with clear value proposition
• Provide a seamless user experience:
• Use the unified UI provided by Credential Manager to show all available sign-in options, allowing the user to choose their preferred method without having to remember which one they used last.
• Use the official passkey icon to build user familiarity and create a consistent experience.
• Make sure that users can fall back to their traditional sign-in methods or a recovery method, such as a username and password, if a passkey is not available or if they are using a different device.

• Provide users with clarity about credentials within your app’s Settings UI: Make sure your users understand their authentications options by displaying helpful information about each passkey within your app’s settings. To learn more about adding credentials metadata, see the Credential Manager documentation.

Passkey Metadata on App’s Settings screen

• Educate users: Supplement the messaging to adopt passkeys with in-app educational resources or links that explain passkeys in detail.
• Progressive rollout: Consider a phased rollout to introduce passkeys to a subset of your user base to gather feedback and refine the user experience before a broader launch.

Developer Case Studies

Real-world developer experiences often highlight how small design choices—like when and where to surface a passkey prompt—can significantly influence adoption and user trust. To see this in action, let’s explore how top apps have strategically surfaced passkey prompts at key moments in their apps to drive stronger adoption :

Uber

To accelerate passkeys adoption, Uber is proactively promoting passkeys in various user journeys, alongside marketing strategies.

Uber has shared : “90+% of passkey enrollments come from promoting passkey creation at key moments inside the app as compared to onboarding and authentication CUJs“, underscoring the effectiveness of their proactive strategy.

Key learnings and strategies from their implementation:

• Offer passkeys without disrupting the core user experience: Uber added a new account checkup experience in their account settings to highlight passkey benefits, resulting in high passkey adoption rates.

User Account checkup flow

• Proactively bring passkeys to users: They learned not to wait for users to discover passkeys organically because relying on organic adoption would have been slower despite observed benefits like faster sign-ins and increased login success rates for passkey users.
• Use additional mediums to promote passkeys: Uber is also experimenting to promote passkeys through email campaigns or banners on a user’s account screen to highlight the new sign-in method, making their next sign-in easier and more secure.
• Respect your user’s choice: Recognizing that not all users are ready for passkeys, Uber implemented backoff logic in critical flows as sign in, signup screens and, in some contexts, offers passkeys alongside other familiar authentication methods.

Here’s what Uber has to say:

At Uber, we’ve seen users who adopt passkeys enjoy a faster, more seamless, and more secure login experience. To help more users benefit from passkeys, we’ve added nudges to create a passkey at key moments in the user experience: account settings, signup, and login. These proactive outreaches have significantly accelerated our passkey adoption. 

Ryan O’Laughlin

Senior Software Engineer, Uber

Economic Times

Economic Times, part of the Times Internet ecosystem, used a seamless user experience as the primary motivation for users to transition to passkeys.

After introducing targeted nudges, Economic Times observed ~10% improvements in passkey creation completion rate within the initial rollout period.

Key learnings and strategies from their implementation:

• Strategic passkey generation prompts: Initially, Economic Times was aggressively prompting passkey creation in multiple user flows, but it was observed that this approach disrupted business-critical journeys such as subscription purchases or unlocking premium features and was leading to abandoned carts.
• Refined approach: Economic Times made a deliberate decision to remove passkey generation prompts from sensitive flows (such as the subscription checkout flow) to prioritize immediate action completion.
• Targeted prompts: They strategically maintained passkey generation in areas where user intent to sign-in or manage authentication is high, such as initial sign-up flows, explicit sign in pages, or account management sections.
• Positive outcome: This refined deployment resulted in improved passkey generation numbers, indicating strong user adoption, without compromising user experience in critical business flows.

Passkeys Management Screen

Conclusion

Integrating passkeys with Android’s Credential Manager isn’t just about adopting new technology; it’s about building a fundamentally more secure, convenient, and delightful experience for your users. By focusing on intelligent passkey introduction, you’re not just securing accounts–you’re building trust and future-proofing your application’s authentication strategy.

To provide your users the best, optimized and seamless experience, follow the UX guidelines while implementing passkeys authentication with Credential Manager. Check out the docs today!

• Sample with UX best practices
• Sign in your user with Credential Manager
• API Reference – androidx.credentials
• User authentication with passkeys
• Google Safety Center – Passkey
• Google Security Blog: Security of Passkeys in the Google Password Manager

Posted by John Zoeller – Developer Relations Engineer, Loyrn Hairston – Product Marketing Manager, and Jonathan Salamon – Dashlane Staff Software Engineer

Dashlane is a password management and provision tool that provides a secure way to manage user credentials, access control, and authentication across multiple systems and applications.

Dashlane has over 18 million users and 20,000 businesses in 180 countries. It’s available on Android, Wear OS, iOS, macOS, Windows, and as a web app with an extension for Chrome, Firefox, Edge, and Safari.

Recently, they expanded their offerings by creating a Wear OS app with a Credential Provider integration from the Credential Manager API, bringing passkeys to their clients and users on smartwatches.

Streamlining Authentication on Wear OS

Dashlane users have frequently requested a Wear OS solution that provides standalone authentication for their favorite apps. In the past, Wear OS lacked the key APIs necessary for this request, which kept Dashlane from being able to provide the functionality. In their words:

“Our biggest challenge was the lack of a standard credentials API on Wear OS, which meant that it was impossible to bring our core features to this platform.”

This has changed with the introduction of the new Credential Manager API on Wear OS.

Credential Manager provides a simplified, standardized user sign-in experience with built-in authentication options for passkeys, passwords, and federated identities like Sign in with Google. Conveniently, it can be implemented with minimal effort by reusing the same code as the mobile version.

The Dashlane team was thrilled to learn about this, as it meant they could save a lot of time and effort: “[The] CredentialManager API provides the same API on phones and Wear OS; you write the code only once to support multiple form factors.”

After Dashlane had planned out their roadmap, they were able execute their vision for the new app with only a small engineering investment, reusing 92% of the Credential Manager code from their mobile app. And because the developers built Dashlane’s app UI with Jetpack Compose for Wear OS, 60% of their UI code was also reused.

Developing for Wear OS

To provide credentials to other apps with Credential Manager, Dashlane needed to implement the Credential Provider interface on Wear OS. This proved to be a simple exercise in calling their existing mobile code, where Dashlane had already implemented behavior for credential querying and credential selection.

For example, Dashlane was able to reuse their logic to handle client invocations of CredentialManager.getCredential. When a client invokes this, the Android framework propagates the client’s getCredentialRequest to Dashlane’s CredentialProviderService.onBeginGetCredentialRequest implementation to retrieve the credentials specified in the request.

Dashlane delegates the logic for onBeginGetCredentialRequest to their handleGetCredentials function, below, which is shared between their mobile and Wear OS implementations.

// When a Credential Manager client calls 'getCredential', the Android
// framework invokes `onBeginGetCredentialRequest`. Dashlane
// implemented this `handleGetCredentials` function to handle some of
// the logic needed for `onBeginGetCredentialRequest`
override fun handleGetCredentials(
    context: Context,
    request: BeginGetCredentialRequest):
List<CredentialEntry> =
  request.beginGetCredentialOptions.flatMap { option ->
    when (option) {
      // Handle passkey credential
      is BeginGetPublicKeyCredentialOption -> {
        val passkeyRequestOptions = Gson().fromJson(
            option.requestJson, PasskeyRequestOptions::class.java)

        credentialLoader.loadPasskeyCredentials(
          passkeyRequestOptions.rpId,
          passkeyRequestOptions.allowCredentials ?: listOf()
        ).map { passkey ->
          val passkeyDisplayName = getSuggestionTitle(passkey, context)

          PublicKeyCredentialEntry.Builder(
            context,
            passkeyDisplayName,
            pendingIntentForGet(context, passkey.id),
            option
          )
          .setLastUsedTime(passkey.locallyViewedDate)
          .setIcon(buildMicroLogomarkIcon(context = context))
          .setDisplayName(passkeyDisplayName)
          .build()
// Handle other credential types

Reusing precise logic flows like this made it a breeze for Dashlane to implement their Wear OS app.

“The Credential Manager API is unified across phones and Wear OS, which was a huge advantage. It meant we only had to write our code once.”

Impact and Improved Growth

The team is excited to be among the first credential providers on wearables: “Being one of the first on Wear OS was a key differentiator for us. It reinforces our brand as an innovator, focusing on the user experience, better meeting and serving our users where they are.”

As an early adopter of this new technology, Dashlanes Wear OS app has already shown early promise, as described by Dashlane software engineer, Sebastien Eggenspieler: “In the first 3 months, our Wear OS app organically grew to represent 1% of our active device install base.”

With their new experience launched, Wear OS apps can now rely on Dashlane as a trusted credential provider for their own Credential Manager integrations, using Dashlane to allow users to log in with a single tap; and users can view details about their credentials right from their wrist.

Dashlane’s Recommendations to Wear OS Developers

With their implementation complete, the Dashlane team can offer some advice for other developers who are considering the Credential Manager API. Their message is clear: “the future is passwordless… and passkeys are leading the way, [so] provide a passkey option.”

As a true innovator in their field, and the preferred credential provider for so many users, we are thrilled to have Dashlane support Credential Manager. They truly inspired us with their commitment to providing Wear OS users with the best experience possible:

“We hope that in the future every app developer will migrate their existing users to the Credential Manager API.”

Get Started with Credential Manager

With its elegant simplicity and built-in secure authentication methods, the Credential Manager API provides a simple, straightforward authentication experience for users that changes the game in Wear OS.

Want to find out more about how Dashlane is driving the future of end-user authentication? Check out our video blog with their team in Paris, and read about how they found a 70% in sign-in conversion rates with passkeys.

To learn more about how you can implement Credential Manager, read our official developer and UX guides, and be sure to check out our brand new blog post and video blog as part of Wear OS Spotlight week!

We’ve also expanded our existing Credential Manager sample to support Wear OS, to help guide you along the way, and if you’d like to provide credentials like Dashlane, you can use our Credential Provider sample.

Finally, explore how you can start developing additional experiences for Wear OS today with our documentation and samples.

Posted by Niharika Arora – Senior Developer Relations Engineer, Joseph Lewis – Staff Technical Writer, and Kumareshwaran Sreedharan – Product Manager, Zoho.

As an Android developer, you’re constantly looking for ways to enhance security, improve user experience, and streamline development. Zoho, a comprehensive cloud-based software suite focused on security and seamless experiences, achieved significant improvements by adopting passkeys in their OneAuth Android app.

Since integrating passkeys in 2024, Zoho achieved login speeds up to 6x faster than previous methods and a 31% month-over-month (MoM) growth in passkey adoption.

This case study examines Zoho’s adoption of passkeys and Android’s Credential Manager API to address authentication difficulties. It details the technical implementation process and highlights the impactful results.

Overcoming authentication challenges

Zoho utilizes a combination of authentication methods to protect user accounts. This included Zoho OneAuth, their own multi-factor authentication (MFA) solution, which supported both password-based and passwordless authentication using push notifications, QR codes, and time-based one-time passwords (TOTP). Zoho also supported federated logins, allowing authentication through Security Assertion Markup Language (SAML) and other third-party identity providers.

Challenges

Zoho, like many organizations, aimed to improve authentication security and user experience while reducing operational burdens. The primary challenges that led to the adoption of passkeys included:

• Security vulnerabilities: Traditional password-based methods left users susceptible to phishing attacks and password breaches.
• User friction: Password fatigue led to forgotten passwords, frustration, and increased reliance on cumbersome recovery processes.
• Operational inefficiencies: Handling password resets and MFA issues generated significant support overhead.
• Scalability concerns: A growing user base demanded a more secure and efficient authentication solution.

Why the shift to passkeys?

Passkeys were implemented in Zoho’s apps to address authentication challenges by offering a passwordless approach that significantly improves security and user experience. This solution leverages phishing-resistant authentication, cloud-synchronized credentials for effortless cross-device access, and biometrics (such as a fingerprint or facial recognition), PIN, or pattern for secure logins, thereby reducing the vulnerabilities and inconveniences associated with traditional passwords.

By adopting passkeys with Credential Manager, Zoho cut login times by up to 6x, slashed password-related support costs, and saw strong user adoption – doubling passkey sign-ins in 4 months with 31% MoM growth. Zoho users now enjoy faster, easier logins and phishing-resistant security.

Implementation with Credential Manager on Android

So, how did Zoho achieve these results? They used Android’s Credential Manager API, the recommended Jetpack library for implementing authentication on Android.

Credential Manager provides a unified API that simplifies handling of the various authentication methods. Instead of juggling different APIs for passwords, passkeys, and federated logins (like Sign in with Google), you use a single interface.

Implementing passkeys at Zoho required both client-side and server-side adjustments. Here’s a detailed breakdown of the passkey creation, sign-in, and server-side implementation process.

Passkey creation

To create a passkey, the app first retrieves configuration details from Zoho’s server. This process includes a unique verification, such as a fingerprint or facial recognition. This verification data, formatted as a requestJson string), is used by the app to build a CreatePublicKeyCredentialRequest. The app then calls the credentialManager.createCredential method, which prompts the user to authenticate using their device screen lock (biometrics, fingerprint, PIN, etc.).

Upon successful user confirmation, the app receives the new passkey credential data, sends it back to Zoho’s server for verification, and the server then stores the passkey information linked to the user’s account. Failures or user cancellations during the process are caught and handled by the app.

Sign-in

The Zoho Android app initiates the passkey sign-in process by requesting sign-in options, including a unique challenge, from Zoho’s backend server. The app then uses this data to construct a GetCredentialRequest, indicating it will authenticate with a passkey. It then invokes the Android CredentialManager.getCredential() API with this request. This action triggers a standardized Android system interface, prompting the user to choose their Zoho account (if multiple passkeys exist) and authenticate using their device’s configured screen lock (fingerprint, face scan, or PIN). After successful authentication, Credential Manager returns a signed assertion (proof of login) to the Zoho app. The app forwards this assertion to Zoho’s server, which verifies the signature against the user’s stored public key and validates the challenge, completing the secure sign-in process.

Server-side implementation

Zoho’s transition to supporting passkeys benefited from their backend systems already being FIDO WebAuthn compliant, which streamlined the server-side implementation process. However, specific modifications were still necessary to fully integrate passkey functionality.

The most significant challenge involved adapting the credential storage system. Zoho’s existing authentication methods, which primarily used passwords and FIDO security keys for multi-factor authentication, required different storage approaches than passkeys, which are based on cryptographic public keys. To address this, Zoho implemented a new database schema specifically designed to securely store passkey public keys and related data according to WebAuthn protocols. This new system was built alongside a lookup mechanism to validate and retrieve credentials based on user and device information, ensuring backward compatibility with older authentication methods.

Another server-side adjustment involved implementing the ability to handle requests from Android devices. Passkey requests originating from Android apps use a unique origin format (android:apk-key-hash:example) that is distinct from standard web origins that use a URI-based format (https://example.com/app). The server logic needed to be updated to correctly parse this format, extract the SHA-256 fingerprint hash of the app’s signing certificate, and validate it against a pre-registered list. This verification step ensures that authentication requests genuinely originate from Zoho’s Android app and protects against phishing attacks.

This code snippet demonstrates how the server checks for the Android-specific origin format and validates the certificate hash:

val origin: String = clientData.getString("origin")

if (origin.startsWith("android:apk-key-hash:")) { 
    val originSplit: List<String> = origin.split(":")
    if (originSplit.size > 3) {
               val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])

                if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
            throw IAMException(IAMErrorCode.WEBAUTH003)
        }
    } else {
        // Optional: Handle the case where the origin string is malformed    }
}

Error handling

Zoho implemented robust error handling mechanisms to manage both user-facing and developer-facing errors. A common error, CreateCredentialCancellationException, appeared when users manually canceled their passkey setup. Zoho tracked the frequency of this error to assess potential UX improvements. Based on Android’s UX recommendations, Zoho took steps to better educate their users about passkeys, ensure users were aware of passkey availability, and promote passkey adoption during subsequent sign-in attempts.

This code example demonstrates Zoho’s approach for how they handled their most common passkey creation errors:

private fun handleFailure(e: CreateCredentialException) {
    val msg = when (e) {
        is CreateCredentialCancellationException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "The operation was canceled by the user."
        }
        is CreateCredentialInterruptedException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Passkey setup was interrupted. Please try again."
        }
        is CreateCredentialProviderConfigurationException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Credential provider misconfigured. Contact support."
        }
        is CreateCredentialUnknownException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "An unknown error occurred during Passkey setup."
        }
        is CreatePublicKeyCredentialDomException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Passkey creation failed: ${e.domError}"
        }
        else -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "An unexpected error occurred. Please try again."
        }
    }
}

Testing passkeys in intranet environments

Zoho faced an initial challenge in testing passkeys within a closed intranet environment. The Google Password Manager verification process for passkeys requires public domain access to validate the relying party (RP) domain. However, Zoho’s internal testing environment lacked this public Internet access, causing the verification process to fail and hindering successful passkey authentication testing. To overcome this, Zoho created a publicly accessible test environment, which included hosting a temporary server with an asset link file and domain validation.

This example from the assetlinks.json file used in Zoho’s public test environment demonstrates how to associate the relying party domain with the specified Android app for passkey validation.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.zoho.accounts.oneauth",
            "sha256_cert_fingerprints": [
                "SHA_HEX_VALUE" 
            ]
        }
    }
]

Integrate with an existing FIDO server

Android’s passkey system utilizes the modern FIDO2 WebAuthn standard. This standard requires requests in a specific JSON format, which helps maintain consistency between native applications and web platforms. To enable Android passkey support, Zoho did minor compatibility and structural changes to correctly generate and process requests that adhere to the required FIDO2 JSON structure.

This server update involved several specific technical adjustments:

1. Encoding conversion: The server converts the Base64 URL encoding (commonly used in WebAuthn for fields like credential IDs) to standard Base64 encoding before it stores the relevant data. The snippet below shows how a rawId might be encoded to standard Base64:

// Convert rawId bytes to a standard Base64 encoded string for storage
val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())

2. Transport list format: To ensure consistent data processing, the server logic handles lists of transport mechanisms (such as USB, NFC, and Bluetooth, which specify how the authenticator communicated) as JSON arrays.

3. Client data alignment: The Zoho team adjusted how the server encodes and decodes the clientDataJson field. This ensures the data structure aligns precisely with the expectations of Zoho’s existing internal APIs. The example below illustrates part of the conversion logic applied to client data before the server processes it:

private fun convertForServer(type: String): String {
    val clientDataBytes = BaseEncoding.base64().decode(type)
    val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
    val clientJson = JSONObject()
    val challengeFromJson = clientDataJson.getString("challenge")
    // 'challenge' is a technical identifier/token, not localizable text.
    clientJson.put("challenge", BaseEncoding.base64Url()
        .encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8))) 

    clientJson.put("origin", clientDataJson.getString("origin"))
    clientJson.put("type", clientDataJson.getString("type"))
    clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
    return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}

User guidance and authentication preferences

A central part of Zoho’s passkey strategy involved encouraging user adoption while providing flexibility to align with different organizational requirements. This was achieved through careful UI design and policy controls.

Zoho recognized that organizations have varying security needs. To accommodate this, Zoho implemented:

• Admin enforcement: Through the Zoho Directory admin panel, administrators can designate passkeys as the mandatory, default authentication method for their entire organization. When this policy is enabled, employees are required to set up a passkey upon their next login and use it going forward.
• User choice: If an organization does not enforce a specific policy, individual users maintain control. They can choose their preferred authentication method during login, selecting from passkeys or other configured options via their authentication settings.

To make adopting passkeys appealing and straightforward for end-users, Zoho implemented:

• Easy setup: Zoho integrated passkey setup directly into the Zoho OneAuth mobile app (available for both Android and iOS). Users can conveniently configure their passkeys within the app at any time, smoothing the transition.
• Consistent access: Passkey support was implemented across key user touchpoints, ensuring users can register and authenticate using passkeys via:
• The Zoho OneAuth mobile app (Android & iOS);
• Their Zoho web accounts page.

This method ensured that the process of setting up and using passkeys was accessible and integrated into the platforms they already use, regardless of whether it was mandated by an admin or chosen by the user. You can learn more about how to create smooth user flows for passkey authentication by exploring our comprehensive passkeys user experience guide.

Impact on developer velocity and integration efficiency

Credential Manager, as a unified API, also helped improve developer productivity compared to older sign-in flows. It reduced the complexity of handling multiple authentication methods and APIs separately, leading to faster integration, from months to weeks, and fewer implementation errors. This collectively streamlined the sign-in process and improved overall reliability.

By implementing passkeys with Credential Manager, Zoho achieved significant, measurable improvements across the board:

• Dramatic speed improvements
• 2x faster login compared to traditional password authentication.
• 4x faster login compared to username or mobile number with email or SMS OTP authentication.
• 6x faster login compared to username, password, and SMS or authenticator OTP authentication.
• Reduced support costs
• Reduced password-related support requests, especially for forgotten passwords.
• Lower costs associated with SMS-based 2FA, as existing users can onboard directly with passkeys.
• Strong user adoption & enhanced security:
• Passkey sign-ins doubled in just 4 months, showing high user acceptance.
• Users migrating to passkeys are fully protected from common phishing and password breach threats.
• With 31% MoM adoption growth, more users are benefiting daily from enhanced security against vulnerabilities like phishing and SIM swaps.

Recommendations and best practices

To successfully implement passkeys on Android, developers should consider the following best practices:

• Leverage Android’s Credential Manager API:
• Credential Manager simplifies credential retrieval, reducing developer effort and ensuring a unified authentication experience.
• Handles passwords, passkeys, and federated login flows in a single interface.
• Ensure data encoding consistency while migrating from other FIDO authentication solutions:
• Make sure you handle consistent formatting for all inputs/outputs while migrating from other FIDO authentication solutions such as FIDO security keys.
• Optimize error handling and logging:
  • Implement robust error handling for a seamless user experience.
  • Provide localized error messages and use detailed logs to debug and resolve unexpected failures.
• Educate users on passkey recovery options:
• Prevent lockout scenarios by proactively guiding users on recovery options.
• Monitor adoption metrics and user feedback:
  • Track user engagement, passkey adoption rates, and login success rates to keep optimizing user experience.
  • Conduct A/B testing on different authentication flows to improve conversion and retention.

Passkeys, combined with the Android Credential Manager API, offer a powerful, unified authentication solution that enhances security while simplifying user experience. Passkeys significantly reduce phishing risks, credential theft, and unauthorized access. We encourage developers to try out the experience in their app and bring the most secure authentication to their users.

Get started with passkeys and Credential Manager

Get hands on with passkeys and Credential Manager on Android using our public sample code.

If you have any questions or issues, you can share with us through the Android Credentials issues tracker.