OIDC ou SAML: de qual você realmente precisa

Toda equipe que constrói software B2B se depara com a mesma bifurcação na primeira vez que um cliente sério diz "precisamos de SSO". Duas siglas, OIDC e SAML, ambas alegando ser a resposta, e uma internet repleta de tabelas comparativas que dizem que SAML é "corporativo" e OIDC é "moderno" e deixam você exatamente tão empacado quanto antes. Aqui está a versão que de fato ajuda você a entregar.

O que são

SAML é de 2005 e é XML. Um provedor de identidade assina uma asserção ("esta é a alice@bigco.com, aqui estão os grupos dela") e a envia para o seu app, que verifica a assinatura e faz o login dela. Foi criado para o navegador e para a identidade da força de trabalho, numa época em que "a empresa" significava Active Directory on-premises e uma pilha SOAP. É verboso, é antigo e está absolutamente em toda parte dentro de grandes organizações, que é o único fato sobre ele que importa para você.

OIDC é de 2014 e é JSON e JWTs, assentado sobre o OAuth 2.0. Um provedor de identidade emite um ID token que seu app valida. Foi criado para a web moderna: SPAs, apps móveis, APIs, login social. É mais limpo, mais bem especificado para as coisas que você de fato constrói hoje, e é o protocolo que a maioria dos novos projetos de identidade agora fala.

Quando cada um vence

A resposta honesta para "qual eu deveria construir" é que você quase nunca pode escolher. Você constrói o que o departamento de TI do seu cliente escolheu, e eles escolheram muito antes de terem ouvido falar de você.

• Um cliente no Okta, Entra ID ou Google Workspace geralmente consegue usar qualquer um dos dois, e o OIDC é o caminho mais agradável.
• Um cliente em um ADFS mais antigo, um IdP legado on-premises ou uma lista de requisitos de compras escrita em 2016 vai te entregar um bloco de metadados SAML e um convite de calendário, e esse é o fim da discussão.
• Seus próprios apps de primeira parte, seu dashboard e seu cliente móvel, querem OIDC, ponto final. Você nunca recorreria ao SAML para logar um usuário no seu próprio app React.

Então o campo se divide de forma limpa: OIDC para o moderno e o de primeira parte, SAML para "porque a empresa mandou". Venda para empresas suficientes e vão pedir os dois. Não eventualmente. Repetidamente.

As armadilhas, que é onde construir você mesmo fica caro

O problema do SAML é que ele é um protocolo de XML assinado, e XML assinado é uma das coisas mais consistentemente perigosas da criptografia aplicada. As formas de errar a verificação de assinatura do SAML são muitas e famosas:

• Signature wrapping (XSW): um atacante move o elemento assinado e insere uma asserção forjada e não assinada onde o seu parser de fato lê. Se você verifica a assinatura e lê a asserção como duas etapas separadas, você provavelmente está vulnerável, e quase toda primeira implementação faz exatamente isso.
• Canonicalização e injeção de comentários: a classe de bugs de 2018 em que user@company.com<!---->.evil.com é canonicalizado de um jeito para a verificação de assinatura e de outro jeito para a string que o seu código lê, então você autentica alegremente a pessoa errada. CVEs reais, em várias bibliotecas importantes.
• As mais silenciosas: assinar a resposta mas não a asserção, aceitar asserções não assinadas, confiar no emissor fornecido pelo IdP sem fixá-lo, errar a janela de validade da asserção. Cada uma é a sua própria armadilha, e cada uma já foi colocada em produção por pessoas que sabiam o que estavam fazendo.

O OIDC é significativamente mais sensato, mas não é livre de arestas. Você ainda precisa validar as claims certas (iss, aud, exp, o nonce), usar PKCE, recusar o há muito morto fluxo implícito, e rotacionar e cachear JWKS sem rejeitar um token assinado por uma chave que você ainda não buscou. A diferença é que as armadilhas do OIDC são documentadas, têm formato JSON e são tratadas corretamente por padrão na maioria das bibliotecas. As armadilhas do SAML têm formato XML e já devoraram times de segurança muito mais bem equipados que o seu.

A resposta de verdade

"OIDC ou SAML" é a pergunta errada, porque a resposta certa para um produto B2B é "sim". Seus clientes modernos e seus próprios apps querem OIDC. Seus clientes corporativos vão exigir SAML num cronograma que você não controla. Construa para um, e a terceira reunião de vendas derruba tudo.

O que você realmente precisa é de uma forma de aceitar qualquer que seja o protocolo que cada cliente traz, sem montar duas stacks, dois conjuntos de encanamento de metadados e duas chances independentes de errar a verificação de assinatura. A implementação é o custo. A escolha nunca foi a parte difícil.

Essa é a parte que o Authagonal tira do seu prato. Cada tenant ganha SAML 2.0 com importação de metadados em um clique e federação OIDC com os provedores que seus clientes já usam, no mesmo login, sem taxa por conexão para nenhum dos dois. Você não implementa verificação de assinatura XML, você não fica de babá de um cache JWKS, e você não reconstrói nada disso quando o próximo cliente aparece falando o outro protocolo. Veja o que está incluído.