Configuration
Enabling passkeys
You can enable passkeys for your tenant in the Authsignal Portal by going to Settings -> Authenticators.
The Relying Party
The Relying Party ID determines the web domain for which passkeys are valid.
If your web application is hosted on https://example.com then you could set example.com as your Relying Party ID.
Choosing a Relying Party ID
If you want to allow passkeys to be valid across multiple subdomains, then you should set the top level domain as the Relying Party ID.
For example, if users should be able to register a passkey on https://auth.example.com and reauthenticate with the same passkey on https://shop.example.com, then you would need to set the Relying Party ID to example.com.
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.
Modifying a Relying Party ID
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.
Custom domains
If you're using Authsignal's pre-built UI to manage passkeys, you will need to configure a custom domain. In this case your Relying Party ID should match your custom domain.
If you're implementing passkey functionality using Authsignal's client SDKs, you don't need to configure a custom domain.
Local development
There are two possible scenarios for local development:
- Your web app is running locally but your Relying Party ID is public, e.g.
example.com. This will be the case if you're using Authsignal's pre-built UI (either via redirect or popup) or if using an authorization server which is not run locally. - Your web app is running locally and your Relying Party ID is
localhost. This may be the case if you're using Authsignal's client SDKs.
In the first scenario, you don't need to create a separate tenant for local development; you can use the same tenant that your deployed app is using.
In the second scenario, you should create a separate Authsignal tenant which can be used exclusively for local development and testing.
Make sure that you include the scheme e.g. http and port e.g. 3000 in the expected origin.