Using the pre-built UI
Requiring a challenge with an existing method
When using the pre-built UI, strong binding between authenticators is handled automatically. This is because the pre-built UI requires the user to complete a challenge with an existing authentication method in order to add a new method within a limited time window (10 minutes by default).
Completing an email OTP challenge to authorize adding a passkey
Skipping the prerequisite challenge
It is possible to skip this prerequisite challenge step when launching the pre-built UI if you have already strongly authenticated the user outside of Authsignal. This can be achieved by passing additional scopes when tracking an action on your server to generate a short-lived pre-built UI URL.Using Client SDKs
To ensure a strong binding between authenticators, our Web SDK and Mobile SDK support two different ways of adding new authentication methods.Presenting a challenge with an existing method
Similar to the pre-built UI, with this option you can present a challenge with an existing method (e.g. passkey) in order to enroll a user in a new method (e.g. authenticator app) within a limited time window (10 minutes by default).Tracking an action to generate a token
You can track an action using a Server SDK to generate a time-limited token (valid for 10 minutes by default). This token can be used to authorize adding the new authenticator. If this is not the user’s first authenticator, you must specify the scopeadd:authenticators when generating the token.
You should only ever generate a token with the add:authenticators scope from a context where the user
is strongly authenticated.
The example below demonstrates how a user ID is obtained from an authenticated request context and passed into the track request when using AWS Lambda and API Gateway.
setToken method.

