O Single Sign-On (SSO) permite que os usuários se autentiquem uma única vez com um provedor de identidade (IdP) centralizado e acessem várias aplicações sem precisar inserir as credenciais novamente. O SSO elimina a necessidade de digitar senhas repetidamente transferindo a responsabilidade pela autenticação de aplicações individuais para uma autoridade central que mantém o estado de autenticação.

Quando você se autentica na rede corporativa e acessa o Slack, o GitHub ou uma base de conhecimento interna imediatamente sem precisar digitar a senha outra vez para cada aplicação, está experimentando o SSO exatamente como ele foi pensado.

A implementação do SSO proporciona benefícios imediatos e mensuráveis para as equipes de segurança e desenvolvimento, pois centraliza o controle e padroniza a experiência de autenticação.

Centralização da segurança e da conformidade

• Minimiza a superfície de ataque: a centralização da autenticação em um único evento de autenticação primário reduz o número de credenciais que os usuários gerenciam ativamente em todo o ecossistema, ajudando a minimizar a superfície de ataque como um todo e o potencial de comprometimento.
• Impõe políticas consistentes: o SSO ajuda a impor políticas de autenticação robustas, incluindo a Autenticação Multifatorial (MFA), no IdP. Isso elimina a necessidade de implementar medidas redundantes em dezenas de sistemas.
• Simplifica a auditabilidade: os registros de autenticação centralizados otimizam a criação de trilhas de auditoria e relatórios de conformidade, fornecendo às equipes de segurança uma única fonte de informações confiáveis sobre o acesso do usuário em todo o ecossistema de aplicações.

Como melhorar a velocidade e a experiência do usuário (UX)

• Elimina a redundância: para as equipes de desenvolvimento, o SSO elimina a necessidade de implementar e manter a lógica de autenticação em cada nova aplicação, permitindo que os desenvolvedores se concentrem nos recursos principais.
• Reduz a sobrecarga de suporte: o uso do SSO minimiza o volume de chamados de suporte técnico para redefinição de senhas e bloqueios de contas, permitindo que as equipes de suporte se concentrem em problemas de maior valor.
• Acelera o provisionamento: a integração e o desprovisionamento de usuários são simplificados, pois o acesso a vários sistemas é concedido ou revogado por meio de uma única ação no sistema de identidade central.

O SSO opera por uma série de redirecionamentos seguros baseados em sessão, construídos sobre uma relação de confiança criptográfica entre uma aplicação (o provedor de serviços ou SP) e o IdP.

O fluxo principal de SSO

1. Solicitação inicial: um usuário tenta acessar uma aplicação protegida (SP). Ao reconhecer a solicitação não autenticada, o SP redireciona o navegador do usuário para o endpoint de login do IdP.
2. Autenticação e sessão do IdP: o usuário se autentica com o IdP usando um método de sua preferência (como senha, chave de acesso ou biometria). O IdP valida a identidade, estabelece uma sessão autenticada e armazena um identificador de sessão seguro (normalmente em um cookie HttpOnly, Secure, SameSite).
3. Emissão de token: o IdP redireciona o usuário de volta para o SP com um artefato de segurança personalizado para essa aplicação.

• Para a Security Assertion Markup Language (SAML) 2.0, especificada pela OASIS, esse artefato é uma asserção XML assinada que contém declarações de identidade do usuário.
• Para o OpenID Connect (OIDC), conforme especificado pela OpenID Foundation, envolve a troca de um código de autorização por um token de ID e um token de acesso, juntamente com um token de atualização opcional, dependendo do tipo de cliente e da configuração do escopo. Para mais informações sobre essa distinção, consulte Autenticação ou autorização.

4. Acesso concedido: o SP valida a asserção ou token verificando assinatura, expiração (exp), not-before (nbf), emissor (iss) e público-alvo (aud) e estabelece uma sessão local para o usuário.

Acesso subsequente sem interrupções

Quando o mesmo usuário, na mesma sessão do navegador, acessa uma segunda aplicação que confia no mesmo IdP:

