O que é Single Sign-On (SSO)?

Single sign-on é um método de autenticação em que um único login no provedor de identidade dá acesso a várias aplicações independentes. O elenco tem dois papéis: o provedor de identidade (IdP) autentica os usuários e responde por eles; cada service provider (SP) — os apps que você de fato quer usar — confia nesse aval em vez de rodar o próprio login. Uma distinção pedante que vale guardar: apps que compartilham um diretório, mas pedem a senha um a um, são same sign-on — o mesmo login, várias vezes; SSO de verdade significa ser perguntado uma única vez.

Principais pontos

A dança de redirects, passo a passo

Por que redirects, afinal? A política de mesma origem do navegador: app.example.com não consegue ler um cookie de login de idp.example.org, então a identidade precisa viajar como uma mensagem assinada através do navegador, e não como um cookie compartilhado — que é exatamente o que o fluxo faz:

1  Usuário abre app.example.com — sem sessão
2  O SP redireciona ao IdP com uma requisição de autenticação
3  O usuário se autentica NO IDP (senha + MFA) — ou já tem
   uma sessão no IdP, e este passo é pulado em silêncio
4  O IdP emite uma asserção assinada (XML SAML) ou um ID token (JWT OIDC)
5  O navegador a entrega na URL de callback do SP
6  O SP valida: assinatura · issuer · audience · expiração · replay
7  O SP inicia a própria sessão local — o usuário está dentro
8  Próximo app: passos 1–2, depois direto do caminho silencioso do 3 ao 7

Como fica o lado do service provider quando um backend o embrulha:

// JavaScript / Node.js — Back4app JS SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
const user = await Parse.User.logInWith('keycloak', {
  authData: {
    id: subClaim,              // the IdP's stable subject ID
    access_token: accessToken, // verified server-side against the IdP
  },
});
// One IdP login now serves every app that trusts the same issuer.

// Flutter / Dart — Back4app Flutter SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
final user = ParseUser.forQuery();
final response = await user.loginWith('keycloak', {
  'id': subClaim,              // the IdP's stable subject ID
  'access_token': accessToken, // verified server-side against the IdP
});
// One IdP login now serves every app that trusts the same issuer.

// iOS / Swift — Back4app Swift SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
let user = try await User.loginWith(
    "keycloak",
    authData: [
        "id": subClaim,              // the IdP's stable subject ID
        "access_token": accessToken  // verified server-side against the IdP
    ]
)
// One IdP login now serves every app that trusts the same issuer.

// Android / Kotlin — Back4app Android SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
val authData = mapOf(
    "id" to subClaim,              // the IdP's stable subject ID
    "access_token" to accessToken  // verified server-side against the IdP
)
ParseUser.logInWithInBackground("keycloak", authData).continueWith { task ->
    val user = task.result
    // One IdP login now serves every app that trusts the same issuer.
}

Iniciado pelo SP vs. iniciado pelo IdP

A maioria dos explicadores descreve apenas o primeiro e nunca nomeia o segundo — mas IdPs corporativos adoram os tiles de painel, então os SPs encontram os dois. O panorama técnico do SAML especifica os dois perfis; a regra prática está na última linha da tabela.

SAML vs. OIDC

E o triângulo que desembaraça as siglas, de uma vez: SAML e OIDC fazem autenticação para SSO; o OAuth 2.0 sozinho é autorização — o OIDC é a camada de identidade que tornou o encanamento do OAuth seguro para login. Login social é a mesma maquinaria OIDC com uma plataforma de consumo como IdP e um único app como audiência; o SSO corporativo troca o senhorio e alarga a sessão para uma suíte.

As partes que ninguém menciona

Single logout (SLO) é a metade difícil. O login converge para dentro de um IdP; o logout precisa se espalhar para fora, até cada SP com sessão local — e a corrente quebra se um app não responder, as restrições de cookies de terceiros dos navegadores quebram as notificações de front-channel, e nada chega aos seus outros dispositivos. Na prática, “deslogado em todo lugar” significa sessões locais curtas que reconferem a sessão (encerrada) do IdP, não um broadcast confiável. As sessões correm em três relógios: a sessão global do IdP, a sessão local de cada app e a janela de validade da própria asserção. Sair de um app enquanto a sessão do IdP vive significa reentrada silenciosa na visita seguinte — comportamento que usuários reportam como bug e que arquitetos deveriam reconhecer como o design. E o imposto do SSO: fornecedores de SaaS rotineiramente trancam o suporte a SAML/SSO atrás de planos enterprise a múltiplos do preço base — um fato de mercado que merece orçamento, já que a exigência do time de segurança e a linha de compras chegam juntas.

