O que é SSO: autenticação única e federação

SSO (autenticação única) é um processo em que uma conta e seus autenticadores dão acesso a várias aplicações de forma contínua, em geral por um protocolo de federação. Em vez de inventar senha em cada sistema, você prova identidade uma vez perante um provedor e as aplicações confiam nessa prova para abrir a sessão local.

Você já abriu o e-mail, o painel do cliente, a ferramenta de tarefas e o sistema de notas fiscais e digitou quase a mesma senha quatro vezes. Em seguida veio o cansaço, o atalho perigoso de reutilizar a senha e o risco de um vazamento em um site fraco contaminar os demais. O single sign-on existe para cortar esse ciclo sem fingir que o problema de identidade desapareceu.

Além disso, quem gerencia acesso em empresa ou produto digital precisa decidir se cada aplicação terá cadastro próprio ou se haverá um centro de confiança. Por isso este verbete explica o que a autenticação única faz, quais protocolos aparecem no caminho, onde o ganho de usabilidade vira concentração de risco e o que conferir antes de ligar o login federado em produção.

Como o SSO autentica você em vários sistemas#

O SSO autentica você uma vez perante um provedor de identidade e, depois, entrega às aplicações uma prova assinada de que aquela pessoa foi verificada. Assim a aplicação não precisa guardar a senha do usuário, porque ela confia no provedor e valida a prova recebida antes de criar a sessão própria. No glossário do NIST, o single sign-on é descrito como processo em que uma conta e seus autenticadores acessam várias aplicações de maneira contínua, em geral com protocolo de federação.

Na linguagem da federação de identidade, o provedor autentica e emite a asserção, enquanto a aplicação que confia nela é a parte confiadora. Por exemplo, você clica em “Entrar com a conta da empresa”, o navegador vai ao provedor, você usa senha, código ou outro fator, e volta à aplicação com um código ou token de curta duração. Em seguida a aplicação troca esse material por informação de identidade e abre a sessão local, muitas vezes marcada por um cookie de navegador ou por um token opaco no servidor.

O MDN descreve o fluxo recomendado de OpenID Connect em duas etapas. Primeiro a aplicação redireciona o navegador ao endpoint de autorização do provedor. Depois, com o código recebido, chama o endpoint de token e obtém um ID token assinado junto com um access token, conforme o guia de identidade federada. Porém o código costuma expirar rápido, e a recomendação comum é limitar essa janela a poucos minutos. Assim um código interceptado perde utilidade se não for trocado a tempo.

Enquanto isso, a validação do lado da aplicação não é opcional. A parte confiadora precisa verificar assinatura, emissor, audiência e validade temporal da asserção. Se aceitar material forjado ou reutilizado, o atacante entra sem passar pelo provedor. Por outro lado, se a validação estiver correta, o comprometimento de uma aplicação não deveria automaticamente fabricar identidade válida nas demais, porque cada sessão e cada audiência ficam amarradas ao contexto certo.

Há um custo escondido que muita implantação ignora. Centralizar o login melhora a experiência, porém concentra o impacto de indisponibilidade e de comprometimento do provedor. Se o provedor cai, várias aplicações param de autenticar novos usuários ao mesmo tempo. Se a sessão no provedor for sequestrada, o invasor pode tentar saltar entre serviços ainda cobertos por aquele ticket de confiança.

Na prática, o que eu vejo com mais frequência é time tratar o redirecionamento como já seguro e esquecer a validação rigorosa do retorno. Quem opera SSO de verdade testa rejeição de asserção inválida com a mesma seriedade com que testa o login feliz, porque falha silenciosa de verificação só aparece quando alguém já está explorando o buraco.

Papéis, confiança e o que a aplicação realmente recebe#

A federação de identidade não copia a senha para cada site. Ela transporta reivindicações sobre o sujeito, como identificador estável, e-mail verificado ou grupos, e a aplicação decide autorização local a partir disso. Ou seja, autenticar não é o mesmo que autorizar. Você pode estar autenticado e ainda assim sem permissão para um módulo administrativo.

Além disso, a confiança precisa ser explícita. A aplicação só deve aceitar provedores cadastrados, com chaves conhecidas e metadados conferidos. Aceitar qualquer emissor só porque o token parece JWT é abrir a porta para um provedor malicioso ou mal configurado. No entanto, restringir demais sem processo de onboarding também gera atalho operacional, com gente pedindo exceção permanente de senha local.

SAML, OpenID Connect e OAuth no SSO#

