In this case, the user is already registered with the customer system. It is assumed that they have already been logging in with the customer system. The following flow should be followed as the customer would like their current users to onboard with Haventec Silent MFA.
The user will log in as usual to the customer system. With the help of Silent MFA SDK, Haventec Silent MFA APIs and the integration code in the customer system, the current users of the customer will experience the added security of Silent MFA without any friction.
As the customer system knows that the user is their current user, it first tries registering the user’s device with Silent MFA. There will be 400 response and the customer system needs to register the user with Silent MFA. Whether to register the user first or register the device directly depends on if the customer backend knows if the user is already registered with Silent MFA. It is totally up to the customer system.
The rest of the flow is very similar to the previous scenario.
The above flow goes as follows.
The end user logs in as usual to the customer frontend.
The customer front end calls the SDK login service with a username and password.
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*.
The call to Haventec Authenticate from customer backend with relevant parameters.
As the user is not yet registered with Authenticate Silent MFA, 400 no user account found response is received.
If so, the PUT /mfa/user Create MFA User. Haventec Authenticate API is called with relevant userName, applicationId and apiKey.
As a result of successful user registration, the client backend receives Haventec Authenticate userId, activation token and sessionId for that particular user.
The customer backend needs to store the received activation token and session id securely.
The customer backend also needs to create a magic link out of the activation token received from the successful user registration and send it to the user’s email.
User details such as Haventec Authenticate userId and sessionId need to be sent back to the SDK as well.
The SDK will store these details in the user’s session storage.
Before the end user clicks the magic link from their email, the followings happen.
12. The SDK calls the check API of the customer backend according to the intervals configured in the SDK.
13. The check API of the customer backend calls PATCH /mfa/user/device/activate Activate MFA User. API of Haventec Authenticate every time the polling call is executed in step 12.
14. 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.
15. The customer backend relays the result to the SDK.
16. 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.
17. 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.
18. The end user clicks the magic link.
19. The link is a POST to the customer backend with Haventec Authenticate generated activation token.
20. As a result of step 19, the customer backend triggers Haventec Authenticate PATCH /mfa/verify Verify MFA Use, with relevant userId, sessionId, activation token, apiKey and applicationId.
21. The verification PATCH to Haventec Authenticate was successful.
22. The success was returned.
23. POST /check has been running by the SDK with the interval as configured in the SDK; the recommended time is 5 seconds.
24. PATCH /mfa/user/device/activate Activate MFA User has in turn been called according to the interval specified in the SDK.
25. 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.
26. The customer backend returns the authKey and deviceId to the SDK.
27. The SDK stores the received credentials in the user’s local storage.
28. The customer front-end is notified of the successful storage of the credentials.
29. The user has been successfully logged in.
*applicationId and apiKey are available after the customer application is registered with Haventec Authenticate via Haventec Console.