Passkeys and the Authsignal pre-built UI

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.

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 authsignal.com. Configuring a custom domain can be done in the Authsignal Portal.

For example, if your app is running on the domain example.com then you could configure the Authsignal pre-built UI on the subdomain auth.example.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 the Authsignal 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.

​

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.

​

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.

​

Next steps

• Using passkeys with your own custom or native UI
• Passkeys and local development