Best practices

This page contains useful information about best practices and considerations for anyone involved in implementing ReuseID, for example developers, project managers and technical architects.

The scope is for select topics that can assist you during your integration, such as key decisions, tips and ways to avoid common issues.

MobileID authentication

If you have chosen MobileID as an authentication method for ReuseID, then you can read the sections below to ensure that you have a smooth and successful integration.

Choose an authentication protocol

An early decision that you need to make is which authentication protocol to use for MobileID authentication:

Authentication protocol	Description
ReuseID REST API	The ReuseID REST API is Signicat's native, proprietary solution. You need to use this API to conduct most supported operations, regardless of which authentication protocol you choose. This includes operations such as: Creating ReuseID users Registering MobileID devices Conducting management operations This means that if you use this API for authentication, then it is the only API you need to support. Note: To learn more, see the ReuseID API reference documentation.
OIDC Authorization Code Flow	The OpenID Connect (OIDC) authentication protocol with Authorization Code Flow allows you to integrate with MobileID as an eID method in the Signicat eID and Wallet Hub. This is an an alternative to integrating with Signicat's ReuseID REST API. The OIDC Authorization Code Flow is primarily designed for web applications and is not well suited for native mobile apps. In this flow, the client redirects the end-user to the authorisation server for authentication. Note: To learn more, see the MobileID Authorization Code Flow integration documentation.
OIDC CIBA Flow	The OpenID Connect (OIDC) authentication protocol with CIBA flow allows you to integrate with MobileID as an eID method in the Signicat eID and Wallet Hub. This is an an alternative to integrating with Signicat's ReuseID REST API. The OIDC CIBA flow (Client-Initiated Backchannel Authentication) is an extension to the OIDC protocol and is well-suited for headless applications that need to make backchannel authentication requests, such as with a mobile app. This flow may be useful if for example you use a third-party access management software that integrates with and uses OIDC standards. Note: To learn more, see the MobileID CIBA Flow integration documentation.

Check for outstanding transactions

In an omni-channel environment, transactions can be initiated from several different channels and not only from the the native mobile app.

When your app initiates an authentication, it cancels any ongoing transactions that were started from other channels. To avoid this, you must implement a check for outstanding transactions by using a startAuth SDK call before your app starts an authentication itself.

Avoid excess devices for a user

In certain situations, the amount of devices registered to an end-user may be unnecessarily large. For example, this can happen if an end-user deletes and registers your app repeatedly. In these cases, you may reach the user device limit of 30 devices per end-user.

If an end-user has more than 30 devices registered to them, then it could indicate suspicious behaviour such as malicious usage of your services. As a security measure:

1. When an end-user attempts to register a device that exceeds the user device limit, we notify you by returning the error message exceeding_user_device_limit.
2. Next, you can then investigate the situation further and if required, delete the previously registered devices using the Delete device operation.

Signicat automatically deletes devices that have not been used in the last 365 days, whereas you must manually delete other devices.

Our recommendation

You may find it useful to implement functionality where your end-users can manage their own devices logged into your website and delete their unused devices.

Activation code length

The default activation code length is 10. To ensure that you maintain good security, we do not recommend that you reduce this length for production accounts.

If the end-user registers within your app and does not need to enter the activation code manually, then we recommend that you use a long activation code.

Choose events (callback) or polling

Events are our way of letting you know when something happens in one of our services. When an asynchronous operation completes, or when ReuseID gets a notification that a device has changed state, ReuseID publishes an event with the operation result.

You can use the Signicat events service to subscribe to events, so that you automatically receive the result at your specified notification URI. This is often referred to as callback.

You can also get the operation result back through polling. The result that you receive through the Signicat events service is the same as the result obtained by polling, but wrapped in a Signicat event object.

For production, we always recommend that you use the Signicat events service instead of polling. This offers the best usability and responsiveness, as it has the least amount of latency. It also means that that you do not need to conduct additional polling calls.

Want to learn more?

• For information generic to all Signicat events, see the general Events documentation.
• For information specific to ReuseID, see the ReuseID Events documentation.

Segments

When conducting certain operations on the User resource, it is possible to pass an optional parameter called segment in the request. The following operations support this parameter:

• Create user
• Update user

As the segment is then returned in the response of a respective transaction, it allows you to group the end-users and corresponding transactions based on a segmentation of your choice.

For example, if your app is used by end-users across multiple countries, you could use segments to get statistics for app usage per country, In this example, you could segment your end-users using country codes such as NO, SE, DK.

Resolve an external reference

When a user is created with the Create user operation, we generate a valid UUID to identify it called a userId. This is required for carrying out most operations such as registration and authentication.

You may already have your own internal customer references that you store and use for your customers. In the context of this product, we refer to it as an external reference.

If you do not want to store the Signicat-generated userId, then you can use the Resolve external reference operation to supply the associated externalRef and fetch the userId.

Once fetched, the userId can then be can then be used to start the subsequent operation as normal.