Multiple Backend Support

The SDK allows defining FIDO UAF credentials in multiple backends. By default, the SDK will assume that all operations must be executed against the server defined in the Configuration_{java, swift, objc, flutter, react native} object, see the Configuration chapter for details.

If in your application all the accounts in a given device are created in the same backend, only the Blocking Servers section is relevant to you.

Limitations Using Identity Suite

The support of multiple backends has the following constraints that only apply when you are using the Identity Suite as a backend.

In the case of Authentication Cloud, you can ignore this section.

username Uniqueness

The SDK assumes that username is unique across backends. In other words, two identities (or accounts), even if they are created in two different backends, cannot have the same username. The nature of the username depends on how the backend has been configured, it can be for example an email or a login ID.

So, if you want your application to support managing multiple accounts that are defined in different backends, verify that this constraint is fulfilled.

All Backends Have the same HTTP Endpoint Structure

The SDK assumes that all the backends have the same HTTP endpoints. The base URL and relative paths for each endpoint are defined in the Configuration object.

For example, if the base URL in Configuration is https://siven.ch/auth, and a new account is registered in server acme.com, it is assumed that the base URL of the backend is https://acme.com/auth, and that all HTTP endpoints are relative to that base URL.

All Backends Have the same Firebase Cloud Messaging Configuration

If your application uses push notifications, all the backends must have the same Firebase Messaging Configuration. The SDK assumes that the same FCM registration token can be used with all accounts.

Registering in a Different Backend

To register in a backend that is not the one defined in Configuration, there are 3 possibilities, depending on the nature of your backend:

1. In App registration with Identity Suite, you must specify the URL of the server in the Registration.serverUrl _{java, swift, objc, flutter, react native}.

   As mentioned in the constraints above, only the scheme, host and port of the provided URL will be taken into account, because it is assumed that all backends have the same HTTP endpoint structure.

2. Out-of-band Registration, the SDK will figure out what is the backend where the registration must take place based on the RedeemData _{java, swift, objc, flutter, react native} provided by OutOfBandPayload.redeemData() _{java, swift, objc, flutter, react native}.

3. Authentication Cloud In-app Registration, your application selects the backend where registration must be executed when obtaining the enroll response or the appLinkUri from the Authentication Cloud. The SDK will figure out automatically the backend to be used.

Blocking Servers

The SDK does not provide any built-in functionality to limit registration to any backends. It is your application's responsibility to do so, if required.

For Identity Suite and Authentication Cloud in-app registration, your application is the one deciding which is the backend to be used (see previous section).

In the case of out-of-band registration, you can check whether the host of the redemption URL returned by the method RedeemData.redeemUrl() _{java, swift, objc, flutter, react native} corresponds to a known backend.