If you’ve already integrated the pre-built UI you might want to start exploring passkeys by enabling them as an additional authentication method alongside your existing methods. With this approach, users will be able to create and use their passkeys within the pre-built UI.

Using passkeys within Authsignal's pre-built UI

This approach is great when optimizing for speed of integration - the only prerequisite is that you need to set up a custom domain. However, if you want to integrate passkeys directly into an existing login page or a native mobile app, then using Authsignal Client SDKs is likely the better option.

​
Setting up a custom domain

If you’re using Authsignal’s pre-built UI with passkeys, you’ll need to set up a custom domain. This means that your users’ passkeys will be bound to your own domain rather than mfa.authsignal.com.

​
Defining the relying party

Once you have set up your custom domain, you can then enable Passkey as an authenticator option in the Authsignal Portal. This step requires defining your Relying Party ID, which determines the domains where your users’ passkeys are valid. If you have already set up a custom domain, the Relying Party ID value will default to your top-level domain. For example, if your custom domain is auth.example.com then your Relying Party will default to example.com. Setting the Relying Party as your top-level domain is a good future-proof approach - it means that your users passkeys will be valid for Authsignal’s pre-built UI running on your custom domain (e.g. auth.example.com) as well as on your top-level domain (e.g. example.com) and any other subdomains.
If you modify your Relying Party ID you may invalidate your existing users’ passkeys. You should only edit your Relying Party ID before releasing passkey functionality to production, or when testing with a separate Authsignal tenant associated with a non-production environment.

​
Adding expected origins

Expected origins determine where a valid passkey authentication request may come from. These should include the URL scheme e.g. https:// and a port if applicable e.g. :3000. For example, if your users can sign in with their passkey at https://auth.example.com and reauthenticate on both https://example.com and https://challenge.example.com, then you would need to whitelist all three origins.

Configuring expected origins in the Authsignal Portal

​
Uplifting users to passkeys

To encourage your users to start using passkeys, we recommend using the pre-built UI’s built in passkey uplift prompt.
Passkey uplift prompt

Passkey uplift prompt

​
Next steps