Resumo rápido
Comparar "SSO vs SAML vs OIDC" mistura dois tipos de coisa. SSO é um conceito de experiência: autentique uma vez no IdP, acesse várias aplicações sem login adicional. SAML e OIDC são protocolos que implementam esse conceito — você sempre escolhe entre os dois (ou usa os dois) para entregar SSO. SAML é o veterano em empresarial; OIDC é o padrão moderno para apps novas, mobile e APIs.
SSO
Conceito de experiência. "Uma identidade, várias aplicações". Pode ser implementado via SAML, OIDC, Kerberos ou (legacy) cookies compartilhados.
SAML 2.0
Protocolo de federação baseado em XML, padrão OASIS (2005). Troca de assertions assinadas via redirect HTTP POST/Redirect entre IdP e SP.
OIDC
OpenID Connect — camada de identidade sobre OAuth 2.0. JSON Web Tokens (JWT), endpoints REST, ideal para apps modernas, mobile e APIs.
| Critério | SSO (conceito) | SAML 2.0 | OIDC |
|---|---|---|---|
| Natureza | Conceito de experiência | Protocolo | Protocolo |
| Padronizado por | — | OASIS (2005) | OpenID Foundation (2014, sobre OAuth 2.0) |
| Formato do token | — | XML (SAML Assertion) | JWT (JSON Web Token) |
| Tamanho típico | — | Grande (KB) | Pequeno (centenas de bytes) |
| Trânsito | — | Browser (Redirect/POST) | Browser + back-channel REST |
| Adequado para apps web tradicionais | — | Sim | Sim |
| Adequado para mobile/SPA | — | Não (lento, complexo) | Sim (PKCE) |
| Adequado para API/microservices | — | Não | Sim |
| Suporte em SaaS enterprise legacy | — | Excelente | Crescente |
| Logout federado (SLO) | — | Sim (mas instável) | Back-channel logout (parcial) |
| Identidade federada cross-org | Sim | Excelente | Excelente |
| Curva de aprendizado | — | Alta (XML, XMLDSig) | Média |
| Ataques clássicos | Token reuse, session fixation | XSW, XXE, Golden SAML, replay | Mix-up, CSRF, alg=none, redirect |
| Mitigações chave | MFA, gestão de sessão | Validar escopo de assinatura, audience, NotOnOrAfter | PKCE, state, nonce, validar iss/aud/exp |
| Suporta refresh sem reautenticar | Depende | Não nativo | Sim (refresh token) |
| Substitui MFA | Não | Não | Não |
| Compatível com WebAuthn/Passkeys | Sim (no IdP) | Sim (no IdP) | Sim (no IdP) |
| Onde brilha | Experiência unificada | SaaS enterprise legacy, federação B2B | Apps modernas, mobile, APIs, B2C |
Como decidir
- "Devo fazer SSO?": sim, é higiene básica moderna. A pergunta real é "qual protocolo?".
- Aplicação SaaS enterprise legada (Workday, ServiceNow, SAP, Salesforce): SAML, sem hesitar — é o protocolo nativo desses ecossistemas.
- Aplicação web nova ou em modernização: OIDC, especialmente se tiver mobile, SPA ou APIs envolvidas.
- Mobile-first ou SPA: OIDC com PKCE. SAML em mobile é quase sempre um erro.
- Federação B2B com outras organizações: SAML ainda é mais bem suportado em interop corporativa.
- Identidade de cliente (B2C, milhões de usuários): OIDC, com IdPs como Auth0, Okta CIC, Microsoft Entra External ID.
- O IdP corporativo já suporta os dois (Entra ID, Okta, Ping, Keycloak): escolha pelo que a aplicação fala melhor — não há ganho em forçar um lado.
Aprofunde nos conceitos
- Passwordless, Passkeys e FIDO2
- MFA — tipos, fatores e ataques comuns
- ITDR — Detecção de ameaças de identidade
- Zero Trust Architecture
- Ferramenta: Decoder e analisador de JWT
Perguntas frequentes
SSO e SAML são a mesma coisa?
Não. SSO é um conceito de experiência: "autentique uma vez, acesse várias aplicações". SAML e OIDC são protocolos que implementam SSO entre um Identity Provider (IdP) e um Service Provider (SP). Você pode ter SSO via SAML, OIDC ou Kerberos. Confundir os três é a maior fonte de erro arquitetural em projetos de identidade.
Quando usar SAML e quando usar OIDC?
SAML domina aplicações empresariais legadas (Workday, Salesforce, ServiceNow), VPNs e SaaS B2B mais antigos. OIDC é o padrão moderno para aplicações novas, mobile, SPAs e APIs — JWT, construído sobre OAuth 2.0. Se está começando hoje e a aplicação suporta os dois, prefira OIDC; se só fala SAML, use SAML.
OAuth 2.0 é SSO?
Não. OAuth 2.0 é autorização delegada (acesso a recursos em nome do usuário), não autenticação. Usar OAuth como SSO é um anti-padrão clássico que leva a vulnerabilidades. OIDC é a camada de autenticação sobre OAuth — o ID Token transmite identidade; o Access Token segue sendo OAuth puro para chamar APIs.
Quais são os ataques clássicos contra SAML?
XML Signature Wrapping (XSW), replay sem NotBefore/NotOnOrAfter, assinatura faltando em assertions críticas, XXE em parsers, Golden SAML (quando IdP é comprometido). Mitigação: validar assinatura no escopo correto, exigir Conditions, restringir audience, exigir signed assertions.
E contra OIDC?
Mix-up Attack, CSRF sem state, open redirect no redirect_uri, JWT com alg=none, algorithm confusion (HMAC trocado por RSA), PKCE faltando em clients públicos, ID Token usado como Access Token. Mitigação: PKCE em tudo, state + nonce obrigatórios, validar iss/aud/exp/sub/azp, allow-list exata de redirect_uris.
Onde se encaixam WebAuthn/Passkeys?
Substituem o mecanismo de autenticação primária (senha+MFA) por chaves criptográficas no dispositivo, resistentes a phishing. Não substituem SSO — o IdP continua emitindo SAML/OIDC para as aplicações; o login no próprio IdP é que passa a usar passkey em vez de senha+TOTP.
Arquitetura de identidade e SSO
Desenhamos sua federação de identidade, escolha SAML/OIDC por aplicação, hardening do IdP e roadmap para passwordless.
Falar com Especialista