A maioria das startups de SaaS quer vender para empresas, mas muitas não estão preparadas para o requisito mais solicitado de uma empresa: logon único (SSO). Os produtos SaaS geralmente são projetados para nomes de usuário e senhas, não integrações complexas com provedores de identidade (IdPs) como Okta, Google ou Active Directory. 

Quando confrontados com o desafio de construir essas integrações, muitos desenvolvedores vão arregaçar as mangas, ler as especificações de autenticação e autorização e começar a trabalhar. Infelizmente, pode haver tanto espaço para interpretação nessas especificações que a implementação do SSO se torna difícil, lenta e arriscada. Se você é uma pequena startup, ou mesmo uma empresa de médio porte com uma equipe de engenharia ocupada, esse trabalho pode ser um grande dreno e diminuir sua capacidade de começar a adquirir clientes corporativos.

Pode custar semanas preciosas (ou meses) para implementar o SSO para um negócio corporativo e, para surpresa de muitos desenvolvedores, o que funcionou para um cliente corporativo pode não funcionar para o próximo. O SSO é inesperadamente desafiador para fazer de forma correta e consistente. Vamos detalhar o porquê e, em seguida, oferecer algumas abordagens alternativas.

O que há de tão difícil em construir o SSO?

Deixe-me contar sobre a primeira vez que tentei implementar o SSO. 

Comecei o Nylas Mail em 2013 depois de escrever as linhas iniciais de código no meu dormitório no MIT. Tornou-se um projeto de código aberto muito bem-sucedido e arrecadamos mais de US$ 10 milhões na tentativa de destronar o Microsoft Outlook. Não demorou muito para que precisássemos comercializar, e foi quando nos deparamos com um público totalmente novo de compradores: líderes de TI e profissionais de compras. Estávamos empolgados em conversar com clientes corporativos sobre adoção, mas eles precisavam de recursos corporativos para implementar o Nylas em escala. Como uma pequena startup, projetamos nosso aplicativo para usuários comuns e não para adoção corporativa, portanto, não estávamos preparados para integrar com um IdP ou satisfazer outros requisitos corporativos. O trabalho para adicionar esses recursos foi demais para nós e nos impediu de obter sucesso no mercado comercial. 

A lição aqui é que sem SSO e outros recursos corporativos, um produto só pode ir até certo ponto.

A principal coisa a entender sobre SSO é que é um problema de integração. A maioria dos desenvolvedores cria aplicativos usando pacotes OSS, como Devise , que trata da autenticação para Ruby on Rails. Isso funciona para clientes com requisitos básicos, permitindo que as pessoas usem diferentes modelos com alta modularidade. Em algum momento, os desenvolvedores acabam precisando integrar seu produto a um IdP, geralmente começando com as maiores necessidades de seus clientes. Diferentes empresas usam diferentes soluções de IdP: algumas podem usar soluções prontas, como Okta ou Azure Active Directory, enquanto outras têm suas próprias soluções personalizadas.

Qualquer fornecedor que deseje vender para essas empresas deve se integrar a todos esses IdPs, o que significa gerenciar tanto a autenticação do IdP quanto os usuários baseados em credenciais nativas (ou seja, um nome de usuário e senha nativos da plataforma do fornecedor). Como nenhum dos IdPs funciona de forma idêntica e há tantos provedores de SSO, você precisará manter várias integrações em paralelo.

A integração de SSO vai além de criar recursos e funcionalidades e garantir que eles funcionem. É preciso um trabalho considerável para adaptar perfeitamente o fluxo de login de um aplicativo. A orquestração e a habilitação de recursos dependem da funcionalidade do IdP e exigem uma nova lógica de negócios com implicações para a autenticação móvel e de dois fatores (2FA). O SSO geralmente também possui 2FA integrado, criando complexidade adicional que deve ser considerada juntamente com outras integrações no nível do sistema. 

SAML é metade da batalha

Existem várias maneiras de implementar o SSO. Um dos mais populares é através de um padrão aberto baseado em XML chamado Security Assertion Markup Language (SAML). A especificação SAML é flexível e tem várias opções para cobrir uma variedade de casos possíveis. Não há dois fornecedores que implementem a especificação da mesma maneira. Em outras palavras, não é implementado de forma consistente e existem vários “sabores” de SAML. Como resultado, está repleto de oportunidades para problemas de segurança.

Para ser claro, não é que a especificação seja mal projetada. Em vez disso, quando os protocolos foram projetados, os designers queriam abranger muitas possibilidades. Muito pode ser feito com SAML que raramente é implementado. Mas qualquer integração de SSO ainda precisa estar pronta para dar suporte a determinados casos de borda, que é onde as vulnerabilidades surgem.

Cargas SAML

Ao se preparar para uma integração SSO, um fornecedor corporativo provavelmente realizará uma revisão de segurança do código SAML para procurar código ou fluxos exploráveis. Por exemplo, o SAML usa certificados e assinaturas para cargas úteis, o que pode ser particularmente complicado por estruturas de dados aninhadas. Isso é útil para o gerenciamento de vários níveis de comunicação IdP, principalmente em grandes empresas, onde pode haver várias camadas de autenticação SAML para passar. Cada camada tem assinaturas que precisam de verificação, um processo que pode ser como descascar uma cebola. Uma integração SAML generalizada pode ser difícil de implementar e verificar porque nem sempre é hierárquica e as solicitações entre sistemas podem ser não lineares.

Se todas as camadas não forem completamente verificadas, os agentes mal-intencionados podem fazer uso indevido da carga útil. Uma exploração SAML comum é modificar respostas válidas e injetar uma assinatura inválida diferente de uma sessão expirada. A razão pela qual isso funciona é simples: um dos desenvolvedores do SAML SSO escreveu um código que verifica se há assinaturas válidas, mas não em toda a resposta. Cada camada da carga SAML precisa ser investigada por completo. A maioria das or