Single Sign-On (SSO) e federação de identidade são a base do controle de acesso moderno: um usuário autentica uma única vez em um Identity Provider (IdP) e acessa dezenas de aplicações sem reinserir credenciais. Quando bem implementado, o SSO reduz senhas fracas reutilizadas, centraliza o ponto de aplicação de MFA e simplifica auditoria. Quando mal configurado, concentra o risco em um único nó crítico. Este guia cobre os dois protocolos dominantes — SAML 2.0 e OIDC — seus fluxos, diferenças, IdPs do mercado, provisioning via SCIM, ataques conhecidos e a relação com Zero Trust.

O que é federação de identidade

Federação de identidade é o conjunto de acordos, padrões e tecnologias que permitem que sistemas de domínios distintos compartilhem informações de autenticação de forma segura e verificável. Em vez de cada aplicação manter seu próprio banco de usuários e lógica de login, ela confia em uma declaração emitida por um terceiro de confiança — o Identity Provider. O Service Provider (SP) valida a declaração criptograficamente e concede acesso sem precisar conhecer a senha do usuário.

A federação resolve três problemas práticos: elimina a proliferação de credenciais (um usuário em 40 SaaS tem 40 senhas distintas); habilita o ciclo de vida centralizado (desligar um colaborador no IdP revoga acesso a todos os sistemas federados); e permite aplicar políticas de segurança — MFA, device posture, geolocalização — em um único ponto antes de qualquer acesso ser concedido.

SAML 2.0: assertions XML para o enterprise

O Security Assertion Markup Language 2.0, padronizado pelo consórcio OASIS em 2005 (especificação SAML Core 2.0), define um protocolo de troca de assertions XML entre Identity Provider e Service Provider. Uma assertion SAML é um documento XML assinado digitalmente que declara quem é o usuário (Authentication Statement), quais atributos ele possui (Attribute Statement) e o que ele está autorizado a fazer (Authorization Decision Statement).

Papéis no SAML

  • Identity Provider (IdP): autentica o usuário e emite a assertion assinada com sua chave privada. Exemplos: Microsoft Entra ID (antigo Azure AD), Okta, Keycloak, Google Workspace, PingFederate.
  • Service Provider (SP): recebe a assertion, valida a assinatura com o certificado público do IdP e concede acesso. Exemplos: Salesforce, AWS Console, Jira, qualquer aplicação configurada para SAML.
  • Principal: o usuário que inicia o fluxo de autenticação.

Fluxo SP-Initiated (mais comum)

  1. O usuário acessa a URL protegida no Service Provider.
  2. O SP detecta que o usuário não está autenticado e gera um AuthnRequest XML, codificado em Base64 e enviado via redirecionamento HTTP para o IdP.
  3. O IdP autentica o usuário (senha + MFA) e emite uma Response XML contendo a assertion assinada.
  4. O IdP envia a Response via POST para a Assertion Consumer Service URL (ACS URL) do SP.
  5. O SP valida a assinatura, verifica a validade temporal (NotBefore/NotOnOrAfter), extrai os atributos e cria a sessão do usuário.

No fluxo IdP-Initiated, o usuário parte do portal do IdP e o SP recebe a assertion sem ter gerado um AuthnRequest — o que aumenta o risco de ataques de replay e deve ser evitado ou fortemente monitorado.

OIDC e OAuth 2.0: tokens JWT para o mundo moderno

OpenID Connect (OIDC) é uma camada de identidade sobre o OAuth 2.0, publicada pela OpenID Foundation em 2014. Onde OAuth 2.0 define um framework de autorização (delegação de acesso), OIDC adiciona autenticação por meio do ID Token — um JWT (JSON Web Token) assinado que contém claims sobre o usuário autenticado.

Tokens no OIDC

  • ID Token: JWT assinado pelo IdP que prova quem é o usuário. Contém claims padrão: sub (identificador único), email, name, iss (emissor), aud (audiência), exp (expiração).
  • Access Token: token opaco ou JWT usado para acessar recursos protegidos (APIs). Tem vida curta.
  • Refresh Token: token de longa duração usado para obter novos Access Tokens sem reautenticar o usuário.

