O que é SSO e como acessar vários sistemas com uma única conta?

Como o SSO funciona por trás da tela?

O SSO envolve dois lados. De um, fica o provedor de identidade, chamado de IdP (Identity Provider), que guarda as contas e faz a autenticação. Exemplos comuns são o Microsoft Entra ID, o Google Workspace e o Okta. Do outro, ficam as aplicações, que deixam de conferir a senha e passam a aceitar a confirmação enviada pelo IdP.

Na prática, o colaborador faz login pela manhã, com senha e MFA. Ao abrir o CRM, o sistema o redireciona ao provedor de identidade, que reconhece a sessão ativa e devolve uma confirmação assinada digitalmente. O CRM valida essa assinatura e libera a entrada sem pedir nada ao usuário. Tudo acontece em poucos segundos.

Essa troca segue padrões abertos. Os mais usados em aplicações web são o SAML 2.0 (Security Assertion Markup Language) e o OpenID Connect, este construído sobre o OAuth 2.0. Em redes com Active Directory, o Kerberos oferece um efeito parecido para recursos do domínio, como pastas compartilhadas e sistemas internos.

SSO é o mesmo que um gerenciador de senhas?

Não. O gerenciador de senhas guarda uma senha diferente para cada sistema e a preenche no lugar do usuário. As senhas continuam existindo e podem ser vazadas, reutilizadas ou capturadas em um phishing.

No SSO por federação, a aplicação nem chega a receber a senha do usuário. Ela confia no provedor de identidade. Quando a conta é bloqueada no IdP, novos acessos às aplicações integradas deixam de funcionar.

Alguns provedores oferecem um modo intermediário para aplicações que não suportam federação: o IdP armazena a senha daquele sistema e a preenche automaticamente. A experiência melhora, mas o controle não é o mesmo. As duas ferramentas podem conviver, com SSO para o que aceita integração e gerenciador de senhas para o que fica de fora.

Por onde começar a implantar?

1. Levante as aplicações em uso, incluindo os serviços em nuvem contratados diretamente pelas áreas, sem passar pela TI.
2. Defina o provedor de identidade. Muitas empresas já têm um, como o Microsoft Entra ID para quem usa Microsoft 365.
3. Fortaleça a identidade central antes de ampliar o alcance dela: MFA para todos, políticas de acesso condicional e bloqueio de protocolos antigos de autenticação.
4. Priorize as aplicações com mais usuários e com dados sensíveis, como e-mail, ERP, CRM e sistemas financeiros.
5. Avalie o provisionamento automático de contas. Com o padrão SCIM (System for Cross-domain Identity Management), o IdP cria, altera e desativa usuários nas aplicações compatíveis.
6. Comece com um grupo piloto, corrija o que falhar e só então amplie para toda a empresa.

Mantenha também contas de acesso emergencial, bem protegidas e monitoradas, para o caso de o provedor de identidade ficar indisponível ou de uma configuração errada bloquear os administradores.

Equívocos comuns sobre SSO

SSO não é gestão de permissões. Ele resolve a autenticação, ou seja, confirma quem é a pessoa. O que ela pode fazer dentro de cada sistema continua definido nos perfis da aplicação ou em uma solução de IAM. Quem tinha permissão demais antes do SSO continua com permissão demais depois dele.

Bloquear a conta central não encerra tudo na hora. Sessões já abertas em algumas aplicações podem continuar válidas até expirar. Contas locais criadas antes da integração também seguem funcionando se ninguém as desativar. O processo de desligamento precisa prever as duas situações.

Nem sempre o SSO vem incluído. Alguns fornecedores de software como serviço só liberam a integração em planos mais caros. Essa pergunta deve entrar na avaliação de qualquer sistema novo, junto com o suporte a SAML, OpenID Connect e SCIM.