O que é SSO (single sign-on).
Um login para vários softwares. E o que ele não resolve sozinho.

Como o SSO funciona

No SSO há dois papéis. O provedor de identidade (IdP, de identity provider) guarda as contas e faz a autenticação. O provedor de serviço (SP) é o software que a pessoa quer usar, como o CRM, o ERP ou a ferramenta de chamados.

O fluxo típico é assim:

1. A pessoa abre o software e clica em "entrar com a conta da empresa".
2. O software redireciona para o provedor de identidade.
3. O provedor de identidade autentica a pessoa (senha, MFA, chave de segurança) ou reconhece que ela já está autenticada.
4. O provedor de identidade devolve ao software uma asserção (no SAML) ou um token (no OpenID Connect) dizendo quem é a pessoa.
5. O software confia na resposta e abre a sessão, sem pedir senha própria.

No SSO federado, o software nunca vê a senha. Ele confia na assinatura do provedor de identidade, configurada uma vez pelo time de TI.

SAML, OpenID Connect e OAuth no SSO

Na prática, o SSO de uma empresa usa SAML e OIDC lado a lado, conforme o que cada software suporta.

Vantagens do SSO

• Menos senhas: uma credencial forte, com MFA, no lugar de dezenas de senhas reaproveitadas.
• Menos chamados: esquecimento de senha deixa de ser problema de cada software.
• Bloqueio central do login: desativar a conta no provedor de identidade impede novos logins nos softwares federados.
• Política única: MFA, acesso condicional e regras de sessão aplicadas num lugar só.

Riscos e limites do SSO

O SSO concentra a confiança. Por isso, a conta no provedor de identidade precisa de MFA forte, e as contas administrativas dele merecem cuidado redobrado.

Os limites que mais aparecem na auditoria são outros:

• Sessão aberta não é login novo. Bloquear a conta no IdP impede o próximo login, mas uma sessão já aberta no software pode continuar até expirar.
• Contas locais continuam lá. Muitos softwares mantêm usuários criados antes do SSO, contas de administrador de emergência e contas de serviço. Elas não passam pelo IdP.
• Perfis vivem dentro de cada software. O SSO diz quem entrou, não se a pessoa é administradora do CRM ou aprova pagamentos no ERP.
• Nem todo software está no SSO. Planos mais baratos de muitos SaaS não oferecem SAML, e o software contratado fora da TI (shadow IT) nunca foi integrado.

O que acontece com cada acesso quando a conta é bloqueada no SSO

Esta é a tabela que vale conferir antes de dizer "desligamos a pessoa no SSO, está resolvido":

A última linha costuma passar despercebida. Bloquear o login não é o mesmo que remover a licença. No primeiro caso a pessoa perde o acesso, mas a empresa continua pagando pelo assento. O custo só acaba quando a licença é liberada ou o contrato é reduzido.

Quando o SSO só existe no plano mais caro

Muitos fornecedores de SaaS só liberam SAML nos planos corporativos. Para uma empresa com dezenas de ferramentas, isso significa que uma parte delas vai ficar fora do login único por decisão de custo, e não por descuido. Para essas ferramentas, o mínimo é:

• MFA ativado no próprio software, quando houver;
• um responsável nomeado, que saiba quem são os usuários;
• a ferramenta na lista de softwares conferidos em toda saída de colaborador;
• a ferramenta dentro da revisão periódica de acessos.

SSO e o desligamento na prática das empresas brasileiras

O SSO reage ao que acontece no diretório. Mas o desligamento nasce em outro lugar: no RH, no software de folha de pagamento. Entre a rescisão registrada na folha e a conta bloqueada no diretório existe um intervalo, que depende de um aviso por e-mail ou de um chamado.

Três situações comuns alargam esse intervalo:

• Desligamento imediato: a pessoa sai no mesmo dia, e o chamado para a TI só é aberto depois.
• Terceiros e PJ: não estão na folha, então muitas vezes ninguém avisa quando o contrato termina.
• Mudança de área: não há desligamento, logo não há gatilho. A pessoa leva os acessos antigos para a função nova.

O SSO não tem como resolver nenhuma das três, porque a informação não chega até ele. É um problema de processo e de governança.

Checklist para implantar SSO

1. Escolha o provedor de identidade que já é a fonte das contas, em geral o Microsoft Entra ID ou o Google Workspace.
2. Exija MFA no provedor de identidade antes de federar os softwares.
3. Liste os softwares e marque quais aceitam SAML ou OIDC no plano contratado.
4. Comece pelos softwares com dados sensíveis e mais usuários.
5. Depois de federar, desative o login por senha local e mantenha apenas contas de emergência, guardadas e monitoradas.
6. Onde o software aceitar, ligue o provisionamento automático de contas (SCIM).
7. Registre os softwares que ficaram fora e trate cada um como exceção, com dono.

Termos do SSO em uma linha

SSO não é governança de acessos

SSO é autenticação: prova quem é a pessoa. Governança de acessos é saber quem tem acesso a quê, se ainda deveria ter e quem aprovou. É isso que a revisão de acessos, o menor privilégio e a segregação de funções verificam, e é isso que o auditor testa nos ITGC.

Uma empresa pode ter SSO em 100% dos softwares e ainda assim receber apontamento na auditoria, por desligados com contas locais ativas ou por perfis de administrador sem dono.

Material informativo. Não substitui orientação jurídica.

Informações sobre produtos da Microsoft consultadas na documentação pública da Microsoft em novembro de 2026. Microsoft, Microsoft Entra, Microsoft 365, Active Directory, Windows Server, Azure, Google Workspace, Workday, SAP SuccessFactors, TOTVS, Senior, ADP e demais nomes citados são marcas de seus titulares. A Niuco não é afiliada, parceira nem endossada por eles; a citação é apenas descritiva.