Authorization Code Flow com PKCE

O fluxo recomendado para aplicações web e mobile é o Authorization Code Flow com Proof Key for Code Exchange (PKCE, RFC 7636). O cliente gera um code_verifier aleatório e envia seu hash (code_challenge) na requisição de autorização. O servidor de autorização retorna um code de curta duração; o cliente troca esse code pelo token apresentando o code_verifier original. Isso impede ataques de intercepção do code mesmo em canais não totalmente seguros.

Comparativo SAML 2.0 vs OIDC

Dimensão SAML 2.0 OIDC / OAuth 2.0
Formato do token XML (assertion assinada) JWT (JSON, compacto)
Transporte HTTP Redirect / POST (browser) HTTP (browser, API, mobile)
Aplicações-alvo Web enterprise, legado, SaaS B2B SPAs, mobile, microsserviços, APIs
Complexidade de implementação Alta (XML, certificados, metadata) Moderada (JSON, bibliotecas maduras)
Suporte a autorização Limitado (Authorization Decision) Nativo via OAuth 2.0 scopes
Logout único (SLO) Suportado (SAML SLO profile) Parcial (Front-Channel Logout, OIDC Back-Channel)
Ecossistema Salesforce, AWS, SAP, legados Google, GitHub, AWS Cognito, Stripe
Padrão de referência OASIS SAML 2.0 (2005) OpenID Foundation OIDC Core 1.0 (2014)

Identity Providers do mercado

Microsoft Entra ID (Azure AD): dominante em ambientes Microsoft 365. Suporta SAML 2.0, OIDC, WS-Federation e SCIM. Oferece Conditional Access (políticas baseadas em risco, localização, dispositivo) e integração nativa com Windows Hello for Business.

Okta Workforce Identity: IdP agnóstico de stack com catálogo de milhares de integrações pré-construídas (OIN). Forte em just-in-time provisioning, Adaptive MFA e Universal Directory. Referência para organizações multi-cloud.

Keycloak: IdP open source mantido pela Red Hat, ideal para ambientes on-premises ou nuvem privada. Suporta SAML 2.0, OIDC, LDAP/AD como federation source e permite customização profunda via temas e extensões Java.

Google Workspace: IdP integrado para organizações Google-first. Suporta SAML 2.0 com apps de terceiros e OIDC nativo para aplicações Google. Contexto Aware Access permite políticas baseadas em dispositivo.

SCIM: provisionamento automático do ciclo de vida

System for Cross-domain Identity Management (SCIM 2.0, RFC 7642–7644) é um protocolo REST + JSON para sincronizar diretórios de identidade. Quando o RH admite ou desliga um colaborador no sistema de origem (Workday, SuccessFactors, o próprio AD), o IdP propaga essa mudança via SCIM para todos os Service Providers conectados: cria conta, atualiza grupos, suspende ou remove — em minutos, não dias.

SCIM elimina duas das maiores falhas de segurança em IAM corporativo: contas órfãs de ex-colaboradores que permanecem ativas semanas após o desligamento, e provisionamento manual com permissões excessivas por falta de template correto. A implementação exige que o SP suporte o endpoint SCIM (maioria dos SaaS modernos suporta) e que o IdP tenha o conector configurado com o token de autenticação do SP.

JIT Provisioning

Just-in-Time (JIT) provisioning cria a conta do usuário no Service Provider no momento do primeiro login SSO bem-sucedido, usando os atributos da assertion SAML ou do ID Token OIDC. É uma alternativa ao SCIM para SPs que não suportam o protocolo de provisionamento ou para organizações com base de usuários externa (parceiros, clientes B2B). A desvantagem é que o JIT não remove contas automaticamente: o desligamento no IdP impede futuros logins, mas a conta no SP permanece existindo até ser removida manualmente ou por cron.

