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 organizações não possui sistemas de identificação de vários níveis, portanto, essa não é uma exploração particularmente comum, mas o protocolo a suporta porque foi projetada com esse tipo de flexibilidade em mente.

A falta de padronização pode facilmente levar a falhas e vulnerabilidades

Quando se trata de SSO, há milhares de coisas para acertar e muitos pequenos detalhes a serem considerados. Você pode implementar algo e fazê-lo funcionar, mas a robustez virá testando-o contra implementações. E enquanto a especificação é padronizada, essas implementações não são.

Considere escrever uma integração SAML para uma nova plataforma organizacional. A plataforma pode usar XML canônico , mas não pode declarar explicitamente um namespace, o que pode causar uma falha de autenticação. Mesmo que ambas as partes em cada lado do fluxo estejam em conformidade com a especificação, não há garantia de que funcionará imediatamente. É especialmente doloroso quando uma parte faz uma pequena alteração em sua implementação, pois isso pode levar a falhas de login que são especialmente difíceis de solucionar. Um usuário pode ligar para o departamento de TI e dizer: “Não consigo fazer login”, iniciando uma busca inútil em um esforço para solucionar um problema com uma pequena alteração de XML em um sistema que ele não controla.

A natureza baseada em XML do SAML vem com desafios relacionados a XML. A ordenação de objetos e a organização de entidades aninhadas (ou seja, tags) podem causar problemas. O mapeamento de atributos não é padrão nas plataformas. Os identificadores de usuários nas plataformas não são padronizados. Às vezes você recebe um ID, às vezes um e-mail. Às vezes, não há identificador e é algo opaco como uma string serializada do Active Directory. Pode ser tentador usar uma biblioteca de código aberto – nada supera o baixo preço do gratuito – mas poucos pacotes de código aberto lidam bem com XML. 

O design do aplicativo pode influenciar a funcionalidade e a segurança do SAML

A integração SSO também pode diferir com base na estrutura de um aplicativo. Por exemplo, posso fazer login no GitHub com minha conta pessoal do Gmail e depois entrar em um dos sistemas internos da minha empresa. O GitHub está agindo essencialmente como um segundo fator de autenticação para meu aplicativo interno, permitindo que eu pule o mecanismo de autenticação principal do aplicativo. Você pode ter formas primárias e secundárias de autenticação—e fluxos diferentes para autenticação de e-mail e senha—mas o funcionamento desses sistemas conforme projetado é influenciado pela natureza do próprio aplicativo.

Ao criar um aplicativo com SAML SSO, você não precisa se preocupar em alterar nomes de usuário ou senhas, pois isso pode ser feito fora do seu aplicativo. No entanto, os fluxos têm que refletir essa realidade. Alguns sistemas IdP, como o Active Directory da Microsoft, que fornece uma string opaca e exclusiva, não fornecem um endereço de e-mail. Se você não obtiver um endereço de e-mail, precisará descobrir outra maneira de identificar e autenticar um usuário. Esse método pode não funcionar com a estrutura de dados ou a arquitetura geral do seu aplicativo.

Muitos aplicativos SaaS prontos para empresas iniciam logins de SSO solicitando o subdomínio da organização. Uma pesquisa nos bastidores direciona você para o formulário de login para o login do IdP dessa empresa nesse aplicativo SaaS. O problema é que um agente mal-intencionado pode encontrar uma exploração digitando vários subdomínios da empresa e saber quem está usando SSO e SAML. Se esse agente mal-intencionado estiver procurando usar uma vulnerabilidade de segurança recém-descoberta, é possível que a exploração funcione em pelo menos uma dessas telas de login do IdP.

Construir interfaces de usuário com capacidade de SSO é difícil e cada empresa está fazendo algo diferente. O padrão mais comum é ter campos de nome de usuário e senha com alguns ícones de IdP abaixo e em texto pequeno, “Entrar com SAML/SSO”. O login do iCloud da Apple não mostra um campo de senha imediatamente porque verifica se o domínio do nome de usuário está coberto por um fluxo de SSO. O Slack usa CNAMEs personalizados em seus URLs, como avance10.com, e envia você para o fluxo de login correto. Não há uma maneira padrão de fazer isso, e é por isso que todo mundo faz de maneira diferente.

Onboarding de empresas e offboarding de pessoas

Outra complicação relacionada ao SSO baseado em SAML é a integração de novos clientes. Digamos que você seja um fornecedor de SaaS e acabou de assinar seu primeiro grande contrato com uma grande empresa. Agora é hora de colocar esses usuários corporativos em seus sistemas. Seu engenheiro de integração configurará a integração SAML trabalhando com o arquiteto de segurança da empresa.

A configuração de uma integração SAML envolve a troca de um conjunto de parâmetros de dados, como URLs de redirecionamento e mapeamento de campo de atributos SAML. Não há uma especificação clara de como os nomes devem ser (como distinção entre maiúsculas e minúsculas), portanto, será necessário fazer testes para garantir que ambos os lados funcionem. Há também a necessidade de fazer o upload de um certificado, que também não possui uma metodologia clara na especificação.

Testar a integração SAML é um grande ponto de atrito para as empresas e quase sempre é feito manualmente, o que significa que as ferramentas para a configuração também são gerenciadas manualmente. Em sua forma mais básica, as empresas têm usado uma planilha ou formulário simples para a troca de parâmetros de dados. O processo é tão propenso a quebras que muitas vezes é tratado com um serviço personalizado de luva branca. Construir um painel de administração multiuso para SAML é caro e difícil, então as empresas geralmente continuam com o trabalho manual até que o projeto se torne proibitivo.

