SAML vs OIDC: qual protocolo de logon único escolher

SAML vs OIDC é a escolha de protocolo por trás do logon único. No SAML 2.0 (padrão OASIS, março de 2005), um provedor de identidade assina uma asserção XML sobre o usuário, e o navegador a leva até o provedor de serviços. O OpenID Connect (Core 1.0, fevereiro de 2014, também ISO/IEC 26131:2024) acrescenta uma camada de identidade ao OAuth 2.0: o provedor emite um JWT assinado, o token de ID, normalmente pelo fluxo de código de autorização, e pode emitir tokens de acesso para APIs na mesma troca.

Visão geral

Como cada um faz o login do usuário

No SAML, o provedor de serviços redireciona o navegador para o provedor de identidade com um AuthnRequest. Depois do login, o IdP retorna um formulário HTML que envia por POST uma Response codificada em base64 com a asserção: emissor, titular, restrição de público-alvo, janela de validade, atributos e uma assinatura XML. O provedor de serviços verifica a assinatura com o certificado dos metadados do IdP e confere as condições.

No OpenID Connect, o cliente redireciona para o endpoint de autorização do provedor com scope=openid, um state, um nonce e um desafio PKCE. O provedor retorna um código de uso único para a URI de redirecionamento; o cliente o troca no endpoint de token pelo token de ID e pelo token de acesso por meio de uma conexão TLS direta, de modo que os tokens nunca passam pela barra de endereços do navegador.

O script abaixo lê os dois tipos de configuração do mesmo provedor (20 de outubro de 2026, curl e jq 1.8.1). Em requisições repetidas, o tamanho dos metadados SAML variou entre 28 e 32 KB e o JWKS entre 7 e 8 chaves, conforme servidores diferentes respondiam.

#!/bin/sh
base=https://login.microsoftonline.com/common
echo "== OpenID Connect discovery"
curl -s "$base/v2.0/.well-known/openid-configuration" -o oidc.json
echo "bytes: $(wc -c < oidc.json | tr -d ' ')"
jq -c '{id_token_signing_alg_values_supported, response_types_supported}' oidc.json
curl -s "$(jq -r .jwks_uri oidc.json)" | jq -c '{jwks_keys: (.keys | length), kty: ([.keys[].kty] | unique)}'

echo "== SAML 2.0 metadata"
curl -s "$base/FederationMetadata/2007-06/FederationMetadata.xml" -o saml.xml
echo "bytes: $(wc -c < saml.xml | tr -d ' ')"
grep -o 'SignatureMethod Algorithm="[^"]*"' saml.xml | sort -u
grep -o 'SingleSignOnService Binding="[^"]*"' saml.xml | sort -u
echo "distinct certificates: $(grep -o '<X509Certificate>[^<]*' saml.xml | sort -u | wc -l | tr -d ' ')"
rm -f oidc.json saml.xml

== OpenID Connect discovery
bytes: 1728
{"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"]}
{"jwks_keys":7,"kty":["RSA"]}
== SAML 2.0 metadata
bytes: 28179
SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
distinct certificates: 5

O que a parte confiável deve verificar

SAML: verifique a assinatura XML com o certificado do IdP que você configurou (nunca com um certificado embutido na mensagem) e confirme que a assinatura cobre exatamente a asserção que seu código lê; depois confira Issuer, Destination, InResponseTo, AudienceRestriction, NotBefore e NotOnOrAfter e rejeite repetições (replay). A dificuldade é estrutural. A XML Signature assina elementos referenciados por ID depois da canonicalização, então um documento pode conter um elemento com assinatura válida e outro, diferente e não assinado, que a aplicação processa no lugar dele. Em 2012, Somorovsky e colegas demonstraram esse signature wrapping em 11 de 14 frameworks SAML; em 2024 e 2025, o ruby-saml (usado pelo GitLab) precisou de correções novamente (CVE-2024-45409, CVE-2025-25291 e CVE-2025-25292) porque dois parsers XML da mesma biblioteca liam o mesmo documento de formas diferentes.

OpenID Connect (Core §3.1.3.7): verifique o JWS com uma chave do JWKS do provedor, selecionada pelo kid, e com o algoritmo que você espera; depois confira iss, aud (o ID do seu cliente), exp, iat e o nonce que você enviou. O JSON tem uma única árvore de análise e a assinatura cobre exatamente os bytes recebidos, então o problema de wrapping não existe; as armadilhas que restam são aceitar algoritmos inesperados, pular a verificação de aud e comparar URIs de redirecionamento de forma frouxa, problemas tratados pelas melhores práticas atuais de segurança do OAuth (RFC 9700, janeiro de 2025). O validador de tokens OIDC executa essas verificações com o JWKS atual de um provedor, e o inspetor de SAML mostra qual elemento uma assinatura cobre de fato.

Quando escolher cada um

• Novas aplicações, aplicativos móveis, aplicações de página única, APIs: OpenID Connect com o fluxo de código e PKCE.
• Venda de SaaS para empresas: ofereça suporte aos dois; as equipes de identidade de muitos clientes ainda configuram o SAML primeiro.
• Federações de pesquisa e ensino (eduGAIN, InCommon): SAML, com agregados de metadados; o OpenID Federation 1.0 (final desde fevereiro de 2026) está em piloto no eduGAIN, mas ainda não é a norma.
• Governo e setores regulados: siga o perfil que seu ecossistema exige; o open banking e regimes semelhantes usam o FAPI 2.0, um perfil reforçado de OAuth e OpenID Connect.
• Provisionamento de usuários e grupos: nenhum dos dois; use o SCIM 2.0 (RFC 7643 e RFC 7644) junto com qualquer um dos protocolos.

Notas de migração

1. Rode os dois em paralelo: configure uma aplicação OIDC no mesmo provedor de identidade e mapeie o mesmo identificador de usuário (sub ou um atributo estável) para as contas existentes antes de fazer a troca.
2. Mapeie atributos para claims explicitamente; os nomes de atributos SAML (muitas vezes URNs) raramente coincidem com os nomes das claims OIDC, e as claims de grupo podem exigir uma chamada de API separada quando os usuários pertencem a muitos grupos.
3. Use uma biblioteca certificada para OpenID Connect, ative a descoberta e o cache do JWKS com atualização quando aparecer um kid desconhecido e fixe os algoritmos aceitos.
4. Reforce o que continuar no SAML: atualize a biblioteca, exija asserções assinadas, rejeite documentos com várias asserções ou com DTDs e monitore a expiração dos certificados nos metadados dos parceiros.
5. Planeje o logout separadamente: mapeie o Single Logout do SAML para o Back-Channel Logout do OIDC onde as sessões precisarem ser encerradas de forma centralizada.
6. Desative a conexão SAML só depois que os logs não mostrarem nenhum login SAML durante um ciclo de negócios completo.

Referências

• OASIS SAML 2.0 Core e Bindings
• OpenID Connect Core 1.0 (§3.1.3.7, validação do token de ID)
• OpenID Connect Discovery 1.0
• OpenID Connect Back-Channel Logout 1.0
• RFC 9700, melhores práticas atuais de segurança do OAuth 2.0
• RFC 7636, PKCE e RFC 8252, OAuth para aplicativos nativos
• XML Signature Syntax and Processing 1.1 do W3C
• Somorovsky et al., On Breaking SAML, artigo no USENIX Security 2012