Riscos e ataques conhecidos

Golden SAML

Se um atacante compromete a chave privada do IdP — obtida via dump de memória do AD FS, acesso ao servidor do Okta ou export indevido do Keycloak — ele pode forjar assertions SAML válidas para qualquer usuário, incluindo administradores, sem precisar de senha ou MFA. O ataque foi documentado publicamente em campanhas APT (Solorigate/SolarWinds). Contramedidas: armazenar chaves em HSM dedicado ou Azure Key Vault/AWS KMS; monitorar exports de certificado; alertar para assertions com atributos de administrador emitidas fora do horário comercial.

OIDC Misconfiguration: Redirect URI Abuse

Registrar Redirect URIs com wildcard (https://app.com/*) ou aceitar URIs arbitrárias permite que um atacante redirecione o Authorization Code para um endpoint sob seu controle e troque-o por tokens. Regra: Redirect URIs devem ser exatas e revisadas periodicamente. Remover URIs de aplicações descontinuadas é frequentemente negligenciado.

Token Replay e ausência de validação de audience

JWTs sem validação rigorosa do claim aud (audiência) podem ser aceitos por SPs que não eram o destinatário original. Assertions SAML sem verificação do NotOnOrAfter permitem replay de tokens capturados. Toda implementação de SP deve validar: assinatura, emissor (iss), audiência (aud), validade temporal e — para SAML — o InResponseTo correspondente ao AuthnRequest original.

Falta de MFA no IdP

SSO sem MFA centraliza o risco em uma senha. A comprometimento de uma credencial do IdP equivale ao comprometimento de todos os sistemas federados. MFA deve ser obrigatório no IdP para todos os usuários, com exceção de nenhuma. Políticas de Adaptive MFA (exigir segundo fator apenas em contextos de risco elevado) são um complemento, não um substituto.

Boas práticas de implementação

  • Habilitar assinatura de assertions e, quando possível, criptografia do assertion SAML (EncryptedAssertion) para dados sensíveis.
  • Configurar tempo de vida de sessão do IdP compatível com a política de segurança: sessões longas convenientes são sessões de risco elevado em dispositivos compartilhados.
  • Implementar Single Logout (SLO) para que o logout em um SP propague o encerramento de sessão no IdP e nos demais SPs.
  • Manter inventário atualizado de todos os Service Providers registrados no IdP; remover integrações inativas.
  • Monitorar logs de autenticação do IdP no SIEM: padrões de logins simultâneos em locais distintos, assertions emitidas fora do horário esperado, falhas de validação de assinatura repetidas.
  • Rodar os certificados SAML antes da expiração; testar a rotação em homologação para evitar interrupção em produção.
  • Não expor o metadata XML do IdP publicamente sem necessidade; ele contém informações de endpoint e certificado úteis para reconhecimento.

SSO e Zero Trust

O modelo Zero Trust (NIST SP 800-207) pressupõe que nenhuma rede é confiável e que cada requisição de acesso deve ser verificada explicitamente com base em identidade, postura do dispositivo e contexto. SSO e federação são pilares desse modelo: sem identidade federada forte, não há como aplicar políticas granulares por recurso. O fluxo Zero Trust estende o SSO com verificações adicionais: o IdP avalia se o dispositivo está gerenciado (MDM), se o endpoint de segurança está ativo, se a sessão vem de um IP ou localização esperada — e só então emite o token com os scopes adequados.

Soluções como Cloudflare Access, Zscaler Private Access e Microsoft Entra Private Access funcionam como proxies de identidade na frente de aplicações internas, substituindo VPNs tradicionais: o usuário autentica via OIDC no IdP, o proxy valida o token e as políticas de contexto, e só então encaminha a conexão para o recurso interno. Aplicações legadas sem suporte a SAML ou OIDC são protegidas sem modificação de código.

Referências normativas e técnicas

  • OASIS SAML 2.0 Core Specification (2005) — docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
  • OpenID Connect Core 1.0 — openid.net/specs/openid-connect-core-1_0.html
  • OAuth 2.0 Authorization Framework — RFC 6749 (IETF)
  • PKCE — RFC 7636 (IETF)
  • SCIM 2.0 — RFC 7642, 7643, 7644 (IETF)
  • NIST Special Publication 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
  • NIST SP 800-207 — Zero Trust Architecture

Perguntas frequentes

Qual a diferença entre SAML 2.0 e OIDC?

SAML 2.0 troca assertions XML entre Identity Provider e Service Provider, sendo dominante em aplicações corporativas legadas e web SSO. OIDC usa tokens JWT sobre OAuth 2.0 e é a escolha natural para aplicações modernas, APIs, mobile e SPAs. A decisão depende do stack da aplicação: SAML para sistemas enterprise tradicionais; OIDC para microsserviços e cloud-native.

SSO reduz ou aumenta a superfície de ataque?

SSO concentra o vetor de autenticação em um único ponto, o que simplifica monitoramento e permite políticas uniformes de MFA e sessão. O risco aumenta apenas se o Identity Provider for comprometido ou mal configurado — por isso exige proteção reforçada do IdP, MFA obrigatório, rotação de certificados e monitoramento de assertions suspeitas.

O que é o ataque golden SAML e como preveni-lo?

Golden SAML ocorre quando um atacante obtém a chave privada do Identity Provider e forja assertions SAML válidas para qualquer usuário sem precisar de credenciais. A prevenção exige: guardar chaves privadas do IdP em HSM ou cofre de segredos, monitorar logins com atributos incomuns, habilitar verificação de assinatura no SP e revisar periodicamente certificados ativos.

O que é JIT provisioning e quando devo usá-lo?

Just-in-Time provisioning cria automaticamente a conta do usuário no Service Provider no momento do primeiro login bem-sucedido via SSO. É útil quando a base de usuários muda com frequência (terceiros, parceiros). Para controle mais granular do ciclo de vida — desativação imediata, grupos dinâmicos — prefira SCIM, que atualiza contas em tempo real via API REST.

Posso usar SSO com aplicações que não suportam SAML nem OIDC?

Sim. Soluções como Cloudflare Access ou proxies de autenticação funcionam como cabeçalho de identidade na frente da aplicação legada, inserindo headers como X-User ou X-Email após autenticação federada. O aplicativo não precisa implementar protocolo nenhum. Essa abordagem é compatível com o modelo Zero Trust: o proxy verifica identidade e postura do dispositivo antes de rotear a requisição.

SCIM substitui SAML ou OIDC?

Não. SAML e OIDC são protocolos de autenticação; SCIM (RFC 7642–7644) é um protocolo de provisionamento. Eles se complementam: SAML ou OIDC autentica o usuário, SCIM sincroniza o diretório — cria, atualiza e remove contas e grupos no destino de forma automática quando o RH altera o registro no IdP.

Como a Decripte implementa SSO e federação

A Decripte projeta e implementa arquiteturas de identidade federada para organizações de 1 a mais de 100.000 colaboradores. O escopo inclui seleção e configuração de Identity Provider (Entra ID, Okta, Keycloak), integração SAML 2.0 e OIDC com o portfólio de aplicações da empresa, provisionamento automatizado via SCIM, políticas de MFA obrigatório, monitoramento de eventos de autenticação no SIEM e treinamento de equipes de TI. O resultado é uma postura de identidade auditável, escalável e alinhada ao NIST 800-63 e ao modelo Zero Trust.

Empresas que ainda operam com senhas locais em cada sistema, sem visibilidade centralizada de quem acessa o quê, estão expostas a riscos que o SSO bem configurado elimina de forma direta e mensurável. Comece pelo plano gratuito de Gestão de Ameaças para ter um diagnóstico da sua postura atual, ou conheça os planos da Decripte para implementação completa de IAM com SSO, MFA e Zero Trust.