--- term: 'Single Sign-On (SSO)' seoTitle: 'Single Sign-On (SSO): Como Funciona, SAML vs. OIDC, Riscos' headline: 'O que é Single Sign-On (SSO)?' slug: single-sign-on-sso category: auth-security shortDefinition: '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.' relatedTerms: - identity-access-management-iam - oauth-2-social-login - multi-factor-authentication-mfa - session-management contrastsWith: - oauth-2-social-login aboutTerms: - 'Provedor de Identidade (IdP)' - 'Service Provider (SP)' - 'SAML' - 'Single Logout (SLO)' faq: - question: 'O que é SSO em termos simples?' answer: 'Um login abre muitos apps: você prova quem é uma única vez a um provedor de identidade central, e cada aplicação conectada confia nessa prova em vez de pedir a própria senha. O login da manhã no portal da empresa que abre em silêncio o e-mail, a wiki e o CRM é o SSO em ação.' - question: 'Como o SSO funciona?' answer: 'Por redirects e tokens assinados. O app manda o usuário não autenticado ao provedor de identidade; o usuário se autentica lá — senha mais MFA — e o IdP emite uma asserção assinada digitalmente que o navegador carrega de volta; o app valida a assinatura contra certificados trocados de antemão e inicia uma sessão. O app seguinte pula o login porque a sessão no IdP já existe.' - question: 'SSO é seguro?' answer: 'Saldo positivo quando o provedor de identidade impõe MFA: existem menos senhas para sofrer phishing, e política, auditoria e bloqueio moram em um só lugar. O custo honesto é a concentração — uma conta comprometida no IdP, ou o próprio IdP, abre tudo que está rio abaixo. O SSO torna a porta de entrada excelente e única.' - question: 'Qual a diferença entre SSO e um gerenciador de senhas?' answer: 'O gerenciador de senhas guarda muitos segredos e os preenche — cada app continua rodando o próprio login. O SSO elimina senhas por app: as aplicações delegam a autenticação ao IdP e não guardam credencial nenhuma sua. Os dois se complementam; o gerenciador cobre a cauda longa de apps sem suporte a SSO.' - question: 'Login social é o mesmo que SSO?' answer: 'A mesma maquinaria, outro senhorio. Os dois são fluxos de redirect no estilo OIDC até um provedor de identidade — mas o login social usa o IdP de uma plataforma de consumo para entrar em um único app, enquanto o SSO corporativo usa um IdP controlado pela organização, cuja sessão única atravessa uma suíte inteira de aplicações.' - question: 'SAML ou OIDC para SSO?' answer: 'OIDC para tudo que for novo — JSON e JWTs sobre REST, amigável a mobile e SPAs, mais fácil de implementar e depurar. SAML por compatibilidade — o protocolo da era XML entrincheirado nos provedores de identidade corporativos. Produtos que vendem para empresas normalmente acabam falando os dois.' - question: 'Ainda preciso de MFA com SSO?' answer: 'Enfaticamente, sim — o SSO torna aquele único login mais valioso, não menos. A virtude compensatória: impor MFA no provedor de identidade protege todas as aplicações conectadas em um único movimento, que é exatamente a centralização que o SSO existe para oferecer.' - question: 'O que acontece quando o provedor de identidade sai do ar?' answer: 'Ninguém inicia sessão nova em nenhum app conectado — as sessões locais existentes sobrevivem até expirar. Essa é a face de disponibilidade do ponto único de falha, e a razão pela qual redundância do IdP, contas administrativas de emergência e caminhos alternativos pertencem ao plano de implantação, não ao postmortem.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'SAML 2.0 Technical Overview — OASIS' url: 'https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'NIST SP 800-63C — Federation and Assertions' url: 'https://pages.nist.gov/800-63-3/sp800-63c.html' - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' cta: title: 'Login corporativo a um adaptador de distância' text: 'Aponte os adaptadores de autenticação do Back4app para o provedor de identidade do seu cliente — Keycloak, LDAP ou qualquer emissor OIDC — e o Back4app verifica os tokens no servidor, mapeia identidades para usuários e emite as sessões do seu app.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: 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 | Pergunta | Resposta | | --- | --- | | O elenco | O IdP autentica e avaliza · os SPs confiam no aval | | O mecanismo | Redirects + asserções assinadas — a senha nunca sai do IdP | | Os protocolos | SAML (XML, legado corporativo) · OIDC (JWT sobre OAuth, o padrão moderno) | | O trade-off | Uma porta de entrada excelente — e uma única porta que vale tudo atrás dela | | As letras miúdas | Single logout é difícil · sessões correm em vários relógios · SSO custa caro no SaaS | ## 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: ```text 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:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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. } ``` ```mermaid flowchart LR accTitle: Fluxo de single sign-on entre service providers e o provedor de identidade accDescr: Um usuário não autenticado em um service provider é redirecionado ao provedor de identidade, autentica-se uma vez com MFA e recebe uma asserção assinada entregue de volta ao service provider, que a valida e inicia uma sessão local. Uma segunda aplicação repete o redirect, mas a sessão existente no provedor de identidade torna o login silencioso. U["Usuário"] --> SP1["App A (SP)
sem sessão"] SP1 -->|"redirect + requisição de auth"| IDP["Provedor de identidade
login + MFA · sessão global"] IDP -->|"asserção assinada"| SP1 SP1 -->|"valida → sessão local"| OK1["App A aberto"] U2["Mesmo usuário, depois"] --> SP2["App B (SP)"] SP2 -->|"redirect"| IDP IDP -.->|"sessão existe —
asserção silenciosa"| SP2 --> OK2["App B aberto,
sem tela de login"] ``` ## Iniciado pelo SP vs. iniciado pelo IdP | | Iniciado pelo SP | Iniciado pelo IdP | | --- | --- | --- | | Começa em | No app ("Entrar com SSO") | No tile do painel do IdP | | Requisição | O SP emite uma requisição de autenticação | Nenhuma — a asserção chega sem ser pedida | | Vínculo da resposta | A asserção responde a uma requisição específica | Não há requisição para conferir | | Postura de segurança | O padrão — as checagens de replay se ancoram na requisição | Historicamente mais fraco; asserções não solicitadas convidam injeção | | Suportar? | Sempre | Só onde o IdP exigir, com validação extra | 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](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) especifica os dois perfis; a regra prática está na última linha da tabela. ## SAML vs. OIDC | | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Era e formato | 2005 · asserções XML | 2014 · [JWTs](/glossary/pt/json-web-token-jwt/) sobre [OAuth 2.0](/glossary/pt/oauth-2-login-social/) | | Transporte | Bindings de POST/redirect no navegador | REST + redirects | | Serve para | Apps web corporativos, IdPs legados | Mobile, SPAs, APIs — tudo que é atual | | Experiência de desenvolvimento | Verboso, frágil, dependente de biblioteca | Tokens legíveis, fluxos padronizados | | Veredito | Suporte porque os IdPs dos clientes o falam | Escolha para tudo que for novo | 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](/glossary/pt/autenticacao-vs-autorizacao/)** — 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](/glossary/pt/gerenciamento-de-sessao/) 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](/glossary/pt/autenticacao-multifator-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 | Situação | Tendência | | --- | --- | | Vendendo para empresas | Sim — OIDC + SAML; trava contratos | | Ferramentas internas atrás de um IdP corporativo | Sim — centralize MFA e offboarding | | App de consumo | [Login social](/glossary/pt/oauth-2-login-social/) — mesma maquinaria, IdPs de consumo | | Um app, time pequeno | Sessões + MFA bastam; revisite no terceiro app | | Apps de alta criticidade atrás do SSO | Adicione step-up — não pegue carona na sessão-cobertor | | Escolhendo um protocolo hoje | OIDC primeiro; SAML para os clientes que o exigirem | ## 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](/glossary/pt/oauth-2-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.