Durante muitos anos, a proteção dos sistemas corporativos esteve baseada principalmente em usuário e senha. Esse modelo, entretanto, apresenta uma limitação importante: a senha deixou de ser suficiente para proteger uma identidade digital. Credenciais podem ser obtidas por phishing, vazamentos de bases de dados, malware, reutilização de senhas ou ataques de força bruta — e, uma vez em poder de um atacante, uma aplicação que dependa exclusivamente desses dois elementos pode permitir o acesso indevido.
É nesse contexto que surge a MFA — Multi-Factor Authentication, ou autenticação multifator. Em vez de perguntar apenas "qual é sua senha?", o sistema passa a verificar também algo que o usuário possui ou algo que o identifica. Segundo a definição utilizada pela Microsoft em sua documentação de identidade, os fatores normalmente se enquadram em três categorias: algo que você sabe (uma senha), algo que você tem (um telefone ou chave de segurança) e algo que você é (uma característica biométrica).
Para uma organização, o grande desafio não é apenas adotar MFA, mas fazê-lo de maneira centralizada, administrável e compatível com os sistemas existentes. É nesse cenário que o Keycloak desempenha um papel importante.
01O que é MFA, na prática
A autenticação multifator exige dois ou mais elementos de autenticação independentes para confirmar a identidade do usuário. Alguns exemplos comuns:
- Senha + código temporário — o usuário informa a senha e, depois, um código gerado por um aplicativo autenticador.
- Senha + chave de segurança — além da senha, uma chave compatível com FIDO2/WebAuthn.
- Passkey + biometria ou PIN — abordagem sem senha, em que o dispositivo usa uma credencial criptográfica protegida localmente, desbloqueada por biometria ou PIN.
O conceito fundamental por trás de qualquer combinação é o mesmo: comprometer um único fator não deve ser suficiente para obter acesso.
02MFA não é exatamente a mesma coisa que 2FA
Os termos aparecem como sinônimos, mas existe uma diferença conceitual. 2FA — Two-Factor Authentication significa autenticação usando exatamente dois fatores. MFA — Multi-Factor Authentication é um conceito mais abrangente: utilização de múltiplos fatores de autenticação. Senha + TOTP é, ao mesmo tempo, 2FA e MFA; uma solução que combine senha + TOTP + WebAuthn está utilizando múltiplos fatores e é tratada como MFA. No ambiente corporativo, o termo MFA é preferido porque permite trabalhar com diferentes métodos e políticas de autenticação.
03Por que isso importa: o impacto de uma senha comprometida
Mesmo com uma política de segurança que bloqueie senhas fracas, ainda existe a possibilidade de uma credencial legítima ser vazada, reutilizada, capturada por phishing, obtida por malware ou exposta em outro serviço. Com MFA ativada, o atacante pode conseguir a senha e ainda assim encontrar uma segunda barreira: "agora prove que você também possui o dispositivo ou credencial adicional." A própria Microsoft relata, em pesquisa sobre suas contas, que a MFA pode bloquear mais de 99,2% dos ataques de comprometimento — número que deve ser interpretado no contexto da Microsoft, e não como garantia universal, mas que ilustra a importância que grandes provedores atribuem ao segundo fator.
04O problema de implementar MFA aplicação por aplicação
Uma organização com dez sistemas pode tentar implementar MFA separadamente em cada um: ERP, sistema acadêmico, Moodle, portal do colaborador, sistema financeiro, GED. O resultado costuma ser seis ou dez implementações diferentes, cada uma tratando cadastro do segundo fator, recuperação, troca de dispositivo, políticas, sessões, códigos, telas, auditoria e suporte ao usuário — separadamente. Além do retrabalho, a experiência do usuário fica fragmentada, podendo chegar ao cenário absurdo em que a mesma pessoa tem métodos de MFA diferentes para sistemas diferentes.
05O papel do Keycloak
O Keycloak resolve esse problema atuando como Identity Provider (IdP). Em vez de cada aplicação implementar sua própria autenticação, as aplicações delegam essa responsabilidade ao Keycloak:
Usuário → Aplicação → Keycloak → Autenticação + MFA → Aplicação
│
┌─────────────┼─────────────┐
TOTP WebAuthn Passkey
Dessa forma, a aplicação não precisa conhecer a complexidade do mecanismo de MFA — ela simplesmente confia no resultado da autenticação do Keycloak.
06Mecanismos de MFA nativos do Keycloak
A documentação oficial do Keycloak apresenta suporte nativo a diferentes mecanismos de autenticação multifator, incluindo OTP, WebAuthn e códigos de recuperação, o que permite construir políticas diferentes para diferentes grupos de usuários:
| Grupo | Política sugerida |
|---|---|
| Usuários comuns | Senha + TOTP |
| Administradores | Senha + WebAuthn |
| Usuários de sistemas críticos | WebAuthn obrigatório |
| Acesso emergencial | Código de recuperação |
TOTP: uma maneira simples de começar
No modelo TOTP — Time-based One-Time Password, o usuário registra seu autenticador uma única vez, e o aplicativo passa a gerar códigos temporários a cada login (usuário + senha → código TOTP → acesso). O Keycloak permite configurar OTP como parte do fluxo de autenticação, definindo parâmetros como intervalo de tempo, algoritmo, quantidade de dígitos e janela de tolerância para sincronização do relógio. A vantagem: nenhuma aplicação precisa implementar seu próprio gerador ou validador de códigos.
WebAuthn e passkeys
O Keycloak também suporta WebAuthn, padrão usado por tecnologias modernas de autenticação, incluindo passkeys — seja como segundo fator (Senha + WebAuthn) ou como mecanismo passwordless (WebAuthn Passwordless), usando chaves de segurança, notebooks, smartphones ou biometria suportada pelo dispositivo. Uma estratégia de longo prazo comum é começar com senha + TOTP e, depois, migrar determinados grupos para passkeys/WebAuthn, sem precisar mudar a arquitetura geral de identidade.
Códigos de recuperação
Um problema prático de qualquer solução MFA é "e se o usuário perder o telefone?". O Keycloak possui suporte a Recovery Codes — códigos de recuperação gerados individualmente, que funcionam como mecanismo alternativo de segundo fator quando o autenticador principal estiver indisponível (telefone perdido, app removido, troca de aparelho). Naturalmente, esses códigos devem ser tratados como credenciais sensíveis.
07MFA condicional e step-up authentication
Outro recurso importante é a possibilidade de construir Authentication Flows, que definem como uma autenticação deve acontecer: começar com usuário e senha, verificar se existe credencial de segundo fator, solicitar OTP ou WebAuthn, oferecer métodos alternativos, ou negar o acesso caso nenhum segundo fator esteja configurado. Isso permite condições baseadas em função/role do usuário e políticas diferentes por grupo — colaboradores com senha + TOTP, TI com senha + WebAuthn, administradores com WebAuthn obrigatório.
Um conceito relacionado é o step-up authentication: o usuário já está autenticado no portal corporativo com um nível normal de acesso, mas, ao entrar em uma área sensível (como o módulo financeiro), a aplicação pode exigir um nível adicional de autenticação. O Keycloak conta com mecanismos de níveis de autenticação e fluxos condicionais — incluindo configurações de Level of Authentication (LoA) — para esse tipo de cenário. O princípio por trás disso: nem todo acesso precisa ser tratado com o mesmo nível de segurança.
08O maior benefício: MFA centralizada
Sem Keycloak Com Keycloak Aplicação A → MFA A Usuário → Keycloak ─┬─ Aplicação A Aplicação B → MFA B ├─ Aplicação B Aplicação C → MFA C ├─ Aplicação C Aplicação D → MFA D └─ Aplicação D
O MFA fica concentrado na camada de identidade, o que permite à organização criar uma política corporativa única — toda aplicação integrada ao Keycloak deve utilizar MFA conforme sua classificação de risco — muito mais fácil de administrar do que implementar MFA individualmente em cada produto.
Isso é especialmente valioso para empresas com sistemas próprios: em vez de desenvolver TOTP, WebAuthn, QR Code, recuperação, cadastro de dispositivo, validação, expiração e controle de sessões dentro de cada aplicação, o time de desenvolvimento delega essa responsabilidade ao Keycloak via OpenID Connect/OAuth 2.0, e passa a receber apenas a identidade autenticada e as informações necessárias para autorização. A separação fica mais clara: Keycloak → autenticação; aplicação → autorização e regras de negócio.
09O desafio operacional continua existindo
É importante não transformar o Keycloak em solução milagrosa. Centralizar MFA aumenta a segurança e simplifica o desenvolvimento, mas também aumenta a importância da infraestrutura: se o Keycloak ficar indisponível, várias aplicações podem deixar de autenticar usuários. Por isso, uma implantação corporativa precisa considerar disponibilidade, backup, monitoramento, segurança e recuperação de desastre — e arquiteturas de alta disponibilidade com múltiplas instâncias, conforme a própria documentação de produção do Keycloak recomenda. O princípio é simples: quanto mais sistemas dependem do Keycloak, mais crítico ele se torna.
O que a comunidade técnica comenta
Em discussões sobre soluções de identidade e 2FA self-hosted, administradores costumam reconhecer o Keycloak como uma solução de SSO e MFA bastante completa, mas também mais pesada e complexa do que ferramentas dedicadas exclusivamente a MFA. O padrão que se repete: o Keycloak compensa quando existe necessidade real de SSO para várias aplicações; para proteger poucos serviços isolados, uma alternativa mais leve pode ser suficiente. Não faz muito sentido implantar Keycloak apenas para colocar um código de seis dígitos em uma única aplicação — o valor aparece quando ele se torna a plataforma central de identidade da organização.
10Estratégia recomendada, por etapas
| Etapa | Ação |
|---|---|
| 1 — Centralizar identidade | Integrar as aplicações ao Keycloak via OpenID Connect ou SAML. |
| 2 — Implantar TOTP | Começar com usuário + senha + TOTP para os usuários em geral. |
| 3 — Proteger administradores | Exigir WebAuthn ou passkeys para admins, infraestrutura e contas privilegiadas. |
| 4 — Classificar aplicações | Baixo risco: MFA recomendado. Médio: MFA obrigatório. Alto: WebAuthn/passkey. |
| 5 — Evoluir para passwordless | Migrar grupos maduros para WebAuthn/passkeys, à medida que a organização evolui. |
Esse processo é muito mais realista do que tentar implementar a estratégia completa de uma só vez.
11MFA faz parte de uma estratégia maior de segurança
É importante lembrar que MFA não substitui as demais medidas de segurança. Uma arquitetura madura ainda precisa de gestão de privilégios, políticas de senha, proteção contra phishing, revisão de acessos, logs, monitoramento, gestão de dispositivos, atualização de sistemas, backup e resposta a incidentes. Também vale reforçar a distinção: MFA responde "quem é você?"; autorização responde "o que você pode fazer?" — o Keycloak pode ajudar nas duas camadas, mas são problemas diferentes.
12Conclusão
A autenticação multifator é hoje uma das principais ferramentas para reduzir o risco associado ao comprometimento de credenciais. Mas o verdadeiro ganho organizacional não está simplesmente em obrigar os usuários a informar um código adicional — está em centralizar a identidade e transformar a MFA em uma política corporativa reutilizável por todos os sistemas.
É nesse ponto que o Keycloak se torna particularmente interessante: ele permite centralizar identidade, SSO, MFA, políticas de autenticação, WebAuthn, passkeys e recuperação de acesso em uma única plataforma. Para uma organização com diversos sistemas próprios, Moodle, portais, aplicações Web, APIs ou sistemas de diferentes fornecedores, isso pode representar uma redução significativa na complexidade do desenvolvimento e da administração de segurança — aplicações não precisam implementar sua própria segurança de identidade; elas podem confiar em uma plataforma central.
Implantação de MFA com apoio local
Desenhar Authentication Flows, políticas por grupo e step-up authentication exige experiência prática com o Keycloak. A Solis, mantenedora deste site, apoia empresas na implantação de MFA centralizada — do TOTP básico ao WebAuthn/passkeys para contas críticas. Fale com nossos especialistas →
Fontes consultadas
- Microsoft Learn: documentação de identidade sobre categorias de fatores de autenticação e pesquisa sobre eficácia da MFA no bloqueio de ataques de comprometimento de contas.
- Keycloak: documentação oficial sobre OTP, WebAuthn, códigos de recuperação, Authentication Flows, condições baseadas em role, Level of Authentication (LoA) e recomendações de alta disponibilidade para produção.
- Comunidade técnica: padrões recorrentes de relatos sobre soluções self-hosted de 2FA/SSO, usados como leitura de sentimento da comunidade, não como citação literal ou substituto de documentação técnica.