SAML: Um fractal de mau design

Artigo original ↗ Discussão no Hacker News ↗

SAML, o padrão de single sign-on baseado em XML amplamente usado em empresas, é cada vez mais criticado como excessivamente complicado, inseguro e fruto de design por comitê, sendo difícil de implementar corretamente. Os comentários o contrastam com OAuth2/OpenID Connect e JWT, vistos como mais simples e seguros, embora ainda imperfeitos e afetados por seu próprio ecossistema e por incentivos de negócio como o “SSO tax.” Muitos argumentam que, embora o SAML persista por inércia empresarial e IdPs legados, novos produtos deveriam preferir OIDC sempre que possível e tratar SAML como tecnologia legada a ser descontinuada.

Demanda empresarial vs. escolha do fornecedor

  • Muitos argumentam que produtos empresariais precisam oferecer suporte a qualquer SSO que seus clientes usem (muitas vezes SAML); caso contrário, simplesmente não são viáveis.
  • Outros contrapõem que os fornecedores não são obrigados a adotar protocolos que consideram inseguros; perder esses clientes é uma decisão de negócio, não uma obrigação.
  • Alguns fornecedores relatam que migraram para apenas OIDC e, na prática, a maioria dos “clientes SAML” aceitou a mudança porque seus IdPs já suportavam OIDC.
  • Ângulo econômico: recursos de SAML frequentemente ficam atrás de paywall (“SSO tax”), com fornecedores cobrando milhares para “virar a chave”, justificado por custos de suporte e manutenção.

SAML vs OIDC/OAuth2/JWT

  • Há amplo consenso de que SAML é mais complexo e frágil do que OAuth2/OIDC e JWT, embora OAuth2/OIDC/JWT também tenham armadilhas não triviais.
  • Debate sobre se “OAuth2 é uma merda” vem do uso indevido como autenticação em vez de autorização; OIDC é apresentado como a camada adequada de authN.
  • Alguns afirmam que SAML provavelmente sobreviverá ao OIDC por inércia empresarial; outros defendem tratar SAML como um legado obsoleto (por exemplo, IE6) a ser descontinuado.

Armadilhas de segurança e implementação

  • As assinaturas XML de SAML são um foco importante: assinaturas podem cobrir subconjuntos escolhidos pelo atacante, dependem de canonicalização e são vulneráveis a XML Signature Wrapping.
  • Historicamente, muitas implementações validavam uma assinatura e depois confiavam no documento inteiro, ou usavam mal bibliotecas de XML-sig (por exemplo, HMAC com chaves fornecidas pelo atacante, validação WebPKI).
  • Problemas discutidos de JWT/JOSE: alg:none, confusão de algoritmos, mistura de chaves simétricas e assimétricas. Ainda assim, muitos participantes veem os problemas de JWT como menos numerosos e mais fáceis de mitigar do que os de SAML.

Fluxos iniciados por IdP vs. SP

  • Alguns defendem SAML para SSO iniciado pelo IdP e “segurança embutida no payload”, especialmente em cenários de portal empresarial.
  • Outros observam que fluxos iniciados pelo IdP são suscetíveis a login CSRF; o OIDC evita isso intencionalmente, usando em vez disso fluxos iniciados por terceiro que ainda começam no SP.
  • Há divergência sobre se prompts de confirmação ao usuário realmente mitigam tais ataques.

XML, complexidade e design por comitê

  • Vários comentários atribuem os problemas do SAML a XML mais design por comitê: opções demais para assinatura/criptografia e tamanho extremo da especificação.
  • São feitas comparações com OSI vs IP, OpenVPN vs WireGuard e XML vs JSON como exemplos de como projetos mais simples e opinativos funcionam melhor.

Identidade federada, “SSO tax” e alternativas

  • OpenID original, descoberta e registro dinâmicos do OpenID Connect, IndieAuth e DID/FedCM são citados como blocos de construção para identidade independente de provedor.
  • Consenso do thread: incentivos de negócio (acúmulo de dados, upsell de SSO) e não falta de tecnologia impedem o login federado em larga escala.
  • Alguns sugerem que, na prática, inconsistências de SCIM agora consomem mais esforço do que questões de protocolo entre SAML e OIDC.