In this scenario, the user is new to both the customer system and Haventec Authenticate. Therefore, they start to register with the customer system and end with an integrated authentication service powered by both the customer system and Haventec Authenticate Silent MFA.
The end user registers with the customer, and the customer system calls Authenticate Silent MFA registration in the background. When the registration with Silent MFA is successful, the end user will receive an email from Customer Backend containing a magic link constructed out of the activation token issued by Silent MFA in the registration process.
After going through all the steps below, the end user is deemed logged in with the Silent MFA part of the process and their local storage will have fresh credentials to carry out another log in. The credentials for Silent MFA are changed every time the user logs in and subsequently improve the process's security. The customer needs to integrate this with their own registration and login process so that the two systems work in parallel.
The above flow goes as follows.
Sign up - the end user signs up at the client website.
Signup details (eg. username, password) - the customer frontend calls Silent MFA SDK to register with Authenticate providing a username and password.
POST /Register (Signup Details) - the SDK will call relevant facade APIs in the customer backend which in turn calls Haventec Authenticate APIs. In this case, the call is for registration with a username.
PATCH /mfa/user Create MFA User. The customer backend calls the register MFA user endpoint of Authenticate via the URI provided by Haventec passing in the application id and API key* as the already registered customer application identity and the username for the new user.
As a result of the registration API call, the customer backend will receive the Haventec Authenticate userId, activation token and session id for the new user.
The customer backend needs to store the above activation token and session id.
The customer backend needs to create a magic link from the activation token generated by Authenticate and evaluate the email or mobile number corresponding to the username passed by the end user and send the magic link to the end user.
The customer backend needs to send Authenticate userId and sessionId received from Authenticate to the Silent MFA SDK.
The SDK will store these parameters 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; the recommended time is 5 seconds.
11. The check API of the customer backend calls PATCH /mfa/user/device/activate Activate MFA User. API of Authenticate every time the polling call is executed in step 10.
12. During the time the user has not clicked the magic link, the client backend will receive 422 Response which means the user 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 request on clicking the magic 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 User 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.
22. PATCH /mfa/user/device/activate Activate MFA User 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.