User Flow - 3. Logging in with an existing Silent MFA user without a registered Silent MFA device

This scenario is where the user is already registered with both the customer system and Authenticate Silent MFA. However, the user may be using a new device to log in to use the customer's application services. In this case, Silent MFA device registration has to be processed first.

This scenario occurs every time a currently registered user utilises a new device. The user might have registered themselves with their laptop for example. Then, they want to log in to the customer application with their phone. In this case, they do not need to register again; however, the new device they use for the first time needs to be registered.

Once a particular device has been registered for that user, the rest of the logins on that device is seamless.

The above flow goes as follow.

1. The end user logs in as usual to the customer frontend. 

2. The customer frontend calls the SDK login service with username and password.

3. Silent MFA SDK calls POST /login facade API of the customer backend which in turn calls Haventec Authenticate POST /mfa/device Create MFA Device API with relevant userName, applicationId and apiKey*.

4. The customer backend calls POST /mfa/device Haventec Authenticate API with relevant userName, userId, applicationId and apiKey.

5. The device registration is successful and the customer backend receives Haventec Authenticate deviceId, activation token and session id.

6. The customer backend securely saves the activation token and session id received from Haventec Authenticate.

7. The customer backend sends an email to the user with the magic link constructed out of the activation token from Haventec Authenticate.

8. The customer backend sends the device details back to the SDK.

9. The SDK stores the devices details in the user’s session storage.
   
   

Before the end user clicks the magic link from their email, the followings happen.

     10. The SDK calls the check API of the customer backend according to the intervals configured in the SDK.

     11. The check API of the customer backend calls PATCH /mfa/user/device/activate Activate MFA Device. API of Haventec Authenticate every time the polling call is executed in step 10.

     12. During the time the user has not clicked the magic link, the customer backend will receive 422 response which means the client has not been verified. 

     13. The customer backend relays the result to the SDK.

     14. If the time has passed for the session expiration (which normally is within one hour of the registration call), the session time-out response is returned from SDK to the customer frontend.

     15. And the current flow ends in the user registration fail.

However, if the user clicks the magic link in their email within the session validity, the followings happen.

    16. The end user clicks the magic link.

    17. The link is a POST to the customer backend with Haventec Authenticate generated activation token. 

    18. As a result of step 17, the customer backend triggers Haventec Authenticate PATCH /mfa/verify Verify MFA Device.

with relevant userId, sessionId, activation token, apiKey and applicationId.

   19. The verification PATCH to Haventec Authenticate was successful.

   20. The success was returned 

   21. POST /check has been running by the SDK with the interval as configured in the SDK; the recommended time is 5 seconds.

  22. PATCH /mfa/user/device/activate Activate MFA Device has in turn been called according to the interval specified in the SDK.

  23. As the verification has been successful prior to this, the PATCH /mfa/user/device/activate call with relevant userId, sessionId, activation link, apiKey and applicationId is successful and Haventec Authenticate issues an authKey.

  24. The customer backend returns the authKey and deviceId to the SDK.

  25. The SDK stores the received credentials in the user’s local storage.

  26. The customer front-end is notified of the successful storage of the credentials.

  27. The user has been successfully logged in.

**applicationId and apiKey are available after the customer application is registered with Haventec Authenticate via Haventec Console.