The scenario: you on-boarded your MFA user, and they're logging in again. Once they've passed your traditional password challenge, you want to present the MFA challenge.
Your challenge begins server-side - now the relationship key has been established, it should never be displayed client-side. From your server, you ask Anubis to raise a challenge. This is presented here as a cURL request, as the authorization header is vital:
curl https://anubis.zehuti.com/mfa/auth/relationship-key
--header "Authorization: Bearer secret-key"
--request GET You'll receive a response in JSON:
{"id":"challenge-key"} On your web page, you'll need to call the Anubis library again, which will display a dialog to the user, with instructions on one-time passwords, and a QR code link to the authenticator:
anubis.wait(challenge-key, success, fail); As with on-boarding, the success and fail parameters are obvious; when the challenge has been successfully met, your success function will be called with the challenge ID.
You can't trust anything on the client - it's important that you validate the response from your server as a response to the success function being called:
https://anubis.zehuti.com/mfa/check/challenge-key At which point you'll receive a JSON object back:
{"cha":"challenge-key","status":"status"} There are three potential statuses:
| pending | the user hasn't responded to the challenge |
| approved | the challenge has been approved by the user |
| declined | the user actively declined the challenge |
And that's all there is to it - when you see that 'approved' status, you know your user has successfully met the MFA challenge!