O raio de explosão, com honestidade

O SSO concentra risco de propósito — é isso que “single” significa. Uma conta comprometida no IdP abre todos os apps conectados; um IdP comprometido em si — incluindo o roubo das chaves que assinam asserções, o padrão de ataque da “asserção dourada” — cunha identidade válida para qualquer um, em qualquer lugar. Fornecedores suavizam isso; a resposta de engenharia é gastar bem a concentração: MFA resistente a phishing no IdP (o único login agora merece proteção de nível passkey), autenticação step-up para apps sensíveis em vez de uma sessão-cobertor, sessões globais curtas onde o risco é alto, rotação e monitoramento das chaves de assinatura, e contas locais de emergência para o dia em que o IdP cair. O ponto único de falha nunca desaparece — ele é blindado, porque blindar um único ponto é exatamente a economia que o SSO prometeu.

Integrando como service provider

O que “nós suportamos SSO” exige de verdade de um time de produto, em uma lista: registre sua URL de callback/ACS no IdP e troque metadados (issuer, certificados); valide tudo em toda asserção — assinatura, issuer, audience, expiração e vínculo anti-replay; mapeie os claims do IdP para o seu modelo de usuário, ancorado no subject estável, nunca no e-mail sozinho; provisione just-in-time (o primeiro login via SSO cria o usuário local); trate chegadas iniciadas pelo IdP deliberadamente; e teste as expectativas de logout contra a realidade dos três relógios acima. É um caminho bem trilhado — por isso IdPs open-source como o Keycloak existem para o outro lado do aperto de mão — mas cada item pulado é um achado de segurança com data marcada.

Casos de uso comuns

• Suítes de apps corporativos — o caso canônico: um login pela manhã, todas as ferramentas internas e SaaS depois.
• SaaS B2B subindo de mercado — “suporta SSO” como o checkbox que trava ou destrava o contrato enterprise.
• Educação e saúde — acesso federado entre instituições, onde as raízes do SAML são mais profundas.
• MFA e offboarding centralizados — um lugar para impor fatores; um interruptor que encerra em todo lugar o acesso do funcionário que saiu.
• Produtos multi-app — a sua própria suíte compartilhando um login via o seu próprio IdP, ao estilo consumidor.

Você deveria adotar SSO? Matriz de decisão

Limitações e trade-offs

• A disponibilidade se concentra junto com a identidade. A queda do IdP é a queda do login de todo mundo; redundância e caminhos de emergência fazem parte do recurso, não são adições a ele.
• O logout é mais fraco que o login. O fan-out do SLO falha parcialmente por design; sessões locais curtas, não broadcasts de logout, entregam a garantia real.
• A cauda longa continua com senha. Apps sem suporte a SSO mantêm as próprias credenciais — gerenciadores de senha seguem como a camada de rescaldo.
• As camadas de sessão confundem usuários. Relogin silencioso e tickets de “saí, mas não saí” são a conta de UX do design de três relógios; documentação e timeouts previsíveis a amortizam.
• A qualidade de integração varia por SP. O teto de segurança do SSO é definido pela validação de asserção mais desleixada entre os apps conectados — a lista acima é por app, para sempre.

SSO no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Um app aqui entra em um parque de SSO como service provider pelo mesmo mecanismo de adaptadores que move o login social: o Back4app traz adaptadores de autenticação para Keycloak, LDAP e emissores OAuth2/OIDC genéricos, então o fluxo das abas de código — o IdP autentica, o app recebe tokens, o logInWith os verifica no servidor junto ao emissor — transforma SSO corporativo em configuração mais um handler de redirect. As identidades se ancoram no subject estável do IdP em blocos authData por provedor, o primeiro login provisiona o usuário just-in-time, o linkWith acopla métodos adicionais para o caminho de emergência, e a sessão que o seu app emite continua sendo uma sessão Parse revogável — de modo que a pilha de três relógios termina, do seu lado, com um relógio que você controla por completo.