\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEieK5NxefEs0wwVBn6fxvkV9nHNxMkU1536dzGGFiIgl5NkaZh5H6yADhtcSG-ZGi8Nu8xpr51qLpoip7wYGgDXobv1j_CMhtURHTrhhh7h3BHDNYh9bOtBW4DhnbizuCnsbIFQPJ9997yRA4ahN9-wHvHe8HUKMDd9puNT_E7vWcNbqkRfalZhXhFgF2s\/s1600\/credential-manager-wear-os%20%282%29.png\")
<\/p>\nPosted by John Zoeller \u2013 Developer Relations Engineer<\/em><\/p>\n This post is part of Wear OS Spotlight Week<\/a>. Today, we’re focusing on implementing Credential Manager on Wear OS<\/b>, aiming to streamline the authentication experience.<\/i><\/p><\/blockquote>\n For all software developers, crafting a fast and secure authentication flow is paramount, and this is equally important on Wear OS.<\/p>\n The traditional Wear OS methods require users to have their phone nearby to complete authentication, often with a separate mobile flow or 2-factor auth code.<\/p>\n Credential Manager<\/a>‘s arrival simplifies this process, allowing for authentication directly from a user’s watch with no need for a nearby phone.<\/p>\n As a unified API, Credential Manager enables you to reuse your mobile app\u2019s code on Wear OS, streamlining development across form factors. With a single tap, users can authenticate with passwords, federated identities like Sign in with Google, or passkeys<\/a><\/b>, the new industry standard for security.<\/p>\n Passkeys are built on the principle of asymmetric encryption. During creation, a system authenticator generates a unique, mathematically linked pair of keys: a public key that is securely stored online with the service, and a private key that remains exclusively on the user’s device.<\/p>\n When signing in, the device uses the private key to cryptographically prove to the service that it possesses the key.<\/p>\n This process is highly secure because the private key never leaves the device during authorization (only during syncs from credential providers) and can only be used with the user’s explicit permission. This makes passkeys resistant to server breaches, as a breach could only ever expose the public half of the key pair. Additionally, since there is no passphrase to steal, passkeys are virtually phishing-proof.<\/p>\n The user experience of passkeys is seamless: to log in, a user confirms their presence with their device’s lock (e.g., biometric credential or PIN), and they are signed in. This eliminates the need to remember complex passphrases and provides a faster, more secure method of authentication that works seamlessly across devices.<\/p>\n Credential Manager should be the base of a Wear app\u2019s authentication flow. Developers should decide which of its built-in methods to implement based on what is implemented in their mobile experiences, and based on the variety of authentication methods their users need.<\/p>\n Passkeys are the preferred built-in solution due to their inherent security and simplicity, but the other built-in options Credential Manager provides can also be implemented. Passwords are valuable because of their familiarity to users, and federated identities like Sign in with Google provide users with the comfort of a trusted provider.<\/p>\n Developers should maintain at least one of their existing authentication options as a backup as they transition their users to Credential Manager. If Credential Manager is dismissed by a user, or if all of its methods fail, or if credentials are not available, developers can present their backup options.<\/p>\n The Wear Authentication developer guide<\/a> includes details on supported Wear OS backup authentication options. These include solutions like OAuth 2.0, which has traditionally been a popular choice on Wear OS; and data layer token sharing, which can be used to automatically authenticate users at app launch time if their phone is nearby to sync a signed in account.<\/p>\n Read the full Wear sign-in design guidance<\/a> to learn about all the best practices for designing your authentication flow, including our special guidance around data layer token sharing.<\/p>\n At its core, Credential Manager consolidates multiple authentication methods into a single, unified API call: getCredential<\/a><\/span>. By configuring a GetCredentialRequest<\/a><\/span> with your authentication options, you can use the response to validate a user’s identity with your app’s server that contains the credentials, like so:<\/p>\n <\/p>\n For a truly seamless experience, a user’s credentials must sync effortlessly from their other devices to their watch, since it is currently not possible to create credentials on Wear OS.<\/p>\n To enable this, you must add an entry for Wear OS in your Digital Asset Links<\/a><\/b> to associate your Wear OS app with other versions of your app. Be sure to precisely fill out the asset link entry, including your app’s applicationId<\/span> and the SHA-256 cryptographic hash from your application\u2019s digital signature. You can test them out with our app link verification guide<\/a>.<\/p>\n To allow users to sign in with Credential Manager, provide getCredential<\/span> with options for the three built-in authentication types: passkeys, passwords, and federated identities like Sign in With Google.<\/p>\n <\/p>\n When getCredential<\/span> is called, Credential Manager will use the options developers provide to present users with a UI to choose how they want to log in.<\/p>\n After a user selects their desired credential in the Credential Manager UI, use the result of getCredential<\/span> (which contains the selected credential) to route to your authentication handlers.<\/p>\n <\/p>\n The handling logic for each of the above loginWith\u2019x\u2019<\/span> methods is slightly different, although they all set up network calls to dedicated authentication endpoints. Below are simplified versions of these methods which demonstrate network calls to authenticate users based on their selected method.<\/p>\n Passkeys<\/b> require the signed passkey JSON data. Your server will use this data to cryptographically verify the user.<\/p>\n <\/p>\n Passwords<\/b> require network logic to validate the username and password, our example uses subsequent calls to validate the username first. Your backend will validate these against its user database.<\/p>\n <\/p>\n![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEhixN5tFhfrjYWSjcqKvsvrWf-zTFdROS_piAYDWzHHJccNn9zsqNsZbVfSKXVA-LUo4SlE7Cl0NZeR4hls3bzvkK8GDeO0kISiAsjSaGahaAZ9NUMA0vj8kacuSxAxgeqLzszBUcZije6vposhRkREnhmjoxe8GiBfEH9Rt-8H8BnSttUOT21Xw1popRQ\/s1600\/credential-manager-wear-os%20%281%29.png\")
<\/a><\/p>\n<\/div>\nThe power of passkeys<\/span><\/h2>\n
<\/div>\nDesigning authentication with Credential Manager<\/span><\/h2>\n
<\/div>\n<\/div>\nImplementing Credential Manager on Wear OS<\/span><\/h2>\n
Basic GetCredential setup<\/span><\/h3>\n
Sync Credentials with Digital Asset Links<\/span><\/h3>\n
Furnishing getCredential<\/span> with built-in credentials<\/span><\/h3>\n
<\/div>\nHandling built-in Credential types<\/span><\/h3>\n