SAML

SAML (Security Assertion Markup Language) é um padrão de single sign-on (SSO) baseado em XML publicado pela OASIS em 2005. Muito usado em integrações B2B empresariais — Okta, Ping Identity, Microsoft AD FS, Google Workspace, todo SaaS que vende para grandes empresas.

O modelo: um Provedor de Identidade (IdP, por exemplo, Okta) autentica o usuário. O usuário chega a um Provedor de Serviços (SP, por exemplo, Salesforce) com uma asserção SAML assinada provando quem ele é. O SP verifica a assinatura contra a chave pública do IdP e confia na afirmação.

SAML vs OAuth2/OIDC: SAML é mais antigo, baseado em XML, projetado para SSO empresarial. OAuth/OIDC são baseados em JSON, projetados originalmente para autorização delegada (“permitir que este aplicativo leia meu Gmail”) e posteriormente estendidos para autenticação (OIDC). Novas integrações empresariais usam cada vez mais OIDC; SaaS empresariais existentes frequentemente ainda exigem SAML porque os IdPs dos clientes o exigem.

A especificação de assinatura XML que o SAML usa é notoriamente propensa a erros — ataques de empacotamento de assinatura XML existem em muitas implementações. Bibliotecas modernas (por exemplo, python-saml, as da OneLogin) lidam com isso corretamente por padrão; implementar o seu próprio é uma má ideia.

Bindings SAML — como a asserção é transportada: o SAML define vários bindings de transporte. O HTTP Redirect comprime e codifica em base64 a requisição em uma string de consulta de URL (limitada pelo comprimento da URL do navegador); o HTTP POST envia um blob codificado em base64 em um formulário enviado automaticamente via JavaScript (o mais comum em 2026); o HTTP Artifact passa um token de referência curto que o SP troca fora de banda pela asserção completa. O POST é o padrão moderno porque lida com tamanhos de asserção que confortavelmente ultrapassam os limites de URL e evita vazar a asserção em logs de proxy. A própria asserção é encapsulada em base64 e assinada com SHA-256.

Problemas operacionais em implantações SAML empresariais: desvio de relógio entre IdP e SP (as asserções têm uma janela de validade de 5 minutos por padrão — uma hora de servidor mal configurada quebra o login para todos), rotação de certificados (o certificado de assinatura do IdP expira a cada 1-3 anos e deve ser rotacionado antes dessa data ou todo o SSO falha simultaneamente) e incompatibilidades de formato NameID (o IdP emite emailAddress mas o SP espera IDs opacos persistent). A história clássica de guerra empresarial é uma interrupção de SSO numa segunda-feira de manhã porque o certificado do IdP expirou silenciosamente no domingo à noite e ninguém era responsável pela renovação. Referência: Especificação OASIS SAML 2.0 Core.

Exemplo prático

Um funcionário clica em “Entrar com SSO da empresa” em app.example.com. O SP (Provedor de Serviços) gera um documento XML <AuthnRequest> SAML e faz um POST para o IdP em sso.acme.com/saml. O IdP autentica o usuário (provavelmente via senha + WebAuthn) e retorna uma <Response> SAML contendo uma <Assertion> com: o e-mail do usuário (NameID), associações de grupo (AttributeStatement), janela de validade (NotBefore / NotOnOrAfter ~5 minutos) e restrição de audiência (deve ser exatamente app.example.com). O XML é assinado com a chave RSA-2048 do IdP usando SHA-256. O navegador envia automaticamente via POST esse blob codificado em base64 de volta para app.example.com/saml/acs. O SP verifica a assinatura contra o certificado público pré-compartilhado do IdP, verifica a janela de validade e a audiência, extrai o e-mail e cria uma sessão local. Toda a troca são dois redirecionamentos HTTP e é invisível para o usuário além da tela de login do IdP.

Quando e por que isso importa

Se você vende SaaS B2B, o suporte a SAML é o recurso determinante para vendas empresariais — a maioria das empresas acima de 500 funcionários exige que todo acesso a SaaS passe pelo IdP delas para controle de desligamento (quando um funcionário sai, o IdP revoga a sessão e eles perdem acesso a todos os SaaS conectados de uma vez). Incidentes de segurança modernos em fornecedores de SaaS (Okta 2022, Cloudflare 2023) rastreiam a camada SAML ou de token de sessão em vez de senhas especificamente porque SSO é a credencial de registro. A lista de verificação defensiva para qualquer implementação SAML: validar a assinatura em cada asserção (não apenas o invólucro de resposta), validar InResponseTo para evitar replay, validar audiência e destinatário, aplicar a janela de tempo estritamente e armazenar a impressão digital do certificado do IdP fora de banda para que uma URL de metadados comprometida não possa silenciosamente trocar a chave confiável. Referência: OWASP SAML Security Cheat Sheet.