When the user lose existing 2FA, the SeaCat Auth should provide an emergency procedure for how to login.
That could be implemented by (1) sending emergency code to the email; or to (2) pre-create ones for a later use (to be stored on the secure place).
The secondary use case is when a user wants to introduce a new device (with FIDO2/WebAuthn 2FA) but without the access to the already set private key. ("Authentication failed, can't identify used authenticator" situation).
The user can use emergency code to login from the new device and then introduce it as another authenticator.
Bit length of the emergency code should be large (>256bits) and the longevity very short.
Possible extension is to limit (via scope/authorization) the "emergency" session for SeaCat Auth WebUI only.
When the user lose existing 2FA, the SeaCat Auth should provide an emergency procedure for how to login. That could be implemented by (1) sending emergency code to the email; or to (2) pre-create ones for a later use (to be stored on the secure place).
The secondary use case is when a user wants to introduce a new device (with FIDO2/WebAuthn 2FA) but without the access to the already set private key. ("Authentication failed, can't identify used authenticator" situation). The user can use emergency code to login from the new device and then introduce it as another authenticator.
Bit length of the emergency code should be large (>256bits) and the longevity very short.
Possible extension is to limit (via scope/authorization) the "emergency" session for SeaCat Auth WebUI only.