Enter your primary domain. This value should correspond to the web domain associated with your mobile app. For more information refer to our Mobile SDK documentation. Click Continue.
If targeting Android, then go to your Expected origins settings, click Add Android app origin and enter your app’s SHA-256 fingerprint value. For more information on how to obtain this value refer to our Mobile SDK documentation.
This token includes the add:authenticators scope to authorize binding a passkey to an existing user so you should only generate it when the user is strongly authenticated.
You can also use our SDK to help determine when to display a passkey creation prompt based on whether or not the user has an existing passkey available on their device.
let showPrompt = await authsignal.passkey.shouldPromptToCreatePasskey()if showPrompt { let response = await authsignal.passkey.signUp( token: "eyJhbGciOiJIUzI....", username: "jane.smith@authsignal.com", ignorePasskeyAlreadyExistsError: true, )}
You can define another action to let users authenticate with their passkeys.
This action will be used for observability and to authenticate the user on the server.
let response = await authsignal.passkey.signIn(action: "signInWithPasskey")if let token = response.data?.token { // Send token to your backend for validation}
Because some users may not have a passkey available, you can conditionally present a fallback authentication method by handling error codes returned by the SDK.
This server-side validation step can be used within one of our popular IdP integrations or with our session APIs to issue access tokens and refresh tokens.
Due to security restrictions in the design of passkeys, iOS and Android don’t expose an API to query if a passkey is available on a device.This means we need to handle the UX around passkey availability carefully both when creating and authenticating with passkeys.
Prompting users to create a passkey proactively is a great way of increasing adoption.
The Mobile SDKs include a helper method to determine whether prompting the user to create a passkey is recommended.
let showPrompt = await authsignal.passkey.shouldPromptToCreatePasskey()
This method will return true if the following conditions are met:
A passkey has not been created on the current device.
A passkey has not been used on the current device after it was created on another device.
A passkey has been removed in the Authsignal Portal after it was created or used on the current device.
The method will also return true as a “false positive” in the following edge case:
A passkey is available which was created on another device and has not yet been used on the current device.
This case can be handled by ignoring any errors thrown because a valid passkey already exists.
let response = await authsignal.passkey.signUp( token: "eyJhbGciOiJIUzI....", username: "jane.smith@authsignal.com", ignorePasskeyAlreadyExistsError: true,)if !response.error { // Alert the user that the passkey was successfully created}
Since we can’t query up front whether a passkey is available or not, the recommended pattern is to attempt passkey sign-in for all users and then provide a fallback option by handling error codes.
iOS imposes an additional privacy restriction which prevents apps from determining if the user canceled the passkey flow or if they didn’t have a passkey available.
For this reason we recommend presenting an alternative authentication method in both cases.To learn more about handling error codes refer to the Mobile SDK documentation.
Passkeys are supported on iOS devices running iOS 15 or higher and on Android devices running Android 9 (API level 28) or higher.You can use the SDK to perform this check.
let isSupported = await authsignal.passkey.isSupported()