Authenticator binding

An important consideration when supporting multiple different authentication methods is how to ensure that each method has been added securely.

We consider a new authenticator as having a strong binding to an existing authenticator if the act of enrolling the new authenticator is authorized by the existing authenticator.

​

Using the pre-built UI

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).

​

Using client SDKs

To ensure a strong binding between authenticators, Authsignal client SDKs for web and native mobile apps 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

Alternatively, you can track an action using a Server SDK or the Server API 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 scope add:authenticators when generating the token.

Then pass the token from your backend to the client SDK. You can pass the token directly to the relevant method when creating a passkey or adding a push credential or else you can use the setToken method.