1. A segunda aplicação detecta a solicitação não autenticada e redireciona o usuário para o IdP.
2. O IdP detecta imediatamente a sessão autenticada existente por meio do cookie de sessão.
3. O IdP emite um novo token de segurança específico para a aplicação, sem pedir que o usuário se autentique novamente.
4. O usuário obtém acesso contínuo à segunda aplicação.

Essa reutilização do evento de autenticação central é a base técnica do SSO.

O SSO moderno depende de protocolos padronizados que orientam a troca de dados de identidade e autorização. Para garantir flexibilidade de integração, é necessário selecionar o protocolo correto (ou, frequentemente, ser compatível com ambos).

Protocolo	Formato do token	Caso de uso principal	Complexidade
SAML 2.0	Asserções XML	Enterprise B2B Federation, sistemas legados	Mais detalhado; requer gerenciamento de certificados X.509 para verificação de assinatura e criptografia opcional, incluindo rotação de certificados e monitoramento de expiração
OIDC	JSON Web Tokens (JWTs)	Aplicações modernas para web, dispositivos móveis e baseadas em API	Mais simples, RESTful e mais adequado para desenvolvedores

• O OIDC é a camada de identidade construída sobre o OAuth 2.0. Ele usa JWTs assinados para declarações de identidade em tokens de ID e se alinha nativamente com arquiteturas de API. Para aplicações novas, voltadas para a internet ou para dispositivos móveis, o OIDC com o fluxo de código de autorização e PKCE é a recomendação das Boas Práticas de Segurança Atuais do OAuth 2.0.
• O SAML 2.0 continua sendo predominante para federação B2B, especialmente na integração com a infraestrutura de identidade do cliente, como o Active Directory Federation Services (AD FS), já que muitas vezes é um requisito obrigatório para grandes empresas.

Em um contexto de SaaS B2B, a aplicação geralmente precisa aceitar ambos os protocolos, já que o IdP do cliente determina o requisito de integração.

Em SaaS B2B, o SSO multi-tenant exige que uma aplicação (o SP) faça federação com o IdP independente de cada organização cliente.

• Configuração específica do locatário: uma aplicação deve armazenar e gerenciar os metadados de configuração exclusivos do IdP (como certificados de assinatura SAML ou segredos de cliente OIDC) com segurança para cada cliente.
• Descoberta do domínio de origem (HRD): a aplicação deve determinar qual IdP do cliente usar para rotear a solicitação de autenticação. Isso geralmente é feito roteando a aplicação com base no domínio de e-mail do usuário ou em um identificador da organização inserido antes do login.
• Provisionamento Just-In-Time (JIT): o JIT cria automaticamente a conta local do usuário na aplicação durante o fluxo inicial de autenticação SSO, com base nas declarações recebidas do IdP. Isso elimina o provisionamento manual de contas de usuário para usuários corporativos.
• Autorização pós-autenticação: após a autenticação SSO bem-sucedida, uma aplicação deve impor políticas de autorização, como o Controle de Acesso Baseado em Funções (RBAC), para determinar quais recursos o usuário pode acessar. O SSO confirma a identidade enquanto a camada de autorização da aplicação controla as permissões.

Apesar de centralizar a autenticação, o SSO consolida o risco. Os desenvolvedores devem garantir que o SP esteja protegido contra vulnerabilidades relacionadas a tokens.

