MFA para os usuários do seu app
O SuperDB oferece TOTP (Google Authenticator, 1Password, Authy) pronto no SDK. Você decide quem precisa ativar — a regra de negócio é sua.
// 1) gera o segredo e o QR para o usuário escanear
const { data } = await db.auth.mfa.enroll({ factorType: 'totp', label: 'Meu App' })
// data traz factor_id, secret e uri (otpauth://): renderize a uri como QR code
// 2) confirme com o código de 6 dígitos que o app mostrou
await db.auth.mfa.verify({ factorType: 'totp', code: '123456' })
// 3) consulte os fatores ativos do usuário logado
const { data: f } = await db.auth.mfa.factors()Para exigir o código numa ação sensível, a conferência precisa acontecer no servidor que executa a ação, não só na tela. O passo a passo, com a carência para fatores recém-cadastrados, está no cookbook de MFA TOTP.
Exigir MFA por role (ainda não é self-serve)
Forçar MFA no nível da plataforma para determinadas roles não é configurável pelo dashboard nem por API hoje. O padrão em vigor é: MFA opcional, bloqueio de força bruta após 10 tentativas por 15 minutos. Se o seu contrato exige enforcement por role, fale com o suporte — é habilitado caso a caso.
Enquanto isso, o enforcement fica no seu app: ao detectar que o usuário tem uma role sensível e não tem fator ativo, redirecione para a tela de cadastro de MFA antes de liberar a área restrita.
MFA na sua conta SuperDB
É outra coisa: protege o seu login no app.superdb.com.br (quem administra os projetos), não os usuários do seu app. Configure no menu da sua conta.
Troubleshooting
Usuário perdeu o dispositivo e não tem recovery codes
Como o login ainda não pede o segundo fator, o próprio usuário entra com a senha, remove o fator antigo e cadastra o novo celular (passo 4 do cookbook de MFA TOTP). Não há rota para remover o fator de outra pessoa com a service key.
Código sempre inválido
TOTP depende de relógio: confira se a hora do celular está no automático. Uma diferença maior que 30 segundos já invalida os códigos.