SAML 2.0 e OpenID Connect são os caminhos mais comuns de SSO empresarial e web moderno, enquanto OAuth 2.0 sozinho é framework de autorização e não substitui a camada de identidade. A OWASP deixa a distinção clara no guia de autenticação, ao orientar o uso de OpenID Connect para autenticação e SSO e de OAuth para autorização de APIs, com validação de emissor, audiência, assinatura e expiração do ID token na folha de autenticação.

A Microsoft resume o critério de escolha de forma prática no guia de decisão. SAML 2.0 é protocolo maduro baseado em XML, forte em cenários empresariais legados e em mapeamento detalhado de atributos. OpenID Connect, construído sobre OAuth 2.0, usa tokens JSON e encaixa melhor em aplicações novas, SPA, mobile e microsserviços, segundo o comparativo SAML versus OpenID Connect. Por isso produto novo costuma começar em OIDC, porém cliente corporativo antigo ainda pode exigir SAML por contrato ou por limitação do provedor interno.

OAuth 2.0, descrito no RFC 6749, permite que um cliente obtenha acesso limitado a um serviço HTTP sem receber a senha do dono do recurso, por meio de tokens emitidos após aprovação. Assim ele é peça central do ecossistema moderno. No entanto não responde sozinho à pergunta de quem é o usuário. OpenID Connect acrescenta o ID token e o fluxo de identidade sobre essa base.

Quando SAML ainda faz sentido#

SAML continua útil quando o parque já fala XML, quando há federação estável entre empresas e quando o requisito de compliance cita explicitamente o perfil de navegador SAML. A validação segura exige checar assinatura, destinatário, tempos e amarração entre pedido e resposta. Ou seja, SAML ligado sem checagem completa de mensagem já foi cenário de falha pública em integrações reais.

Por outro lado, carregar SAML em aplicativo mobile nativo ou em API pura costuma ser desconfortável. O payload XML é verboso, as bibliotecas exigem disciplina e o fluxo de navegador nem sempre mapeia bem para o cliente. Em seguida o time tenta gambiarras de WebView e aumenta superfície de ataque. Se o produto for cloud-native e o cliente aceitar OIDC, a troca de protocolo reduz atrito de desenvolvimento e de operação.

Se fosse comigo, eu começaria pelo inventário do que o cliente já opera e só depois escolheria protocolo. Preferir OIDC por moda e descobrir no go-live que o IdP corporativo só entrega SAML gera atraso, custo de ponte e pressão para abrir exceções inseguras. O protocolo certo é o que o ecossistema consegue operar com validação completa, não o mais citado em slides.

Benefícios e riscos reais do SSO#

O benefício principal do SSO é reduzir a quantidade de senhas distintas que a pessoa precisa criar e lembrar, o que diminui atrito e a tentação de reutilizar credenciais fracas. Além disso, a gestão de acesso fica mais coerente quando admissão, desligamento e troca de fator acontecem no provedor central. Porém o mesmo desenho concentra risco, porque uma sessão comprometida no provedor pode ampliar o alcance do invasor para várias aplicações cobertas.

Do lado da segurança defensiva, menos bancos de senha espalhados significa menos alvos com hashes mal protegidos em sistemas secundários. A aplicação passa a confiar em provas assinadas e em criptografia de transporte via HTTPS, em vez de receber a senha em cada formulário. No entanto, isso só vale se a validação da asserção for correta e se o canal não for degradado. Token aceito sem checar audiência ou assinatura anula o ganho.

Há também custo operacional e financeiro. Integrar cada aplicação, mapear atributos, treinar suporte e manter metadados de federação exige tempo de engenharia e de identidade. Por exemplo, um time que liga SSO em dez ferramentas SaaS sem processo de offboarding descobre usuários que continuam entrando após a saída da empresa, porque o vínculo local nunca foi revogado. Assim a autenticação única resolve login e não resolve sozinha o ciclo de vida da conta.

O ponto único de falha e a ilusão de segurança automática#

Quando o provedor fica indisponível, o login de várias frentes trava ao mesmo tempo. Enquanto isso, usuários pedem contorno por senha local e o time, sob pressão, reabre exceção permanente. Essa exceção vira caminho paralelo que o atacante prefere, porque costuma ter menos monitoramento do que o fluxo federado. Por outro lado, manter senha local só para emergência sem controle e sem alerta também é risco.

Outro efeito colateral é a confiança excessiva do usuário. A tela familiar do provedor reduz fricção, porém também treina a pessoa a clicar rápido. Campanhas de engenharia social exploram páginas falsas de login do IdP. Ou seja, SSO não elimina phishing. Em alguns contextos ele até torna a página falsa mais crível, porque o hábito de redirecionar já existe.