• Validação de token não negociável: cada endpoint de API protegido deve realizar a validação completa do JWT. Isso inclui verificar a integridade da assinatura, conferir a declaração exp e confirmar as declarações iss e aud para garantir que o token seja autêntico e destinado à sua aplicação.
• Armazenamento seguro: evite armazenar tokens de acesso ou de atualização sensíveis no localStorage ou no sessionStorage, pois isso aumenta o risco de ataques de Cross-Site Scripting (XSS). Para aplicações de página única, use armazenamento em memória com atualização automática. Para apps web tradicionais, use cookies com os atributos HttpOnly, Secure e SameSite.
• PKCE para OIDC: sempre utilize o fluxo de código de autorização com Proof Key for Code Exchange (PKCE) para todas as aplicações baseadas em OIDC, incluindo apps móveis e web, para mitigar ataques de interceptação de código de autorização.
• Tokens de curta duração: use tokens de acesso de curta duração (com duração máxima de 15 a 60 minutos) e implemente a rotação de tokens de atualização. Cada operação de atualização emite um novo token e invalida o anterior, permitindo a detecção imediata de roubo de tokens.
• Prevenção de fixação de sessão: após validar o token do IdP, o provedor de serviços deve gerar um novo identificador de sessão local imediatamente para evitar ataques de fixação de sessão. Essa responsabilidade é do provedor de serviços (e não do IdP).

Tratamento de sessões inseguras de SPs

Os provedores de serviços geralmente validam o token do IdP corretamente, mas falham em proteger a sessão da própria aplicação. Após a autenticação SSO, o SP deve estabelecer uma sessão segura com tempo limite adequado, proteção contra CSRF e atributos de cookies seguros.

Políticas inadequadas de tempo de vida do token

Aceitar sessões de IdP de longa duração (mais de 24 horas) sem reautenticação cria riscos. Implemente tempos limite de sessão adequados e solicite a reautenticação antes de ações de alto risco usando autenticação em vários níveis.

Como ignorar a complexidade do logout

O processo de logout do SSO requer coordenação entre o IdP e todos os SPs ativos. Implementações incompletas deixam sessões ativas em algumas aplicações após o “logout”, criando uma falsa sensação de segurança. Implemente o logout centralizado (Single Logout/SLO) ou uma comunicação clara sobre o comportamento da sessão.

Confiar em asserções do IdP sem validação

Os provedores de serviços devem validar cada assinatura de token, data de expiração, público-alvo e declaração do emissor. Ignorar a validação porque "veio do nosso IdP" é uma vulnerabilidade que os invasores podem explorar pela falsificação de tokens ou ataques de repetição.

Como o SSO funciona com aplicações móveis?

O SSO móvel utiliza o protocolo OIDC com o fluxo de código de autorização e PKCE. Ele precisa do navegador do sistema (ASWebAuthenticationSession no iOS, Custom Tabs no Android) em vez de visualizações da web incorporadas. O navegador do sistema compartilha o cookie de sessão do IdP entre apps que usam o mesmo domínio de autenticação, possibilitando o SSO verdadeiro. No entanto, o comportamento de compartilhamento de sessão varia de acordo com a plataforma e as configurações de privacidade. O ASWebAuthenticationSession do iOS cria sessões efêmeras por padrão, exigindo que os usuários optem pela persistência de sessão. As visualizações da web embutidas não podem acessar o armazenamento de cookies do sistema e comprometem a experiência de SSO.

O SSO substitui a Autenticação Multifatorial (MFA)?

Não. O SSO determina onde a autenticação ocorre (em um IdP central). A MFA determina a força da autenticação. As organizações devem combinar ambas: impor a MFA no IdP central para que uma única autenticação forte proteja o acesso a todas as aplicações conectadas.

Quando o SSO não é a escolha certa?

A complexidade e os requisitos de infraestrutura do SSO muitas vezes superam os benefícios para aplicações pequenas voltadas ao consumidor ou sites de conteúdo simples. O SSO proporciona o máximo valor em ambientes corporativos com gerenciamento de TI centralizado, onde os usuários precisam de acesso consistente a vários recursos protegidos.

Implementar o SSO do zero, especialmente com suporte para SAML e para OIDC, é uma tarefa complexa. O uso de uma plataforma de identidade dedicada, como a Auth0, pode ajudar a lidar com a complexidade do protocolo, o gerenciamento de sessões e o reforço da segurança, permitindo que os desenvolvedores se concentrem nos recursos principais da aplicação.

Confira nossa série "Introdução ao IAM" para mais informações sobre tópicos relacionados ao gerenciamento de identidade e acesso.

Saiba mais