# Login único (SSO) e 2FA: como proteger os sistemas da empresa

> Login único (SSO) e autenticação em dois fatores na prática: como barram senha vazada, como desligar o acesso de quem saiu num clique e o que exigir do sistema.

Fonte: https://pervian.tech/blog/sso-e-autenticacao-em-dois-fatores · Pervian Tech · publicado em 2026-10-01

A analista do financeiro pediu demissão na sexta-feira. O RH desativou o e-mail dela na segunda, a TI bloqueou o computador na terça, e três semanas depois alguém percebe que o login dela no sistema de gestão, no portal do banco e no painel do e-commerce continua ativo. Ninguém lembrava que ela tinha acesso a esses lugares, e a senha era a mesma em todos.

A cena se repete com variações: a mesma senha usada num site de compras que vazou, a senha num papel colado no monitor, [o fornecedor que ainda entra no portal](https://pervian.tech/blog/portal-do-fornecedor) com o usuário genérico criado "só para aquela semana".

Duas medidas resolvem a maior parte disso: **login único (SSO)**, para que cada pessoa tenha uma identidade só, controlada num lugar só, e **autenticação em dois fatores (2FA)**, para que uma senha vazada não baste para entrar. Este texto explica as duas em linguagem de gestão e mostra o que um sistema, novo ou existente, precisa suportar para adotá-las.

## A resposta curta: o que é SSO, o que é 2FA e por que usar os dois

**Login único (SSO, de *single sign-on*)** significa que o colaborador entra uma vez, com a conta corporativa que a empresa já administra (normalmente Microsoft 365 ou Google Workspace), e os demais sistemas confiam nessa identidade. O sistema de gestão, o portal do colaborador e o painel de BI deixam de guardar senhas próprias e passam a perguntar ao provedor de identidade "quem é essa pessoa e ela ainda está ativa?".

**Autenticação em dois fatores (2FA)** exige, além da senha, uma segunda prova: um código de aplicativo no celular, uma confirmação por notificação ou uma chave de segurança. Quem roubou a senha não tem o segundo fator.

Os dois se completam:

- **SSO concentra o controle.** Uma política de senha, um lugar para ativar o 2FA, um botão para desligar o acesso.
- **2FA protege a porta concentrada.** Se tudo depende de uma conta, essa conta precisa ser difícil de invadir.

SSO sem 2FA cria um ponto único de falha. 2FA sem SSO obriga o usuário a configurar o segundo fator em cada sistema, e a adesão cai. A combinação certa é **SSO com 2FA exigido no provedor de identidade**, e o sistema da empresa recebendo a pessoa já autenticada.

## Senhas fracas e reaproveitadas: a porta de entrada

Boa parte dos acessos indevidos a sistemas empresariais não começa com uma invasão técnica sofisticada. Começa com uma senha válida nas mãos erradas. Os caminhos mais comuns:

- **Reaproveitamento.** O colaborador usa a mesma senha no sistema da empresa e num serviço pessoal. Quando o serviço pessoal vaza, alguém testa a combinação de e-mail e senha em outros lugares.
- **Phishing.** Um e-mail imitando o banco, a contabilidade ou o próprio sistema leva a uma tela de login falsa.
- **Senha compartilhada.** O usuário "estoque" ou "caixa" que cinco pessoas usam. Ninguém sabe quem fez o quê, e ninguém troca a senha quando alguém sai.

Política de senha mais rígida, sozinha, piora o problema: quanto mais complexa e frequente a troca, mais a pessoa anota ou reaproveita. A saída é reduzir o número de senhas que cada pessoa precisa ter e tornar a senha insuficiente para entrar.

Senha compartilhada merece atenção especial, porque ela anula qualquer trilha de auditoria. Se você ainda não tem perfis por função e registro de quem fez cada ação, vale ler antes [como montar perfis de acesso e trilha de auditoria](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria). SSO resolve quem é a pessoa; perfis resolvem o que ela pode fazer.

## Autenticação em dois fatores: opções e usabilidade

Nem todo segundo fator protege igual, e nem todo é igualmente prático. A escolha depende de quem vai usar e de onde.

| Segundo fator | Proteção | Usabilidade | Quando faz sentido |
|---|---|---|---|
| Código por SMS | Baixa a média: vulnerável a troca fraudulenta de chip e a phishing | Alta, não exige instalar nada | Como alternativa de recuperação ou para público externo pouco técnico |
| Código por e-mail | Baixa: se o e-mail cair, o segundo fator cai junto | Alta | Apenas para confirmar ações pontuais, não como 2FA principal |
| Aplicativo autenticador (código de 6 dígitos que muda a cada 30 segundos) | Boa, mas o código ainda pode ser capturado por uma página falsa | Média: instalar o app e cadastrar | Padrão razoável para equipes internas e clientes de portal |
| Notificação no celular com número de confirmação | Boa, desde que mostre o número a digitar e não só "aprovar" | Alta | Equipes que já usam o app do provedor de identidade |
| Chave de segurança física ou passkey | Alta: resiste a phishing porque é vinculada ao endereço do site | Alta depois de configurada | Administradores, financeiro, quem aprova pagamento |

Alguns cuidados de usabilidade decidem se o 2FA vai ser adotado ou contornado:

- **Não peça o segundo fator a cada clique.** Peça no login e em ações sensíveis (alterar dados bancários de fornecedor, aprovar pagamento, exportar base de clientes). Dispositivos já confiáveis podem ficar lembrados por um período definido.
- **Tenha um caminho de recuperação que não seja o ponto fraco.** Se perder o celular faz o suporte desativar o 2FA por telefone sem verificar nada, o atacante liga para o suporte.
- **Cuidado com notificação de "aprovar" sem contexto.** Usuários cansados de alertas aprovam o que aparece. Exigir que digitem o número exibido na tela reduz esse risco.
- **Pense em quem não tem celular corporativo.** Operador de chão de fábrica ou de balcão pode precisar de chave física ou de um posto de trabalho com regra própria.

## Login único com Microsoft ou Google

Na maioria das empresas brasileiras de pequeno e médio porte, o provedor de identidade já existe e está pago: é a conta do Microsoft 365 (cujo diretório hoje se chama Microsoft Entra ID) ou do Google Workspace. O colaborador já entra no e-mail com essa conta, muitas vezes com 2FA ativado. O SSO aproveita esse cadastro em vez de criar outro.

Tecnicamente, o sistema da empresa conversa com o provedor por um protocolo padrão. Os dois que importam:

- **OpenID Connect (OIDC).** Construído sobre o OAuth 2.0, é o padrão mais usado em aplicações web e mobile recentes. O usuário é redirecionado para a tela de login da Microsoft ou do Google e volta ao sistema com um token assinado que diz quem ele é.
- **SAML 2.0.** Mais antigo, baseado em XML, comum em sistemas corporativos e exigido por alguns clientes grandes. Faz o mesmo papel com outro formato.

Para o gestor, a regra prática é: **um sistema novo deve suportar OIDC, e SAML se houver chance de clientes corporativos exigirem**. Quem implementa precisa validar a assinatura do token, conferir o emissor e o público a que ele se destina, e nunca aceitar o e-mail informado pelo usuário como prova de identidade.

Há também uma decisão de autorização: o provedor diz quem a pessoa é, mas quem decide o que ela pode fazer? Duas abordagens comuns:

- **Perfis no próprio sistema**, vinculados ao usuário que chega pelo SSO. Mais flexível para regras de negócio finas.
- **Grupos do diretório** (por exemplo, "Financeiro" ou "Compras" no Entra ID ou no Google) que o sistema traduz em perfis. Mais simples de administrar: mudar a pessoa de grupo muda o acesso em todos os sistemas.

Muitas vezes o melhor é combinar: o grupo define o perfil base, e o sistema guarda exceções e limites (alçada de aprovação, filiais visíveis).

## Desligamento do funcionário em um clique

Esse é o ganho que mais aparece no dia a dia. Sem SSO, desligar alguém exige lembrar de cada sistema em que a pessoa tinha conta. Com SSO, desativar a conta corporativa impede novos logins em todos os sistemas integrados.

Há três detalhes que separam o "em teoria" do "na prática":

1. **Sessões já abertas.** Desativar a conta impede o próximo login, mas uma sessão aberta pode continuar válida até expirar. O sistema precisa ter sessões de duração razoável e, de preferência, consultar o provedor periodicamente ou aceitar um aviso de revogação.
2. **Provisionamento automático.** O padrão SCIM permite que o provedor de identidade crie, altere e desative usuários nos sistemas automaticamente. O suporte a SCIM para aplicações próprias varia de provedor para provedor e de plano para plano, então confirme antes de contar com ele. Sem ele, o usuário é criado no primeiro login, mas a desativação depende de o sistema perceber que a conta sumiu.
3. **Acessos fora do SSO.** Tokens de integração, chaves de API e usuários técnicos criados em nome da pessoa continuam funcionando depois que ela sai. Eles precisam ter dono, validade e inventário. O artigo sobre [erros comuns de segurança em APIs](https://pervian.tech/blog/seguranca-de-apis-erros-comuns) trata de tokens sem expiração e de revogação.

O desligamento ideal vira uma rotina do RH: a data de saída dispara a desativação da conta corporativa, e o resto acompanha. A trilha de auditoria registra quando cada acesso foi encerrado, o que também ajuda a demonstrar o controle sobre quem acessa dados pessoais, parte das medidas de segurança que a LGPD exige de quem trata esses dados.

## Acessos de clientes e parceiros

SSO corporativo resolve a equipe interna. Clientes, fornecedores, representantes e contadores externos não estão no seu diretório, e não devem estar. Ferramentas como Keycloak e Auth0 ajudam aqui, como comparamos em [Keycloak, Auth0 ou login próprio](https://pervian.tech/blog/auth0-keycloak-ou-login-proprio). Para eles, as opções são:

- **Contas próprias do sistema com 2FA**, para portais de cliente e de fornecedor. O cadastro precisa de convite com validade, confirmação de e-mail e, de preferência, aplicativo autenticador como segundo fator.
- **Login com a conta do próprio parceiro.** Quando o cliente é uma empresa que também usa Microsoft ou Google, o sistema pode aceitar o provedor dele (federação). Ele administra quem da equipe dele entra, e você define o que essa empresa pode ver.

Dois cuidados valem para todos os externos: **todo acesso tem prazo** (contrato encerrado, acesso encerrado) e **todo acesso é revisado periodicamente** por alguém interno que responde pela relação.

Para a equipe interna, um bom ponto de partida é concentrar a entrada num lugar só. Um [portal do colaborador ou intranet](https://pervian.tech/blog/portal-do-colaborador-intranet) com SSO vira a porta de acesso a comunicados, documentos e atalhos para os demais sistemas, todos com a mesma identidade.

## O que exigir de um sistema novo

Ao contratar ou [especificar um sistema sob medida](https://pervian.tech/blog/como-descrever-requisitos-de-software), inclua estes itens no escopo. Eles custam pouco no início e muito para adaptar depois.

- [ ] Login por **OpenID Connect** com Microsoft Entra ID e Google Workspace, e **SAML 2.0** se houver clientes corporativos.
- [ ] Possibilidade de **desligar o login por senha local** para usuários internos, deixando só o SSO.
- [ ] **2FA nativo** (aplicativo autenticador, e chave de segurança ou passkey para perfis críticos) para quem não entra por SSO.
- [ ] **Segundo fator em ações sensíveis**, configurável por perfil.
- [ ] **Mapeamento de grupos do diretório para perfis** do sistema.
- [ ] **Provisionamento por SCIM** ou, no mínimo, rotina que desativa usuários ausentes no diretório.
- [ ] **Sessões com expiração** definida e revogação imediata pelo administrador.
- [ ] **Usuários técnicos e tokens de integração** com dono, validade e lista de permissões.
- [ ] **Trilha de auditoria** de logins, falhas, mudanças de perfil e desativações.
- [ ] **Bloqueio após tentativas falhas** e alerta para login de local ou dispositivo incomum.
- [ ] **Nenhum usuário genérico compartilhado**: cada pessoa, um login.

Se o sistema atual não atende a boa parte da lista, isso não obriga a trocá-lo. Muitas vezes dá para colocar uma camada de autenticação na frente dele ou [adaptar o módulo de login, sem mexer no resto](https://pervian.tech/blog/modernizacao-gradual-de-sistemas).

## Implantando sem travar a operação

Ligar SSO e 2FA para todo mundo numa segunda-feira de manhã é a receita para o suporte parar. Um roteiro mais seguro:

1. **Inventário.** Liste os sistemas, quem acessa cada um, como é o login hoje e quais têm usuários genéricos.
2. **Arrume a casa no provedor de identidade.** Contas sem uso desativadas, grupos por função criados, 2FA exigido na conta corporativa.
3. **Comece por um grupo piloto** que usa os sistemas todo dia e tem paciência para reportar problemas, como TI e administrativo.
4. **Rode SSO e senha local em paralelo** por um período curto, com data marcada para desligar a senha local.
5. **Comunique antes**: o que muda, por que, como configurar o aplicativo autenticador e a quem pedir ajuda.
6. **Prepare a recuperação**: o procedimento para quem perdeu o celular, com verificação de identidade.
7. **Elimine os usuários genéricos**, um por um, com login individual para cada pessoa.
8. **Expanda por área** e só então desligue de vez o login por senha local para internos.
9. **Revise acessos periodicamente**, especialmente de externos e de perfis administrativos.

O prazo depende do número de sistemas e de quanto cada um precisa ser adaptado; só o inventário dá uma estimativa honesta.

## Perguntas frequentes

### Pequena empresa precisa de login único e autenticação em dois fatores?

Sim, e costuma ser a que mais ganha, porque raramente tem alguém dedicado a controlar acessos. Se a empresa já usa Microsoft 365 ou Google Workspace, o provedor de identidade já está pago, e o login único aproveita esse cadastro. A autenticação em dois fatores exigida na conta corporativa protege de uma vez todos os sistemas integrados.

### Código por SMS é seguro como segundo fator?

Código por SMS é melhor do que só senha, mas é a opção mais fraca entre os segundos fatores comuns, porque fica vulnerável à troca fraudulenta de chip e a páginas falsas. Para equipes internas, aplicativo autenticador é um padrão razoável. Para administradores e para quem aprova pagamentos, chave de segurança ou passkey protege melhor.

### Qual a diferença entre OpenID Connect e SAML?

Os dois protocolos fazem o mesmo papel: o sistema passa a confiar na identidade confirmada pelo provedor, como Microsoft ou Google. O OpenID Connect é mais recente, construído sobre o OAuth 2.0, e é o mais usado em aplicações web e mobile. O SAML 2.0 é mais antigo, baseado em XML, e ainda exigido por alguns clientes corporativos grandes.

### Dá para colocar login único num sistema antigo?

Depende de como o sistema foi construído, mas raramente é preciso trocá-lo inteiro. Muitas vezes dá para colocar uma camada de autenticação na frente do sistema antigo ou adaptar apenas o módulo de login para aceitar OpenID Connect. O mesmo trabalho costuma eliminar os usuários genéricos compartilhados e criar uma trilha de auditoria dos acessos.

### O que acontece com quem está logado quando a conta corporativa é desativada?

Desativar a conta corporativa impede novos logins, mas uma sessão já aberta pode continuar válida até expirar. Por isso o sistema precisa de sessões com duração razoável, revogação imediata pelo administrador e, de preferência, consulta periódica ao provedor de identidade. Tokens de integração e chaves de API ligados à pessoa também precisam ser revogados à parte.

## Como a Pervian Tech trabalha autenticação

Na Pervian Tech, autenticação é decidida na [arquitetura do software](https://pervian.tech/servicos/arquitetura-de-software), não acrescentada no fim. Começamos entendendo onde estão as identidades da sua empresa (Microsoft, Google ou outro diretório), quem são os usuários externos e quais ações exigem proteção extra. A partir daí, desenhamos o login por SSO, o 2FA, o mapeamento de perfis e a rotina de desligamento junto com o resto do sistema.

Também adaptamos sistemas existentes, com SSO, fim dos usuários compartilhados e trilha de auditoria. Outros temas de proteção de dados estão na categoria [Segurança e LGPD](https://pervian.tech/blog/categoria/seguranca-e-lgpd).

Cada projeto é sob medida e o investimento é sob consulta, definido depois de um diagnóstico inicial gratuito. Se desligar o acesso de quem saiu ainda depende da memória de alguém, [conte como funciona hoje](https://pervian.tech/#contato).