O erro que mais custa caro aqui é vender SSO como escudo mágico e esquecer sessão, logout e vínculo de conta. Sem encerrar sessões locais após logout global, sem reautenticar em ações sensíveis e sem notificar vínculo de identidade nova, o benefício de usabilidade vira atalho para tomada de conta. Segurança de verdade trata o provedor como ativo crítico, com fator forte, monitoramento e plano de falha ensaiado.

SSO com autenticação de dois fatores e sessões#

SSO e autenticação de dois fatores se reforçam quando o segundo fator fica no provedor e cobre o conjunto de aplicações, em vez de ficar solto em cada tela fraca. Assim você fortalece o ponto em que a identidade é realmente verificada. Porém se o segundo fator for frágil, ou se a sessão longa no provedor permitir saltar para apps sensíveis sem novo desafio, o desenho só empurra o risco para outro lugar.

A sessão precisa de política explícita. Tempo de vida curto demais gera irritação e contorno. Tempo longo demais amplia a janela após roubo de cookie ou de token. Além disso, logout deve invalidar o que for possível no provedor e nas aplicações participantes. Logout que só apaga cookie local e deixa a sessão do IdP viva é logout cosmético. Em seguida o usuário acha que saiu do computador compartilhado e o próximo visitante reabre o acesso com um clique.

Há também o papel da biometria e de autenticadores modernos no provedor. Eles podem reduzir dependência de senha memorizável, no entanto exigem recuperação bem desenhada. Recuperação fraca por e-mail sem proteção adicional vira o caminho mais barato para o atacante. Por isso a força da recuperação precisa acompanhar a força do login, senão o fator forte no dia a dia é contornado no dia da emergência.

Quem opera identidade de verdade logo percebe que o debate entre SSO ou 2FA é falso dilema. O desenho maduro usa os dois no lugar certo, com reautenticação para troca de e-mail, vínculo de novo provedor, exportação de dados e alterações administrativas. Sem esse degrau extra, a sessão conveniente vira chave mestra silenciosa.

Como implantar SSO sem abrir falhas#

Implantar SSO com segurança começa por inventário de aplicações, definição do provedor de identidade, escolha de protocolo suportado de ponta a ponta e checklist de validação na parte confiadora. Em seguida entram mapeamento de atributos mínimos, regra de provisionamento e desprovisionamento, e teste de rejeição de mensagens inválidas. Além disso, o tráfego de login precisa permanecer em HTTPS com certificados válidos, porque o redirecionamento carrega códigos e tickets sensíveis.

No vínculo de conta federada, não ligue identidades só porque o e-mail coincide. Use a combinação estável de emissor e sujeito, exija sessão autenticada na conta local antes de adicionar ou remover vínculo, e notifique o usuário quando a identidade mudar. Esses cuidados alinham-se à ideia de que atributo de perfil não é prova suficiente de posse da conta.

Do lado SAML, valide assinatura com certificado do IdP autorizado, confira destinatário e tempos, e amarre a resposta ao pedido original quando o perfil exigir. Aceitar o XML e seguir sem essas checagens não é integração pronta. Em fluxos OIDC, a mesma disciplina se aplica ao ID token e ao código de autorização de curta duração.

Privacidade, dados pessoais e limites legais no Brasil#

SSO trata dados pessoais de identificação e, com frequência, metadados de autenticação. No Brasil, a Lei nº 13.709/2018 (LGPD) exige finalidade legítima, necessidade, segurança e transparência no tratamento, entre outros princípios do art. 6º, no texto compilado disponível no Planalto. Por isso pedir ao IdP o menor conjunto de atributos possível não é só elegância técnica. É alinhamento ao princípio da necessidade.

Além disso, compartilhar perfil completo porque um dia pode servir amplia superfície de vazamento e de uso incompatível. Informe o titular com clareza sobre quem autentica, o que é compartilhado e por quanto tempo a sessão vive. No entanto, transparência sozinha não basta se o provedor e as aplicações não forem capazes de demonstrar medidas de segurança e de atendimento a direitos do titular.

Antes de expandir o perímetro, eu paro e pergunto quem revoga acesso em uma hora, quem audita falhas de validação e quem responde se o IdP vazar. Sem dono claro para esses três pontos, a autenticação única vira projeto de front-end com dívida de identidade. O primeiro passo útil é um piloto em poucas aplicações não críticas, com métricas de falha de login, tempo de offboarding e taxa de exceção de senha local.

Termos relacionados#

