This scenario is very similar to scenario 2(a) in the sense that Haventec Silent MFA SDK and APIs do not change; however, the client will not receive any magic link to verify.
In this case, the customer backend triggers the verify Silent MFA API automatically so that the end users do not have to click the magic link. Theoretically, there will not be any session timeout as well because the customer backend immediately triggers the verify API well within the validity of the session timeout removing the human factor of the process.
The above flow goes as follow.
-
The end user logs in as usual to the customer frontend.
-
The customer frontend calls the SDK login service with 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 Haventec 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 customer backend receives Haventec Authenticate userId, activation token and sessionId for that particular user.
-
The customer backend needs to securely store the received activation token and session id.
-
User details such as Haventec Authenticate userId and sesssionId need to be sent back to the SDK as well.
-
The SDK will store these details in the user’s session storage.
-
Then the customer backend directly calls PATCH /mfa/verify Verify MFA User API of Haventec Authenticate with relevant sessionId, activation token, applicationId and apiKey.
-
The verification is successful and the customer backend receives a 200 response.
-
In other scenarios, the SDK automatically polls the POST /check endpoint of the customer backend with relevant userId and sessionId; the recommended time is 5 seconds.
-
The customer backend in turn calls PATCH /mfa/user/device/activate Activate MFA User
-
Haventec Authenticate API with relevant sessionId, activationToken, apiKey and applicationId.
-
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.
-
The customer backend returns the authKey and deviceId to the SDK.
-
The SDK stores the received credentials in the user’s local storage.
-
The customer front-end is notified of the successful storage of the credentials.
-
The user has been successfully logged in.
*applicationId and apiKey are available after the customer application is registered with Haventec Authenticate via Haventec Console.
Comments
0 comments
Please sign in to leave a comment.