Migrating to RemAuth

Migrating an existing password-based service to a RemAuth passwordless authentication is a straight forward operation that can be implemented very quickly.

Switching to a passwordless authentication service means opening up new possibilities to improve the security, simplicity and robustness of your service. Nevertheless, succeeding in such an evolution presupposes an approach that takes into account both the human and technical aspects.

Defining service settings

Here are some questions to ask yourself before starting a migration to RemAuth:

  • What are the authentication modes to implement (email, RemAuth Control app, SMS)?
  • Should we introduce biometric verification? Optional? Mandatory?
  • Is passwordless authentication a substitute, an alternative or a complementary factor to a password system?
  • Should on-the-fly registration be enabled or not?
  • Will the service be systematically password-free or will compatibility with the old system be maintained?
  • If the migration is global, should it include session management too?
  • Should we introduce a certification by additional physical source (available from September 2017)?

The answers to these questions will allow you to define your service settings in the Customer Center.

Ensuring a smooth transition

Habits do not change overnight. It is therefore important to maintain, at least temporarily, compatibility with the old system. In general, this can be managed with a simple graphical transition interface.

The SafeNote web app for secure note management is an illustration of this type of transition GUI where legacy users have the choice between a connection with or without password.

Example of a GUI where legacy users can choose their connection mode

In the previous example, depending on the selected connection type, the OK button will trigger the connection with or without a password.

Implementing migration

From the implementation perspective, the SafeNote example shown above is not very different from the detailed demo except that we start from an existing service instead of a blank page. In summary, here are the main steps to consider, regardless of your existing service:

  • Get familiar with the various possible use cases by playing with the simulator.
  • Set up your service in the Customer Center with some particular attention to the integration parameters related to the presence of users in an existing database and to the the callback URL that will allow your servers to receive notifications.
  • Get a security token either directly with the /access API endpoint, or by implementing the client libraries. In the latter case, you can get help from the basic template.
  • Trigger passwordless authentication using, for example, a button depending on the context of your service. Here again, the easiest way is to use the libraries and rely on the basic example. The benefits of using this library include:
    • This does not require specific user interface development. If necessary, it is always possible to customize the popup GUI by overwriting the data of the remauth.css template with your own one.
    • On-the-fly registration is done simply by using the invite parameter (see example).
    • A callback function can be triggered when authentication succeeds using the authentication data as returned by the /authenticated API endpoint. Please pay attention to the process variable which returns the process applied according to the parameters of the service. The process applied depends on the use case encountered.
  • At this stage, you have then to define the next action required for your system, depending on whether it is a new or existing user (eg profile creation, logon...) .

Questions? Issues? Please do not hesitate to use the Customer Center SUPPORT section.