• autenticação de dois fatores (2FA) reforça o momento em que o provedor realmente verifica a pessoa antes de emitir a confiança do SSO.
• HTTPS protege o transporte dos redirecionamentos, códigos e cookies usados no fluxo federado.
• criptografia sustenta assinatura e, quando aplicável, proteção das asserções e dos tokens trocados entre provedor e aplicação.
• assinatura digital é o mecanismo que permite à aplicação verificar que a asserção veio do IdP esperado e não foi alterada no caminho.
• API (interface de programação de aplicações) costuma receber autorização via OAuth depois que o SSO resolveu a identidade do usuário.
• cookie de navegador frequentemente carrega a sessão local da aplicação após o retorno bem-sucedido do provedor.
• engenharia social permanece ameaça relevante, porque páginas falsas de login do IdP exploram o hábito do redirecionamento.

Perguntas frequentes sobre SSO#

As dúvidas abaixo cobrem definição no dia a dia, diferença entre protocolos, relação com senha local, impacto de um provedor fora do ar e cuidados de privacidade. Elas servem tanto para quem usa o login federado quanto para quem vai decidir se a organização deve adotá-lo agora.

O que é SSO no dia a dia de quem usa muitos sistemas?#

É entrar uma vez no provedor da empresa ou do produto e abrir várias ferramentas sem redigitar a mesma senha em cada sistema. A autenticação única não apaga a necessidade de proteção forte no provedor, porém reduz o atrito de cadastros paralelos. Na prática, você troca muitas senhas locais por uma identidade central bem protegida e por sessões locais bem delimitadas.

SSO, single sign-on e autenticação única são a mesma coisa?#

Sim no uso corrente. Single sign-on é o termo em inglês, autenticação única é a forma usual em português e SSO é a sigla. Em documentos técnicos, o NIST trata single sign-on como processo de autenticação com uma conta e autenticadores para várias aplicações, em geral via federação. O detalhe que muda é a implementação, não o nome popular.

OAuth sozinho já resolve o login do usuário?#

Não de forma completa. OAuth 2.0 organiza autorização e emissão de tokens de acesso a recursos, conforme o RFC 6749. OpenID Connect acrescenta a camada de identidade com ID token para o SSO web moderno. Por isso misturar os dois termos sem cuidado gera integração que autoriza API e ainda assim autentica mal o usuário.

Se o provedor de identidade cair, o que acontece com as aplicações?#

Novos logins e renovações que dependem do provedor tendem a falhar até a recuperação. Sessões locais já abertas podem continuar por um tempo, dependendo da política de cada aplicação, o que é alívio parcial e também risco se não houver revogação. Por isso o desenho precisa de monitoramento do IdP, comunicação clara ao usuário e critérios para manutenção emergencial sem abrir buraco permanente.

SSO elimina a necessidade de senha local em todos os casos?#

Nem sempre. Muitas organizações mantêm caminho de emergência, usuários externos sem federação ou aplicações que ainda não foram integradas. O problema começa quando a exceção vira regra sem auditoria. Se existir senha local, ela precisa de política, monitoramento e preferência pelo fluxo federado sempre que ele estiver disponível.

SSO resolve sozinho as obrigações da LGPD?#

Não. A LGPD continua a exigir base adequada, finalidade, necessidade, segurança e transparência no tratamento dos dados pessoais envolvidos no login e no compartilhamento de atributos. O SSO pode ajudar a centralizar controles, porém também concentra dados e responsabilidade. Cada controlador e operador no fluxo precisa saber o que trata e como o titular exerce direitos.

Conclusão#

Para a maioria das equipes e organizações que já convivem com dezenas de ferramentas, o SSO bem implantado é caminho superior a senhas repetidas em cada sistema. Ele reduz atrito, concentra o fortalecimento do fator de autenticação e torna admissão e desligamento mais previsíveis. O ganho só se sustenta com validação rigorosa de asserções, política de sessão e offboarding rápido.

A resposta muda quando não há dono para o provedor, quando aplicações críticas ficam sem reautenticação em atos sensíveis ou quando a exceção de senha local cresce sem controle. Nesses casos, a autenticação única amplia o raio de um erro operacional. Também muda quando o protocolo exigido pelo cliente não casa com o stack atual e a pressa em entregar SSO pula checagens básicas de assinatura e audiência.

O primeiro passo concreto é escolher um conjunto pequeno de aplicações, fixar o provedor e o protocolo, escrever o checklist de validação da parte confiadora e medir falha de login junto com tempo de revogação de acesso. Só depois disso vale expandir o perímetro. SSO bom é identidade operada com disciplina, não botão de conveniência ligado sem dono.

Este texto sobre SSO (autenticação única) é informativo e geral. Não constitui consulta jurídica nem orientação individual sobre adequação à LGPD, desenho de IAM ou escolha de fornecedor. Requisitos legais, riscos e controles dependem do contexto de cada organização e do fluxo de dados pessoais envolvido. Para decisões de conformidade ou arquitetura de identidade em produção, procure profissional habilitado nas áreas de direito e de segurança da informação.