Start setting up an authenticator
Generate a secret. This does **not** switch the factor on. Nothing is protected until `/mfa/activate` has seen a code derived from this secret. That order is deliberate: a QR code can be mis-scanned or scanned into nothing, and switching on a factor the member's app cannot actually produce locks them out of their own account.
Generate a secret. This does not switch the factor on.
Nothing is protected until /mfa/activate has seen a code derived from
this secret. That order is deliberate: a QR code can be mis-scanned or
scanned into nothing, and switching on a factor the member's app cannot
actually produce locks them out of their own account.
Authorization
OAuth2PasswordBearer In: header
Cookie Parameters
Response Body
application/json
application/json
curl -X POST "https://example.com/api/b/v1/mfa/enrol"{ "secret": "string", "provisioning_uri": "string"}Remove your authenticator DELETE
Turn the factor off, on proof. A code is required because a hijacked session that can silently remove the second factor has already removed it. A recovery code is accepted here too — someone whose phone is gone still needs a way out, and that is what recovery codes are for.
Confirm the code and switch it on POST
Prove the app works, then turn the factor on. Returns recovery codes. They are shown once and stored hashed, so a member who does not keep them and then loses their phone needs support to intervene — which is why the response is the only place they appear and why the screen showing them has to say so.