Em ambientes corporativos modernos, onde colaboradores acessam dezenas de aplicações distintas como SaaS, on-premises, legadas e cloud-native, o gerenciamento de credenciais individuais por sistema é um vetor crítico de risco e ineficiência operacional. Organizações com dezenas ou centenas de aplicações enfrentam desafios como a proliferação de identidades fragmentadas, silos de autenticação e credenciais desconectadas entre si.
Os impactos práticos são:
- Risco elevado de comprometimento: senhas reutilizadas entre sistemas com diferentes níveis de proteção.
- Baixa adesão ao MFA: usuários resistem à fricção adicional quando precisam autenticar em cada sistema separadamente.
- Custo operacional de helpdesk: reset de senha é, historicamente, um dos chamados mais frequentes em TI corporativa.
- Dificuldade de auditoria: logs de acesso distribuídos em múltiplos sistemas, sem correlação.
O Single sign-on (SSO) é uma técnica de controle de acesso centralizado que permite que um usuário ou sujeito (subject) seja autenticado uma única vez em um sistema e acesse múltiplos recursos ou objetos (objects) sem precisar se autenticar novamente. O SSO é conveniente para os usuários e traz benefícios de segurança. Quando os usuários precisam lembrar múltiplos nomes de usuário e senhas, eles frequentemente recorrem à prática de anotá-los, o que acaba enfraquecendo a segurança.
Conceitos Fundamentais
Identity Provider (IdP)
O Identity Provider é o componente central do SSO. É ele quem detém e valida as credenciais do usuário. Após autenticar o usuário com sucesso, o IdP emite um token ou assertion que serve de prova de identidade para as aplicações consumidoras. Exemplos comuns: Microsoft Entra ID (Azure AD), Okta, Google Workspace, entre outros.
Service Provider (SP)
O Service Provider é a aplicação que o usuário deseja acessar — um sistema de RH, uma ferramenta de colaboração, um portal interno. O SP não verifica a credencial do usuário diretamente; ele confia no assertion emitido pelo IdP, desde que esse IdP esteja previamente configurado como confiável (trust relationship).
Trust Relationship
A relação de confiança entre IdP e SP é o alicerce do SSO. Essa confiança é estabelecida por meio de troca de metadados, certificados digitais e configurações de endpoints, dependendo do protocolo utilizado. Sem essa relação configurada, nenhum assertion será aceito.
Principais Protocolos de SSO
SAML 2.0 (Security Assertion Markup Language)
O SAML 2.0 é um padrão baseado em XML, amplamente utilizado em ambientes enterprise para SSO federado. Define como IdP e SP trocam informações de autenticação e autorização por meio de assertions XML assinadas digitalmente.
Fluxo SAML (SP-Initiated):
Usuário → SP (acessa recurso protegido)
SP → Redireciona usuário ao IdP com AuthnRequest
IdP → Autentica o usuário (apresenta login)
IdP → Emite SAMLResponse (assertion assinada) via POST ao SP
SP → Valida assinatura e assertions → Concede acesso
OpenID Connect (OIDC)
O OpenID Connect é uma camada de identidade construída sobre o protocolo OAuth 2.0. Enquanto o OAuth 2.0 define um framework de autorização (para que uma aplicação acesse recursos em nome do usuário), o OIDC estende isso para autenticação: o cliente recebe um ID Token (JWT) que contém claims sobre a identidade do usuário.
Fluxo OIDC (Authorization Code Flow):
Usuário → Aplicação (SP/Client)
Client → Redireciona ao Authorization Endpoint do IdP (com scope openid)
IdP → Autentica usuário → Redireciona ao Client com Authorization Code
Client → Troca o code por tokens no Token Endpoint (client_id + client_secret)
IdP → Retorna Access Token + ID Token (+ opcionalmente Refresh Token)
Client → Valida o ID Token (JWT) → Identidade estabelecida
OAuth 2.0 e sua Relação com SSO
É importante diferenciar: OAuth 2.0 sozinho não é SSO. OAuth é um framework de delegação de autorização — permite que uma aplicação acesse recursos em nome do usuário sem que este precise compartilhar suas credenciais. Quando combinado com OIDC, ele passa a suportar autenticação e, consequentemente, SSO.
Em ambientes onde o SSO é implementado via OIDC, o Access Token (opaco ou JWT) é usado para acessar APIs protegidas, enquanto o ID Token é o artefato de identidade propriamente dito.
Kerberos: SSO Nativo em Ambientes Windows
Enquanto SAML e OIDC dominam os cenários web e cloud, o Kerberos é o protocolo de SSO que opera silenciosamente por baixo de toda a infraestrutura Windows corporativa. Criado no MIT nos anos 80 e padronizado na RFC 4120, ele é o mecanismo padrão de autenticação do Active Directory.
O Kerberos resolve um problema crítico: como autenticar um usuário em múltiplos serviços de rede sem que a senha trafegue pela rede em nenhum momento. Em vez disso, são trocados tickets — estruturas criptografadas que provam identidade sem expor o segredo que as gerou.
Todo o modelo é ancorado em uma autoridade central de confiança: o Key Distribution Center (KDC), que no Active Directory reside nos Domain Controllers.
Componentes Arquiteturais
Key Distribution Center (KDC): Composto por dois serviços lógicos:
- Authentication Service (AS): Valida a identidade inicial do usuário e emite o Ticket Granting Ticket (TGT).
- Ticket Granting Service (TGS): Emite Service Tickets mediante apresentação de um TGT válido.
Kerberos como Mecanismo de SSO
O Kerberos entrega SSO de forma nativa: após a autenticação inicial (login na estação Windows), o TGT fica armazenado em memória. Cada acesso subsequente a um serviço do domínio — compartilhamentos de rede, Exchange, SharePoint, SQL Server — é transparente ao usuário: o cliente solicita o Service Ticket ao TGS silenciosamente e apresenta ao serviço sem intervenção humana.
Essa experiência “invisível” é exatamente o SSO na prática — e é o que torna o Kerberos tão fundamental nos ambientes corporativos Windows, mesmo que a maioria dos usuários nunca saiba que ele existe.
Kerberos e Ambientes Híbridos
Em cenários híbridos (AD local + Entra ID), o Kerberos e os protocolos modernos de SSO coexistem. O Azure AD Kerberos permite que dispositivos Azure AD-joined acessem recursos on-premises via Kerberos, usando um TGT especial emitido pelo Entra ID e trocado por um TGT do AD local — um mecanismo de bridge entre os dois mundos. Para recursos puramente em nuvem, o Entra ID usa OIDC/SAML; para recursos internos, o Kerberos continua sendo a base.
Arquitetura de SSO em Ambiente Corporativo
SSO Interno vs. SSO Federado
SSO Interno (Enterprise SSO): todos os recursos e o IdP pertencem à mesma organização. Exemplo: Active Directory + ADFS (ou Entra ID) autenticando usuários para sistemas internos.
SSO Federado: envolve múltiplas organizações que estabelecem relações de confiança entre seus respectivos IdPs. Comum em cenários B2B, onde parceiros precisam acessar recursos de outras empresas usando suas próprias credenciais organizacionais. Padrões como SAML 2.0 federation e OpenID Connect federation são utilizados neste cenário.
Riscos Sistêmicos do SSO
O SSO concentra o controle, o que traz um risco inerente: se o IdP for comprometido, todos os sistemas protegidos por ele estão em risco. Por isso, a segurança do IdP deve ser tratada com prioridade máxima:
- MFA obrigatório para administradores do IdP.
- Monitoramento contínuo de logs de autenticação e eventos de emissão de tokens.
- Revisão periódica de relações de confiança (SPs cadastrados).
- Proteção contra ataques de phishing dirigidos a administradores de identidade.
Integração com Diretórios e Protocolos Complementares
O SSO raramente opera de forma isolada. Em ambientes enterprise, ele se integra a:
- Active Directory / LDAP: fonte autoritativa de identidades. O IdP consulta o AD para validar credenciais e obter atributos de grupo.
- SCIM (System for Cross-domain Identity Management): protocolo de provisionamento automático de usuários entre IdP e SPs. Complementar ao SSO — enquanto o SSO cuida da autenticação, o SCIM cuida de criar/atualizar/desativar contas nos sistemas de destino.
- PAM (Privileged Access Management): para contas privilegiadas, o SSO pode integrar com soluções PAM que adicionam camadas adicionais de controle, como gravação de sessão e aprovação de acesso just-in-time.
Conclusão
O SSO é uma peça fundamental da arquitetura de identidade corporativa moderna, presente em múltiplas camadas: do Kerberos operando silenciosamente nos domínios Windows, ao SAML federando identidades entre organizações, ao OIDC habilitando autenticação em aplicações cloud-native. Cada protocolo foi projetado para um contexto específico, e a escolha correta depende do ambiente, dos sistemas envolvidos e do nível de maturidade da organização.
O que todos esses mecanismos têm em comum é a centralização do controle de autenticação — o que reduz a superfície de ataque, facilita a aplicação de políticas consistentes e melhora a experiência do usuário. Porém, essa centralização também cria um ponto único de alto valor para atacantes.
Em conjunto com MFA forte, acesso condicional e práticas de Zero Trust, o SSO deixa de ser apenas uma conveniência operacional e passa a ser um controle de segurança essencial na estratégia de defesa em profundidade da organização.
Referências
ISC2 – Certified Information System Security Professional – Official Study Guide – Tenth Edition – Mike Chapple, James Michael Stewart, Darril Gibson.
RotaDefault 