SSO (single sign-on) é um método de autenticação que permite ao usuário fazer um único login para acessar vários sistemas autorizados. Em vez de digitar uma senha em cada aplicação, um provedor de identidade central verifica quem é a pessoa uma vez e repassa essa confiança aos demais sistemas. No Wi-Fi corporativo, a mesma identidade pode liberar a rede, acabando com a senha compartilhada.
Em uma empresa média, cada sistema novo vira mais uma senha para o colaborador lembrar. O resultado aparece rápido: chamados repetidos de reset, senhas fracas reaproveitadas e acessos que continuam ativos depois que alguém sai da empresa.
O SSO resolve boa parte disso nas aplicações. Mas existe um ponto que muitas empresas deixam de fora: a rede. O colaborador entra no ERP com a conta corporativa e, minutos antes, conectou o celular ao Wi-Fi com uma senha que metade do prédio conhece.
Este conteúdo explica o que é SSO, como o fluxo funciona, quais protocolos estão por trás do login único e, principalmente, como levar essa mesma identidade até o Wi-Fi. Inclui uma comparação entre os métodos de autenticação de rede, os cuidados com Microsoft Entra ID e um passo a passo de implementação.
O que é SSO (single sign-on) e qual o significado da sigla
SSO significa single sign-on, traduzido como login único ou logon único. No contexto corporativo, isso significa que o colaborador se autentica uma vez em um provedor de identidade e passa a acessar todos os sistemas autorizados para o seu perfil, sem novos logins.
Na prática, o SSO é uma das formas de autenticação wi-fi corporativa e de aplicações que muda onde a senha mora. Em vez de cada sistema guardar e validar credenciais próprias, todos confiam em um ponto central.
Uma analogia ajuda. Pense na chave de um hotel:
- No check-in (o primeiro login), você recebe um cartão.
- O mesmo cartão abre o quarto, a academia e a piscina.
- Se a estadia acaba, a recepção invalida o cartão e todas as portas deixam de abrir de uma vez.
Esse último ponto é o que mais interessa à TI. O ganho do SSO não é só conveniência: é conseguir conceder e revogar acesso em um lugar só.
SSO, login único e senha única não são a mesma coisa
Uma confusão comum é achar que SSO é “usar a mesma senha em tudo”. Não é.
- Senha reaproveitada: cada sistema guarda uma cópia da credencial. Se um vaza, todos ficam expostos.
- Sincronização de senha: a mesma senha é replicada entre sistemas, mas o usuário ainda digita em cada um.
- SSO de verdade: o usuário digita a senha apenas no provedor de identidade. Os outros sistemas recebem uma prova assinada de que ele já foi autenticado, sem nunca ver a senha.
Por isso, quando alguém pergunta “o que é SSO em TI”, a resposta curta é: uma relação de confiança entre sistemas, ancorada em uma identidade central.
Como funciona o SSO: IdP, SP e o fluxo de autenticação
O SSO funciona por uma relação de confiança entre quem autentica e quem entrega o serviço. No ambiente corporativo, isso significa que a senha é validada em um único lugar, e os demais sistemas aceitam o resultado dessa validação.
Três papéis aparecem em todo fluxo de SSO:
- Usuário: a pessoa que quer acessar um sistema.
- Provedor de identidade (IdP): o sistema que guarda as identidades e faz a autenticação. Exemplos: Microsoft Entra ID (antigo Azure AD), Okta, Google Workspace e Active Directory com AD FS.
- Provedor de serviço (SP): a aplicação que o usuário quer usar, como CRM, ERP, Microsoft 365 ou o portal de acesso à rede.
O fluxo típico tem seis passos:
- Solicitação de acesso: o usuário abre o SP, por exemplo o CRM.
- Redirecionamento: sem sessão ativa, o SP envia o usuário para a página de login do IdP.
- Autenticação: o usuário informa as credenciais no IdP. Aqui costuma entrar a autenticação multifator (MFA).
- Emissão do token: com as credenciais válidas, o IdP gera um token ou asserção assinada digitalmente.
- Retorno ao SP: o navegador leva esse token de volta ao SP.
- Acesso liberado: o SP valida a assinatura, confirma que veio do IdP confiável e libera o acesso.
No próximo sistema integrado, o passo 3 não se repete. O IdP reconhece que já existe uma sessão ativa e emite um novo token na hora.
O que é provedor SSO URL e onde ele aparece
Provedor SSO URL é o endereço do IdP para onde o SP redireciona o usuário na hora do login. Ele aparece na configuração de qualquer integração SSO, geralmente com outros dois campos:
- SSO URL ou Login URL: o endpoint do IdP que recebe o pedido de autenticação.
- Entity ID (ou Issuer): o identificador único de cada lado da integração.
- ACS URL (Assertion Consumer Service): o endereço do SP que recebe o token de volta.
Quando um sistema pede “informe o provedor SSO URL”, está pedindo o endereço de login do seu IdP, que você encontra no painel de aplicações corporativas do Entra ID, do Okta ou do Google Workspace. Um erro de digitação nesse campo é uma das causas mais comuns de falha em integração SSO.
Token SSO: o que carrega, quanto dura e como expira
Token SSO é a prova assinada de que o usuário foi autenticado. Ele substitui a senha nas conversas entre sistemas: o SP nunca vê a credencial, só o token.
Os formatos mais comuns:
- Asserção SAML: documento XML assinado, com identidade, atributos (e-mail, grupos) e janela de validade.
- ID token OIDC: um JWT com as informações de quem se autenticou.
- Access token e refresh token (OAuth 2.0): autorizam o acesso a recursos e permitem renovar a sessão sem novo login.
O ciclo de vida segue cinco etapas: geração após a autenticação, entrega ao SP, validação da assinatura, renovação e expiração (por tempo, logout ou revogação). A validade é definida pela política do IdP e costuma ir de minutos a poucas horas. Tokens curtos reduzem o estrago se um deles vazar.
Protocolos de SSO: SAML, OAuth 2.0, OIDC e Kerberos
Protocolos de SSO são os padrões que definem como IdP e SP trocam a prova de autenticação com segurança. Em uma integração SSO corporativa, a escolha do protocolo depende do que o sistema suporta e de onde ele roda (web, mobile, rede local).
| Protocolo | Função principal | Formato | Uso típico | Relação com Wi-Fi |
|---|
| SAML 2.0 | Autenticação e federação | XML assinado | Aplicações web corporativas (Salesforce, Microsoft 365) | Login de colaboradores em captive portal via navegador |
| OAuth 2.0 | Autorização (não autentica sozinho) | Tokens, em geral JWT | Um app acessar recursos de outro em nome do usuário | Base técnica do OIDC e de logins sociais |
| OpenID Connect (OIDC) | Autenticação sobre o OAuth 2.0 | JWT (ID token) | Aplicações modernas, web e mobile | Login em captive portal com Google ou Entra ID |
| Kerberos | Autenticação em rede local | Tickets | Domínio Active Directory, logon do Windows | Indireta: autentica o usuário no domínio, não na rede sem fio |
Alguns pontos que costumam gerar dúvida:
- OAuth 2.0 não é protocolo de autenticação. Ele diz o que um app pode fazer, não quem é o usuário. Quem adiciona a identidade é o OIDC.
- SAML continua dominante no corporativo, principalmente em sistemas mais antigos. O OIDC ganha espaço em apps novos e mobile.
- Kerberos é o SSO “invisível” do Windows. O usuário faz logon no domínio e acessa compartilhamentos e intranet sem nova senha.
Nenhum desses protocolos autentica o dispositivo na rede sem fio por conta própria. Para isso entram outros padrões, como 802.1X e RADIUS, que aparecem mais adiante.
Tipos de SSO: empresarial, federado e social
Os tipos de SSO se diferenciam por quem é o dono da identidade e até onde vai a confiança. Para a TI, isso define que tipo de usuário cada modelo atende e qual mecanismo de acesso faz sentido no Wi-Fi.
SSO empresarial
O SSO empresarial integra os sistemas internos de uma mesma organização: intranet, ERP, e-mail, sistemas financeiros e a própria rede. A identidade vem do diretório corporativo (Active Directory, Entra ID ou Google Workspace).
- Quem atende: colaboradores com conta corporativa.
- No Wi-Fi: é o cenário em que a identidade corporativa substitui a senha compartilhada da rede interna.
SSO federado
O SSO federado cria confiança entre organizações diferentes. Um usuário autenticado na empresa A acessa sistemas da empresa B sem nova conta, porque B confia no IdP de A.
- Quem atende: parceiros, terceiros, grupos empresariais e redes de ensino.
- No Wi-Fi: permite liberar acesso a prestadores com a identidade da própria empresa deles, com prazo e escopo definidos.
SSO social
O SSO social usa contas de Google, Apple, Facebook ou LinkedIn para login. É comum em e-commerce e apps de consumo, para reduzir o atrito de cadastro.
- Quem atende: público externo, sem vínculo corporativo.
- No Wi-Fi: aparece no captive portal para visitantes e clientes, com identificação do usuário e registro de acesso.
Na prática, uma mesma empresa costuma usar os três: SSO empresarial para colaboradores, federado para terceiros e social para visitantes.
Benefícios do SSO corporativo para segurança e operação da TI
O SSO corporativo concentra a autenticação em um ponto controlado. Para a TI, isso significa aplicar políticas uma vez e enxergar todos os acessos em um lugar só.
Os principais ganhos:
- Segurança concentrada: com um único ponto de login, fica viável exigir MFA, bloquear países ou horários e detectar comportamento anômalo. Menos senhas também significa menos senhas fracas reaproveitadas.
- Menos fadiga de senha: o colaborador deixa de anotar senhas e de interromper o trabalho para fazer login em cada sistema.
- Onboarding mais rápido: ao entrar no grupo certo do diretório, a pessoa recebe acesso a todas as ferramentas do seu perfil de uma vez.
- Offboarding confiável: desativar a conta no IdP corta o acesso a todos os sistemas integrados. Nenhum acesso órfão fica para trás.
- Menos chamados de suporte: resets de senha e contas bloqueadas estão entre os tickets mais frequentes do service desk. Centralizar o login reduz esse volume.
- Rastreabilidade e compliance: os logs de autenticação ficam centralizados, o que facilita auditorias e o atendimento à LGPD e ao marco civil da internet, que exige a guarda de registros de conexão.
Há um detalhe que pesa na decisão: esses benefícios só se completam quando a rede também usa a identidade central. Se o Wi-Fi continua com senha compartilhada, a revogação no IdP não tira o ex-colaborador da rede.
O principal risco do SSO é a concentração: o mesmo ponto que simplifica a gestão vira um alvo valioso. Para a TI, isso significa que o IdP precisa de proteção proporcional ao que ele libera.
| Risco | O que pode acontecer | Como mitigar |
|---|
| Ponto único de falha | Uma credencial roubada abre vários sistemas | MFA obrigatório, de preferência resistente a phishing (FIDO2, passkeys) |
| Indisponibilidade do IdP | Ninguém consegue logar se o provedor cair | IdP em nuvem com SLA, contas de emergência e plano de contingência |
| Sessões longas demais | Token roubado continua válido por horas | Tokens curtos, reautenticação em ações sensíveis |
| Sistemas legados | Aplicações antigas sem suporte a SAML ou OIDC | Proxy de aplicação, LDAP ou exceção documentada |
| Permissões acumuladas | Usuário muda de área e mantém acessos antigos | Acesso por grupo e revisão periódica |
| Configuração errada | Asserção aceita sem validar assinatura ou público | Testes de integração e validação de certificados |
MFA (autenticação multifator) exige um segundo fator além da senha: app autenticador, chave física ou biometria. Combinado ao SSO, um atacante com a senha ainda esbarra no segundo fator.
O modelo mais maduro é o MFA adaptativo: o IdP pede o fator extra só quando o contexto foge do padrão (dispositivo novo, local ou horário incomum). Assim, a segurança sobe sem pedir código a cada login.
Governança de identidade sustenta o SSO no longo prazo
Governança de identidade é o conjunto de processos que garante o acesso certo, para a pessoa certa, pelo tempo certo. Sem ela, o SSO só troca um problema por outro.
- Papéis e grupos: permissões definidas por perfil, não por pessoa.
- Provisionamento automático: o protocolo SCIM cria e remove contas nos sistemas conforme o diretório muda.
- Revisões de acesso: gestores confirmam periodicamente quem ainda precisa de cada acesso.
- Minimização de dados: compartilhar com cada SP só os atributos necessários, como pede a LGPD.
SSO no Wi-Fi: como a identidade corporativa chega à rede
SSO no Wi-Fi é usar a mesma identidade do provedor corporativo para decidir quem entra na rede sem fio. No contexto de controle de acesso wi-fi, isso significa trocar a senha compartilhada por um acesso individual, que some quando a conta é desativada.
Aqui mora a diferença que quase nenhum guia sobre SSO explica. SSO de aplicação e autenticação de rede são parentes, mas não são a mesma coisa:
- SSO de aplicação acontece no navegador, depois que o dispositivo já tem internet.
- Autenticação de rede acontece antes: o dispositivo ainda não tem endereço IP e precisa provar quem é para receber um.
Por isso, a identidade no wi-fi chega por três caminhos técnicos diferentes.
O dispositivo conecta em uma rede aberta ou isolada e é redirecionado para uma página de login. Ali, o colaborador entra com a conta do Entra ID, Google Workspace ou outro IdP via SAML ou OIDC. É o modelo mais próximo do SSO de aplicação.
- Funciona em praticamente qualquer dispositivo com navegador.
- Não exige configurar nada no aparelho do usuário.
- A sessão tem prazo, então o login se repete quando ela expira.
No 802.1x, o access point só libera a rede depois que um servidor RADIUS confirma a identidade, consultando o diretório via ldap ou integração com o AD. É a base do WPA2-Enterprise e do WPA3-Enterprise.
- A conexão é automática depois da primeira configuração.
- Permite VLAN dinâmica por grupo do diretório.
- O método mais comum com usuário e senha, PEAP-MSCHAPv2, está perdendo espaço (detalhes na próxima seção).
No EAP-TLS, cada dispositivo recebe um certificado digital emitido para aquele usuário ou aparelho. A rede valida o certificado, sem senha trafegando. É o padrão recomendado pela Microsoft para Wi-Fi corporativo.
- Credencial não transferível: não dá para “passar a senha” para outra pessoa.
- Exige uma forma de emitir e instalar certificados (MDM, como o Intune, ou um onboarding guiado).
| Método | Perfil indicado | Segurança | Experiência do usuário | Esforço da TI |
|---|
| Senha compartilhada (PSK) | Nenhum perfil corporativo | Baixa, sem rastreio individual | Simples | Baixo no início, alto na revogação |
| Captive portal com SAML/OIDC | Colaboradores em BYOD, terceiros | Média, com identidade e logs | Login no navegador a cada sessão | Baixo |
| 802.1X com usuário e senha | Notebooks corporativos legados | Média, depende do método EAP | Automática, mas sofre com troca de senha | Médio |
| EAP-TLS com certificado | Dispositivos corporativos e BYOD gerenciado | Alta | Automática e transparente | Médio a alto, sem uma plataforma que automatize |
Para manter o servidor de autenticação sem hardware próprio, muitas empresas adotam radius na nuvem, que conversa direto com o IdP.
Confira outros conteúdos relacionados:
Cada provedor de identidade conversa com a rede de um jeito. Na integração SSO com o Wi-Fi corporativo, isso significa que a arquitetura certa depende de onde as contas moram hoje.
Active Directory local
É o cenário clássico. Um servidor RADIUS (o NPS da Microsoft ou outra solução) consulta o AD e libera o 802.1X com usuário e senha do domínio.
O ponto de atenção é a expiração de senha. Quando a senha do AD vence, dispositivos que guardaram a credencial antiga caem da rede até o usuário atualizar, o que vira chamado.
Microsoft Entra ID
O Entra ID é um IdP em nuvem que fala SAML e OIDC, mas não oferece um serviço RADIUS nativo. Para levar o Entra ID ao Wi-Fi, há três caminhos comuns:
- Captive portal com login SAML ou OIDC no Entra ID.
- EAP-TLS com certificados distribuídos pelo Intune, validados por um RADIUS que consulta o Entra ID.
- RADIUS na nuvem de terceiros integrado ao Entra ID.
A extensão NPS da Microsoft adiciona MFA a um NPS existente, mas a autenticação primária continua no AD local.
O alerta do Windows 11 sobre PEAP-MSCHAPv2
A partir do Windows 11 22H2, o Credential Guard vem habilitado por padrão em dispositivos elegíveis com licenças Enterprise e Education. Segundo a documentação da Microsoft sobre Credential Guard, com ele ativo:
- Conexões 802.1X baseadas em MSCHAPv2 perdem o login automático (SSO).
- O usuário precisa digitar a senha novamente a cada nova sessão do Windows.
- A recomendação oficial é migrar para autenticação por certificado (EAP-TLS ou PEAP-TLS), que o Credential Guard não bloqueia.
Na prática, quem ainda usa PEAP-MSCHAPv2 com senha do AD tende a ver mais chamados de Wi-Fi depois das atualizações do Windows.
Google Workspace
O Google Workspace autentica via SAML e OIDC e oferece o Secure LDAP em algumas edições, o que permite integrá-lo a um servidor RADIUS. A disponibilidade do Secure LDAP varia conforme a edição contratada. Para BYOD, o captive portal com login Google costuma ser o caminho mais simples.
Quando o SSO resolve o acesso Wi-Fi e quando não resolve
O SSO resolve o acesso Wi-Fi quando existe uma pessoa com identidade corporativa do outro lado. No contexto de uma rede com vários perfis, isso significa que ele é uma peça central, mas não cobre todo mundo.
O SSO resolve bem:
- Colaboradores com notebook corporativo: identidade do diretório, de preferência com certificado.
- Colaboradores com celular pessoal (byod): a conta corporativa substitui a senha compartilhada, e a saída da empresa corta o acesso.
- Diretoria e gestores: o mesmo login da empresa, sem tratamento manual por MAC.
- Terceiros com identidade federada: acesso com prazo, sem criar contas locais.
O SSO sozinho não resolve:
- Visitantes e clientes: não têm conta corporativa. O caminho é captive portal com cadastro, voucher ou login social.
- Dispositivos sem usuário: coletores, impressoras, sensores IoT e TVs não fazem login. Pedem políticas por MAC, certificado de máquina ou rede segmentada.
- Avaliação de postura do dispositivo: saber se o aparelho tem antivírus ou patch em dia é papel de um nac, não do SSO.
SSO no Wi-Fi e NAC podem coexistir?
Sim. Muitas empresas enterprise já têm NAC cobrindo notebooks corporativos, mas ainda usam senha compartilhada para celulares e BYOD, porque estender o NAC para esses casos fica caro ou complexo.
Nesse cenário, uma camada de autenticação baseada em identidade cobre o gap do BYOD e dos visitantes, enquanto o NAC segue cuidando dos dispositivos gerenciados. Uma não substitui a outra.
Perguntas frequentes sobre SSO
1- Qual o significado de SSO? SSO significa single sign-on, ou login único em português. É um método de autenticação em que o usuário faz login uma vez em um provedor de identidade e acessa todos os sistemas autorizados sem digitar a senha de novo.
2- O que é provedor SSO URL? É o endereço de login do provedor de identidade (IdP), para onde o sistema redireciona o usuário na autenticação. Você encontra esse valor no painel do Entra ID, Okta ou Google Workspace, ao cadastrar a aplicação corporativa.
3- SSO e MFA são a mesma coisa? Não. SSO define onde o usuário se autentica (uma vez, em um ponto central). MFA define como ele prova a identidade (com mais de um fator). Os dois se complementam: o SSO concentra o login e o MFA protege esse ponto único.
4- Quais são os principais provedores de SSO? Entre os provedores de identidade (IdP) mais usados estão Microsoft Entra ID (Azure AD), Google Workspace, Okta e Auth0. Para aplicar SSO especificamente na rede Wi-Fi corporativa, o WiFeed integra com todos esses provedores e entrega o controle de acesso diretamente no captive portal.
5- Qual é a importância da SSO nas empresas? O SSO melhora a segurança, simplifica o acesso dos usuários, reduz custos com suporte técnico e ajuda a manter a conformidade regulatória, especialmente com leis como a LGPD.
WiFeed na gestão de autenticação
O WiFeed é uma plataforma SaaS de autenticação e controle de acesso para redes Wi-Fi corporativas. Integra SSO nativo com Microsoft Active Directory, Google Workspace, SAML, LDAP e Gov.br (sem precisar trocar equipamentos).
Compatível com mais de 20 fabricantes de APs (Cisco, Fortinet, Aruba, Intelbras, MikroTik, entre outros), oferece mais de 15 métodos de autenticação, logs completos, conformidade com LGPD e Marco Civil. São mais de 12 mil locais, 70 mil APs gerenciados e 30 milhões de usuários autenticados. Clientes como varejo, atacadistas, lojas de departamento, clínicas e hospitais já usam o WiFeed para autenticar colaboradores e visitantes com SSO na rede Wi-Fi.
Atuamos como a ponte entre as políticas corporativas e os desafios do dia a dia tecnológico, garantindo que o SSO entregue valor real, segurança reforçada e facilidade operacional para sua empresa.
Com o WiFeed, o SSO deixa de ser um conceito para virar uma experiência prática, segura e que transforma a forma como sua rede Wi-Fi e sistemas se comportam. Entre em contato com o nosso time.