Coordenar, configurar, implementar e testar o SSO pode levar semanas, se não meses, de comunicação direta. É um processo árduo, muitas vezes envolvendo muita discussão e trabalho em torno de autenticação (“aqui está a identidade validada de um usuário”) e autorização (“aqui estão os serviços e recursos aos quais o usuário validado tem acesso”). Sistemas de ID empresarial como SAML só fazem autenticação para provar que alguém é quem diz ser, deixando a autorização para aplicativos e serviços. O SAML deve intermediar sessões reais como uma autorização de um bit, provando que uma pessoa é quem diz ser, quase como escanear um crachá RFID em uma porta de segurança. O que acontece depois que eles passam pela porta é outra coisa. 

Desafios de gerenciamento de sessão

Ao autenticar com SAML, você está autenticando um usuário, mas após essa validação, você não pode verificar se ainda é uma sessão ativa atual. Você sabe que teve uma sessão atual em um momento em que se autenticou, mas quanto tempo dura sua sessão? Se for muito curto – digamos, 24 horas – pode ser um incômodo, exigindo um login todos os dias para cada usuário. Existem maneiras de contornar isso se você tiver acesso a outros sistemas de identidade, mas o ponto é: o gerenciamento de sessões é um desafio.

Para produtos B2C SaaS, o logout de usuários tem um efeito negativo na retenção e no engajamento. A maioria dos produtos tem um cookie de duas semanas para manter a sessão atualizada, mas os administradores de TI corporativos nem sempre querem isso. Os fornecedores de SaaS, especialmente aqueles que estão vendendo para seu primeiro cliente corporativo, podem ter que repensar o gerenciamento de sessões para seus aplicativos. Depois, há considerações sobre como as sessões são gerenciadas em dispositivos móveis. 

Usuários desligados

Quando uma empresa assina um contrato com seu produto, ela traz uma enorme quantidade de novos usuários. Mas nem todos esses usuários permanecerão durante a vigência do contrato. Uma variedade de processos precisa ser projetada para saídas de funcionários da empresa. Por exemplo:

• O que acontece com os dados de um usuário quando um funcionário sai?
• Os dados ou a conta do usuário são transferidos para uma conta administrativa?
• Todas as sessões devem ser revogadas? Em caso afirmativo, em quanto tempo e como você descobrirá que eles foram embora?
• Como os itens compartilhados serão tratados?
• O que precisa ser desativado e o que precisa ser preservado?

Essas são várias questões importantes a serem consideradas ao vender para clientes corporativos. Não são perguntas fáceis de responder, especialmente se a desativação do usuário já estiver implementada de forma inflexível.

Quando um funcionário sai de uma organização cliente, talvez em más condições, há uma chance de que ele tenha acesso a informações confidenciais, entregas importantes em andamento ou documentos compartilhados com implicações financeiras impactantes. Sem um plano sólido para remover esses usuários, os fornecedores de SaaS podem se encontrar no caminho crítico para os processos de desligamento de RH, TI e segurança da informação de seus clientes corporativos. Se o funcionário optar por sabotar ou adulterar dados aos quais não deveria mais ter acesso, isso é uma má notícia para o fornecedor.

Atravessando o abismo da empresa

Ao vender para uma empresa, seu produto precisa oferecer recursos empresariais. A implementação do SSO – o recurso corporativo mais solicitado – pode exigir mudanças na arquitetura de aplicativos e dados para como uma equipe de desenvolvimento opera e interage com grandes clientes. Não há quase nada em um aplicativo SaaS que não exija reconsideração (ou pelo menos uma verificação dupla) para oferecer suporte a esse primeiro cliente corporativo.

O SSO não se trata apenas de criar um recurso de nível empresarial, mas de manter um conjunto de fluxos que permitem que diferentes clientes com diferentes IdPs usem um aplicativo. Construir SSO com SAML requer muitas decisões e lógica de negócios, o que não acontece organicamente. Além disso, é uma prática recomendada garantir que haja mais de uma pessoa na equipe que entenda a implementação do SAML. Caso contrário, se o desenvolvedor sair e ninguém conhecer os protocolos, pode ficar confuso rapidamente. E as empresas não querem mexer com SAML.

De longe, o SSO é o recurso corporativo mais importante a ser implementado, portanto, se houver orçamento suficiente apenas para um recurso, deve ser o SSO. É a porta de entrada para vender para uma tonelada de empresas. Aprofundando, os fornecedores devem considerar se algum dos itens a seguir seria um benefício adicional para sua implementação de SSO SAML:

• Integração de diretórios
• Gerenciamento automático do ciclo de vida do usuário
• Desprovisionamento de usuários
• Login automático para conformidade de auditoria e retenção eletrônica
• Conformidade com SOC 2
• GDPR
• HIPAA
• Controle de acesso baseado em função granular (RBAC)
• Gerenciamento de chaves corporativas (traga sua própria chave e criptografia)

Antes de começar a construir o SSO, dê uma olhada no WorkOS . O SSO é apenas um dos recursos que oferecemos com apenas algumas linhas de código em seu aplicativo. Mantemos uma forte integração com os IdPs mais populares, temos um painel de administração fácil de usar que as empresas adoram, oferecemos sincronização ao vivo com diretórios de usuários corporativos e facilitamos muito a autenticação multifator.