Passkeys Settings
Customize your WebAuthn authentication from the Descope console (Settings > Authentication Methods > Passkeys).
Enable Method in API and SDK
The Enable method in API and SDK toggle controls whether passkeys authentication can be invoked programmatically via APIs and SDKs.
- When enabled: Authentication works via flows, APIs, and SDKs
- When disabled: Authentication only works with flows or calls made with a valid management key
Available Settings
This section describes additional details about the configuration options available.
Display Name
The Display Name is the human-readable name shown to users when they create or use a passkey. By default, it uses your project name. You can set it to any text you want—for example, your product or company name.
Note
Whether users see the display name depends on their password manager. Some, such as Bitwarden, show it; others only show the top-level domain.
Top Level Domain
The configured domain defines where end users can set up biometric authentication. The top-level Biometrics (WebAuthn) domain restricts where users are allowed to authenticate, applying to both the domain itself and all its subdomains. By default, Descope automatically derives this top-level domain from the request origin.
Changing the top-level domain for Biometrics (WebAuthn) in the Descope UI can invalidate existing users if the new domain no longer matches the one they originally registered with. Users who rely solely on WebAuthn will be unable to log in and must be deleted and recreated. Users with other verified authentication methods can still sign in through those methods, though registering with WebAuthn again may create a new credential.
Android Fingerprints
When a passkey operation runs inside an Android app, the app reports its origin as an APK key hash (android:apk-key-hash:...) rather than your web origin. Use Android Fingerprints to declare which Android apps can complete passkey operations in your project.
Add the SHA-256 fingerprints of the Android keystores used to sign your Android APK, in colon-separated hex format. Each fingerprint is 32 pairs of hex digits separated by colons.
Note
Find the Android keystore file used to sign your Android app and run this command: keytool -list -v -keystore my_keystore.jks
What the list contains changes how Descope treats Android origins:
- Empty (default): Descope uses the origin recorded when the passkey operation started and checks no fingerprints.
- One or more fingerprints: Descope accepts passkey sign-up, sign-in, and add-device operations from Android apps signed with a listed key. An app that reports an APK key hash with no matching fingerprint gets error
E067020. Clients that report a web origin, including browsers and apps that open the flow in a system browser or Custom Tab, are unaffected.
Important
The list covers every Android app in your project, not only the app you added it for. Include each signing key you use, such as your release key, your debug key, and, if you use Play App Signing, the app signing key Google generates rather than your upload key. Miss one and that build can no longer use passkeys.
If your Android app hosts a Descope flow in its own WebView, see Passkeys with Mobile SDKs for how this setting applies.