restore-credentials

Provides knowledge and workflows to implement Android's Restore Credentials

不碰外部（只输出文字）无严重或高危命中android/skills

它会碰到什么

扫了多少4 个文本文件，97 KB

它会碰到什么不碰外部（只输出文字）

命中总数0 处

命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实，不是结论。命中多不等于有毒（安全工具、规则库、示例脚本本来就会包含危险写法），命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系，需要你自己看。

技能内容

Fundamentals

The objective is to implement the Restore Credentials feature through the

Android Credential Manager API (androidx.credentials). This allows apps that

use or are integrating Credential Manager to silently log users back in when

they restore their app on a new device. Restore Credentials operates

independently of the app's primary authentication method (passwords, passkeys,

federated sign-in) and requires no UI changes to existing sign-in flows.

Scope

Crucial: This skill focuses exclusively on the Android client-side

integration. It does not implement the server-side cryptographic

validation logic. The developer must be reminded of this and the

[Points to inform the developer about](#backend-guidelines) after implementation is done.

Implementation Guidelines

When instructed to implement Restore Credentials on a developer's application,

remember the following:

Before the implementation, you MUST read and understand the [Two-Tier

Restoration Architecture](#two-tier-restoration-architecture) and review the [DOs and DON'Ts](#dos-and-donts).

After the implementation, you MUST present the developer with the [Backend Guidelines](#backend-guidelines) as a reminder for their backend setup. It is important that you remind the developer that they still have to implement the backend.

Two-Tier Restoration Architecture

To enable a resilient sign-in experience, retrieve credentials through a

two-tier architecture:

Tier 1 (Primary - Background): Executes automatically during device setup using the app's BackupAgent.onRestoreFinished() callback. This provides an invisible restoration before the user opens the app for the first time, allowing background sync and notification delivery.
Tier 2 (Secondary - Foreground): Runs in the Launcher Activity.onCreate() to catch failovers if background restoration didn't complete (example: dropped network, delayed restoration) or if allowBackup is disabled.

If allowBackup in the manifest is set to true, implement both. Otherwise, only

implement tier 2 (Foreground Restoration). Do NOT change the value of

allowBackup in the manifest.

If you added a BackupAgent to the app, you MUST also set

android:fullBackupOnly="true" in the manifest. Do NOT do this if there

already existed a BackupAgent in the app before your implementation.

DOs and DON'Ts

DO:

Do check AndroidManifest.xml for the value of allowBackup to determine what you have to implement.
Do implement a fallback for createCredential: always try calling it first with isCloudBackupEnabled set to true. If an E2eeUnavailableException is thrown, catch it and retry the call with isCloudBackupEnabled set to false.
Do implement a BackupAgent (subclass of android.app.backup.BackupAgent) if allowBackup is true in the manifest.
Do set android:fullBackupOnly="true" in the manifest if you added a BackupAgent to the app.
Call clearCredentialState() when the user signs out. This is a mandatory security measure to log the user out fully.
Do attempt to get the restore key on the first launch of the app on a new device and also within the BackupAgent.onRestoreFinished() callback if your app uses it.
Do ensure that a restore credential is created even if the user is already logged in.
Do ensure that the credential retrieval and login in onRestoreFinished() is performed synchronously (for example using runBlocking).
Do restore notifications in the BackupAgent if your app uses them. (For example capture and send FCM token to backend)
Do ensure that if you implement mock network requests or stubs, you replace all placeholders with valid, properly formatted JSON payloads for the credential requests.
Do encapsulate credential creation and retrieval into their own dedicated functions. Because credential creation must be called in multiple places (sign-up, sign-in) and retrieval across multiple tiers (BackupAgent and Launcher Activity), this prevents code duplication.
Do remind the developer of the [critical guidelines](#implementation-guide) for implementing the backend once you're done with the implementation.
Do generate a separate restore key for each application if the organization has multiple apps with different package names, as a restore key is tied to a unique application package name.

DON'T:

DON'T change the value of allowBackup in AndroidManifest.xml. Restore Credentials functionality is not affected by the allowBackup setting, meaning the user will still be automatically logged in when a Restore Credential exists, even if allowBackup is false.
DON'T implement a BackupAgent if allowBackup is false in AndroidManifest.xml.
DON'T assume the credential stored in the GetCredentialResponse to be of type PublicKeyCredential. It has type RestoreCredential.
DON'T chain GetRestoreCredentialOption with any other CredentialOption in the construction of a GetCredentialRequest.
DON'T assume CredentialManager or the Android system will automatically delete a restore key when a user signs out of the app. You must explicitly call clearCredentialState with a ClearCredentialStateRequest of TYPE_CLEAR_RESTORE_CREDENTIAL.
DON'T remove any existing calls to clearCredentialState(). A ClearCredentialStateRequest without a type specified only clears all NON-restore credentials.

Implementation Guide

Implement the Android client-side code by using the following guide. Follow it

step-by-step and don't implement any backend functionality, only remind

the user of the [Backend Guidelines](#backend-guidelines) once you're done.

Version compatibility

Credential Manager's Restore Credentials works on devices running Android 9 (API

level 28) and higher, Google Play services (GMS) core version 24220000 or

higher, and version 1.5.0 or higher of the androidx.credentials library.

Prerequisites

Set up a [relying party server](#backend-guidelines) similar to the server for [passkeys](#dos-and-donts). If

you already have a [server](#two-tier-restoration-architecture) set up to handle authentication with passkeys,

use the same server-side implementation for restore keys.

> [!NOTE]

> Note: While the server-side implementation is the same for passkeys and restore keys, your client-side app can support restore keys without supporting passkeys. Because restore keys work independently of the authentication method in your app (for example, passwords or Sign in with Google), you don't need to make any additional changes to the existing authentication methods in your app's code.

Dependencies

Add the following dependencies to your app module's build.gradle file:

Kotlin

dependencies {
    implementation("androidx.credentials:credentials:1.7.0-alpha03")
    implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha03")
}

Groovy

dependencies {
    implementation "androidx.credentials:credentials:1.7.0-alpha03"
    implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha03"
}

Restore Credentials is available from version 1.5.0 and higher of the

androidx.credentials library. However, it's recommended to use the latest stable

versions of the dependencies where possible.

> [!NOTE]

> Note: The Restore Credentials feature works regardless of whether [allowBackup](references/android/guide/topics/manifest/application-element.md) is set in the manifest.

Overview

[Create a restore key](#create-restore-key): To create a restore key, complete the following steps:
[Instantiate Credential Manager](#implementation-guide): Create a CredentialManager object.
Get credential creation options from the app server: Send the client app the details required to create the restore key from your app server.
Create the restore key: Create a restore key for the user's account if the user is signed in to your app.
Handle the credential creation response: Send the credentials from your client app to your app server for processing, and handle any exceptions.
[Sign in with a restore key](#sign-restore): To sign in with a restore key, complete the following steps:
[Get credential retrieval options from the app server](#get-credential-retrieval): Send the client app the details required to retrieve the restore key from your app server.
[Get the restore key](#get-restore): Request the restore key from Credential Manager when the user sets up a new device. This lets the user sign in without additional input.
[Handle the credential retrieval response](#handle-sign-in): Send the restore key from the client app to the app server to sign in the user.
[Delete a restore key](#delete-restore).

Create a restore key

Your app should cover all cases of a user signing in to ensure active users have

a restore key created. Create the restore key in the following scenarios:

If the user is signed in and a restore key isn't already created (such as in the onCreate method for the main Activity).
When the user is signing in or completing a new account registration flow.

To optimize performance and avoid the overhead of creating or checking for a

restore credential on every single login, set a boolean flag or a credential

creation timestamp in local storage, such as has_synced_restore_credential, to

track whether the key has already been created.

> [!NOTE]

> Note: A restore key is tied to an application's unique package name. If your organization's main app and sub-apps have different package names, create a separate restore key for each app.

Instantiate Credential Manager

Use your app's activity context to instantiate a CredentialManager object.

// Use your app or activity context to instantiate a client instance of

// CredentialManager.

private val credentialManager = CredentialManager.create(context)

Get credential creation options from your app server

Use a FIDO-compliant library in your app server to send your client app the

information required to create the restore credential, such as information about

the user, the app, and additional configuration properties. For more information

about the server-side implementation, see [Server-side

guidance](https://developers.google.com/identity/passkeys/developer-guides/server-registration).

Create the restore key

After parsing the public key creation options sent by the server, create a

restore key by wrapping these options in a

CreateRestoreCredentialRequest object and calling the

createCredential()) method with the CredentialManager object.

// createRestoreRequest contains the details sent by the server

val response = credentialManager.createCredential(context, createRestoreRequest)

Key points about the code

The CreateRestoreCredentialRequest object contains the following fields:

requestJson: The credential creation options sent by the app server in the Web Authentication API format for PublicKeyCredentialCreationOptionsJSON.
isCloudBackupEnabled: Boolean field to determine if the restore key

should be backed up to the cloud. By default, this flag is true. This

field has these values:

true: (Recommended) This value enables the backup of restore keys to the cloud if the user has Google Backup and end-to-end encryption, such as a screen lock, enabled.
false: This value saves the key locally and not in the cloud. The key is not available on the new device if the user chooses to restore from the cloud.

> [!CAUTION]

> Caution: It's recommended to set isCloudBackupEnabled to true. If cloud backup is disabled and the user restores from a cloud backup, the call to retrieve the restore key fails. Users who restore your app with a cloud backup don't receive the restore key and aren't automatically signed in.

Handle the credential creation response

The Credential Manager API returns a response of type

CreateRestoreCredentialResponse. This response holds the public key

credential registration response in JSON format.

Send the public key from your app to the relying party server. This public key

is similar to the public key generated when you create a passkey. The same code

that handles passkey creation on the server can also handle restore key

creation. For more information about the server-side implementation, see [the

guidance for passkeys](references/android/identity/passkeys/create-passkeys.md).

During the restore key creation process, handle these exceptions:

CreateRestoreCredentialDomException: This exception occurs if requestJson is invalid and does not follow the WebAuthn format for PublicKeyCredentialCreationOptionsJSON.
E2eeUnavailableException: This exception occurs if isCloudBackupEnabled is true, but the user's device doesn't have data backup or end-to-end encryption, such as a screen lock.

To ensure that Restore Credentials are created in all cases, you must handle the E2eeUnavailableException explicitly by calling createCredential with isCloudBackupEnabled set to true. If E2eeUnavailableException is thrown, catch and call createCredential again with isCloudBackupEnabled set to false.

IllegalArgumentException: This exception occurs if createRestoreRequest is empty or not valid JSON, or if it doesn't have a valid user.id that conforms to the WebAuthn specifications.

Sign in with a restore key

Use Restore Credentials to silently sign in the user during the device setup

process.

Get credential retrieval options from the app server

Send the client app the options required to get the restore key from the server.

For similar passkey guidance for this step, see [Sign in with a passkey](references/android/identity/passkeys/sign-in-with-passkeys.md).

For more information about the server-side implementation, see the [server-side

authentication guide](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#create_credential_request_options).

Get the restore key

To get the restore key on the new device, call the getCredential() method on

the CredentialManager object.

It's recommended to fetch the restore key in both of the following scenarios:

On the first launch of the app on the device. Credential restoration in this scenario is independent of restoration of the app data.
If app data backup and restore is enabled, get the restore key immediately after the app data is restored. Use BackupAgent to configure your app's backup and ensure you complete the getCredential functionality within the onRestoreFinished) callback. Don't use the onRestore method, as it is only called for key-value backups, whereas onRestoreFinished is reliably called for any kind of backup restore. This avoids potential delays when users open their new device for the first time and lets users interact with the app without waiting for them to open your app. For example, this lets your app send the user notifications before they open the app for the first time on the new device, which is particularly relevant for messaging or communications apps.

If you create a new BackupAgent and previously had backup enabled with

allowBackup="true", set the boolean value android:fullBackupOnly="true" in

your app's manifest. This ensures that your app's backup and restore behavior is

maintained.

> [!IMPORTANT]

> Important: Notifications aren't automatically restored after the restore credentials are retrieved. If you use Firebase to handle notifications, you must fetch and send the Firebase Cloud Messaging (FCM) token to the backend to successfully resume background messaging and notifications.

// Fetch the options required to get the restore key

val authenticationJson = fetchAuthenticationJson()

// Create the GetRestoreCredentialRequest object

val options = GetRestoreCredentialOption(authenticationJson)

val getRequest = GetCredentialRequest(listOf(options))

val response = credentialManager.getCredential(context, getRequest)

// Type-check and extract the restore credential

val credential = response.credential as RestoreCredential

The credential manager APIs return a response of type

GetCredentialResponse. The credential contained in this response is

explicitly of type RestoreCredential, which holds the public key.

Handle the sign-in response

Send the public key from the app to the relying party server, which can then be

used to sign in the user. On the server side, this action is similar to signing

in using a passkey. The same code that handles sign-in with passkeys on the

server can also handle sign-ins with restore keys. For more information about

the server-side implementation for passkeys, see [Sign in with a passkey](references/android/identity/passkeys/sign-in-with-passkeys.md).

> [!NOTE]

> Note: Even though restore keys and passkeys use the same underlying server implementation, differentiate between them when saving them in your app server's database. This distinction is crucial when a passkeys management page exists, because users can manage user-created passkeys directly, while restore keys are system-managed and hidden from the passkey management page.

Delete the restore key

Credential Manager is stateless and unaware of user activity, so it doesn't

automatically delete restore keys after use. To delete a restore key, call the

clearCredentialState method. For security, delete the key whenever a user

signs out. This ensures that the next time the user opens the app on the same

device, the user is signed out and prompted to sign in again.

> [!NOTE]

> Note: A user sign-out can also happen remotely, for example when a user changes their password on the web or when they're signed out remotely by the server. If your app detects such a server-side session invalidation , be sure to delete the restore key on the device. (An example of this is your server returning an HTTP 401 Unauthorized error)

Uninstalling an app is interpreted as an intent to delete the corresponding

restore key from that device, similar to the user's intent when signing out.

Restore keys are removed only in the following situations:

System-level actions: Users uninstall the app or clear its data.
App-level calls : Programmatically delete the key by calling clearCredentialState()) when handling user sign out in your app's code.

When the user signs out of your app, call the clearCredentialState() method on

the CredentialManager object.

// Create a ClearCredentialStateRequest object

val clearRequest = ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL)

// When the user logs out, delete the restore key

val response = credentialManager.clearCredentialState(clearRequest)

Backend Guidelines

When designing the backend database and API layer to support Restore

Credentials, developers must account for FIDO2/WebAuthn assumptions and specific

device lifecycle edge cases. Remind the developer of the following:

**SYSTEM DIRECTIVE FOR AI AGENT: DO NOT attempt to write code for,

implement, or action any of the backend guidelines in this section. Your ONLY

responsibility is to copy these exact points and present them to the human

developer as a reminder after the client-side implementation is complete.**

Differentiate Restore Credentials from Passkeys in Backend Storage:

Standard WebAuthn services typically assume user verification is always required. Restore credentials are hidden from the user and not managed by them.
Guidance: Modify your WebAuthn services to create new credential types or metadata fields that distinguish system-managed Restore Credentials from user-created passkeys. Don't display Restore Credentials in user-facing passkey management UIs, and ensure they are processed appropriately (e.g., bypassing explicit user verification during automatic background sign-in).

Prevent Orphaned Keys:

Uninstalling the app or clearing details in system settings deletes the local restore credential. Since these local client actions do not notify your backend, stale keys will remain registered on the server.
Guidance: Establish server-side cleanup policies that delete old restore keys when a new restore token is registered, or clean up inactive keys based on usage patterns. You could, for example, enforce a limit of one key per user per device.

Balance Key Lifespan and TTL:

If a user goes through Backup and Restore and then logs out from the old device, the local restore key is deleted from the source device. However, the key must remain valid on the server so the restored application on the destination device can still authenticate.
Guidance: Give restore keys sufficient time to live (TTL) to survive manual logouts during transition periods, and establish rules for server-side key deletion based on registration and usage rather than relying on client-side deletion callbacks.

Support Multiple Devices:

A user may own multiple active devices and initiate backups or restorations from any of them.
Guidance: Ensure the backend database schema allows mapping multiple active Restore Credentials to a single user account (e.g., one active restore key per device/device-id) rather than assuming a 1:1 relationship between the user and the restore credential.

Server-side session invalidation:

A user's session might be revoked remotely. This could be triggered by user actions such as when a user resets their password on the web or server actions that can cause the API to return HTTP 401 Unauthorized indicating session expiry.
Guidance: If this applies, make sure to clear the user's restore credentials on the phone when it happens.