O melhor CIAM auto-hospedado para quem constrói SaaS B2B

Se já olhou para os preços de algumas plataformas CIAM em SaaS, provavelmente reparou como elas ficam caras e muito possivelmente considerou uma opção auto-hospedada.

Este artigo trata das quatro plataformas CIAM auto-hospedadas que uma equipa pequena de SaaS B2B consegue mesmo manter sem que isso se torne um segundo emprego a tempo inteiro: ZITADEL, FusionAuth, Logto e Ory Hydra. Não têm todas o mesmo formato, e a certa para si depende menos de uma lista de funcionalidades e mais do tipo de produto B2B que está a construir. Corri-as lado a lado num único VPS durante uma semana para montar esta comparação, e o que se segue é a versão que enviaria a um fundador que me escrevesse por mensagem sobre CIAM.

Um aviso à partida: isto é sobre CIAM como funcionalidade de produto, não sobre SSO interno para a sua própria equipa.

A versão curta

Quatro plataformas CIAM auto-hospedadas, uma linha para cada:

• ZITADEL se quer multi-tenancy e organizações B2B prontos a usar.
• FusionAuth se quer uma interface de administração polida e um histórico de versões longo e previsível.
• Logto se quer a experiência de programação mais limpa logo no primeiro dia.
• Ory Hydra se trabalha ao nível do protocolo e quer o motor OAuth 2.0, não uma aplicação de login já decidida por si.

Em resumo: o ZITADEL é a aposta inicial mais segura para um SaaS B2B típico, e o resto do artigo desenvolve esse raciocínio.

Porque o CIAM é uma decisão diferente do SSO interno

Se o SSO da sua equipa interna cair, o estrago costuma ficar contido. Os seus engenheiros podem perder o acesso ao Grafana ou a outra ferramenta interna durante uma hora. Se o CIAM cair, os seus clientes pagantes deixam de conseguir entrar no produto de todo. Isso muda a pergunta de «que ferramenta de autenticação é cómoda para a nossa equipa?» para «em que sistema de autenticação podemos confiar como parte do próprio produto?»

O CIAM, o tipo de infraestrutura de identidade de que um SaaS B2B precisa, exige também primitivas que muitas ferramentas de SSO interno não realçam. O seu cliente não é um único utilizador; é uma organização (um tenant) com os seus próprios utilizadores, papéis, identidade visual e, possivelmente, a sua própria ligação SAML a um IdP corporativo. Não está apenas a autenticar pessoas; está a isolar os utilizadores de uma empresa dos de outra dentro do mesmo produto. É esta a forma B2B que as quatro ferramentas abaixo abordam, cada uma à sua maneira. O Keycloak tem agora Organizations de primeira classe, pelo que descartá-lo como sendo apenas para colaboradores internos seria desatualizado; explico a sua ausência nas perguntas frequentes.

O triângulo construir, comprar ou auto-hospedar também tem outro aspeto aqui. Escrever OAuth de raiz é um erro evitável. Está a lançar um produto SaaS, não um fornecedor de identidade. Comprar gerido (Auth0, Clerk, WorkOS) é a escolha certa quando a sua equipa não tem capacidade de operações e tem um orçamento razoável. Nunca diria a uma startup de duas pessoas para auto-hospedar a autenticação logo no primeiro dia. Auto-hospedar torna-se racional quando o preço por MAU do CIAM gerido ultrapassa o custo da infraestrutura mais o tempo contínuo de engenharia, ou quando precisa de controlo direto sobre a implantação e o plano de dados. Nas equipas com que trabalhei, esse ponto costuma chegar entre «temos um produto a sério» e «temos uma verdadeira função de customer success».

Se procura SSO para as suas próprias aplicações e não para as dos seus clientes, essa é uma comparação diferente desta. Passemos às nossas escolhas.

As quatro ferramentas, uma a uma

Escolhi estes quatro porque têm forma de CIAM suficiente para serem avaliados como infraestrutura de produto, e não apenas como SSO interno. ZITADEL, FusionAuth, Logto e Ory oferecem todos um caminho real de auto-hospedagem e tração suficiente para serem levados a sério. As opções que são só bibliotecas, as de SSO interno e as menos maduras ficam melhor tratadas nas perguntas frequentes.

ZITADEL

O ZITADEL é uma plataforma de identidade de origem suíça escrita em Go, com arquitetura event-sourced e backend PostgreSQL. A 27 de julho de 2026, a sua versão mais recente no GitHub é a the 4.16 series, current as of July 2026. O ZITADEL passou de Apache 2.0 para AGPL-3.0 a partir da v3; para uso SaaS normal, o impacto prático costuma ser menos assustador do que parece, e explico os detalhes nas perguntas frequentes.

O que distingue o ZITADEL para SaaS B2B: as organizações e o multi-tenancy são primitivas de primeira classe, não funcionalidades que compõe a partir de objetos genéricos. Cria uma Organization, ela ganha os seus próprios utilizadores, políticas, identidade visual e definições de acesso, e pode conceder-lhe projetos para que os seus administradores giram as atribuições de papéis dos seus próprios utilizadores. Não tem de inventar o conceito de «tenant» por cima de utilizadores genéricos. Começa já com ele.

A experiência de programação é API-first, com as atuais APIs de recursos REST v2 mais acesso gRPC e REST aos serviços v1 antigos. Há SDK oficiais e da comunidade para as stacks de servidor mais comuns. A consola de administração é funcional, mas mais sóbria do que a do FusionAuth.

A minha leitura: Se está a construir um SaaS B2B e sabe que vai ter tenants, é por ZITADEL que eu começaria. Entre as opções auto-hospedadas, é a que está mais explicitamente desenhada em torno do problema do login B2B.

FusionAuth

O FusionAuth é uma plataforma norte-americana da Inversoft, LLC (uma LLC do Delaware que opera como FusionAuth), no mercado há mais tempo do que as outras três, e isso nota-se, no bom sentido. A interface de administração parece bastante mais trabalhada do que as restantes, a documentação é madura e a cadência de versões é constante em vez de alucinante. Se alguma vez herdou uma integração de autenticação com quatro anos e agradeceu em silêncio ao engenheiro anterior por ter escolhido a opção aborrecida, o FusionAuth é a versão do CIAM que merece esse agradecimento.

O que faz as pessoas tropeçarem é o licenciamento: o FusionAuth Community é gratuito para auto-hospedar, mas o produto principal não é código aberto. O produto rege-se pela licença própria do FusionAuth, e os seus limites importam se planeia redistribuir, incorporar, mudar a marca, revender ou alojar o FusionAuth para os seus próprios clientes. A versão Community auto-hospedada cobre o caso central do SaaS B2B; os planos pagos acrescentam funcionalidades como SAML iniciado pelo IdP, MFA avançada e temas específicos por aplicação, enquanto SCIM, Tenant Manager e políticas de MFA ao nível da aplicação ficam no Enterprise.

Quanto à forma B2B: o FusionAuth modela tenants e aplicações, mas a abstração é «autenticação em contentores por tenant» mais do que «organizações B2B como objeto de domínio». Funciona (já lancei produtos em cima disso), mas o multi-tenancy parece mais uma primitiva de isolamento do que um modelo B2B de primeira classe. Os SDK oficiais e bibliotecas cliente são abrangentes:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

As bibliotecas do lado do servidor são clientes de API leves. A consola de administração é comparativamente mais fácil de entregar a uma pessoa de operações sem perfil de engenharia do que as outras.

A minha leitura: Se a sua equipa valoriza o acabamento da interface e um histórico longo e previsível mais do que primitivas nativas de B2B, então FusionAuth. É a escolha mais «aborrecida» da lista, e isso é um elogio.

Logto

O Logto é o mais recente dos quatro, desenvolvido pela Silverhand Inc. e licenciado sob MPL-2.0, e é aquele a quem o dashboard mais visivelmente importa. A instalação do primeiro dia é comparativamente rápida. Faz o aprovisionamento, passa pelo assistente e tem um fornecedor OIDC a funcionar com uma interface de login predefinida decente em cerca de quinze minutos (cronometrei-o na semana em que corri os quatro lado a lado). Os seus guias de início rápido oficiais cobrem frameworks e stacks de servidor modernos, por isso se a sua stack é «Next.js + Postgres + qualquer coisa», vai sentir-se em casa.

A sua resposta B2B chama-se Logto Organizations. Cobre as primitivas B2B essenciais: pertença a uma organização, papéis com âmbito de organização, convites de membros, aprovisionamento just-in-time e integração de SSO empresarial. O modelo de organização é mais recente do que o do ZITADEL, por isso eu testaria qualquer fluxo SAML, SCIM ou de federação invulgar com os seus clientes-alvo antes de se comprometer.

O compromisso é a maturidade: o Logto é a opção mais recente aqui. O roadmap avança depressa, o que é ótimo quando chega uma funcionalidade de que precisa e incómodo quando chega uma alteração disruptiva. Se o seu SaaS B2B está no extremo mais simples do espetro multi-tenant (um conjunto pequeno de organizações e sem requisitos de federação exóticos), a experiência de programação do Logto torna o resto da decisão mais fácil.

A minha leitura: Se quer o primeiro dia mais rápido e as suas necessidades B2B ainda são relativamente simples, então Logto.

Ory Hydra (e a stack Ory)

O Ory Hydra é o servidor OAuth 2.0 / OpenID Connect do ecossistema Ory, licenciado sob Apache-2.0. A stack Ory completa junta o Hydra ao Ory Kratos (identidade e gestão de utilizadores, login self-service, registo, MFA e recuperação de conta), ao Ory Keto (um servidor de autorização ao estilo Zanzibar que funciona como ponto de decisão de políticas) e ao Ory Oathkeeper (um proxy de identidade e acesso que autentica, autoriza e transforma os pedidos HTTP recebidos). Monta o que precisa. Está tudo escrito em Go e as API são limpas.

O senão (e não é um defeito; para a equipa certa é uma vantagem) é que o Hydra é o motor, não a aplicação. Por desenho, o Hydra liga-se a uma aplicação de login e consentimento separada que você fornece. Se quer um ecrã de login pronto a usar, não é esta a ferramenta. Se está a construir algo em que o fluxo de autenticação faz parte do produto (uma plataforma para programadores, um portal B2B à medida ou um produto API-first com onboarding próprio), a ausência de uma interface imposta é exatamente o que quer.

A história B2B é componível em vez de chave na mão. Pode modelar o multi-tenancy ligando esquemas do Kratos e relações do Keto à sua própria camada de organização, e funciona, mas a cablagem é sua. O custo é mais canalização; o benefício é controlo sobre a experiência. A documentação da Ory cobre a superfície do protocolo em profundidade, mas o modelo componível parte do princípio de que está à vontade para tomar decisões ao nível do protocolo. Se «audience claim» ou «PKCE» não lhe dizem nada, comece por uma das outras três.

A minha leitura: Se está a construir algo ao nível do protocolo (gateway de autenticação, fluxos à medida, plataforma para programadores) e as aplicações padrão lhe parecem limitadoras, o Ory é a resposta certa. Para um SaaS B2B típico que quer o login a funcionar hoje, não é.

Como se comparam num relance

Aqui fica o resumo das quatro ferramentas numa só tabela, útil para uma segunda leitura, não como substituto dos perfis acima.

Por qual deve começar?

Quatro cenários curtos que cobrem a maioria das equipas com quem falaria sobre isto.

Está a construir um SaaS B2B e sabe que vai ter tenants. Comece pelo ZITADEL. As primitivas de multi-tenancy e organização foram desenhadas exatamente para isto, a superfície da API é abrangente e vai gastar menos tempo a inventar o modelo de tenant do que com qualquer uma das outras três. A mudança para AGPL merece uma revisão jurídica, mas uma implantação não modificada e integrada em separado costuma ser um caso de uso SaaS simples.

Quer a interface de administração polida e uma plataforma estável e previsível. FusionAuth. O plano Community cobre as necessidades essenciais de muitas equipas; reserve tempo para ler com atenção a licença e a matriz de funcionalidades. Funcionalidades como SAML iniciado pelo IdP, MFA avançada e temas específicos por aplicação exigem um plano pago, enquanto SCIM, Tenant Manager e políticas de MFA ao nível da aplicação ficam no Enterprise.

As suas necessidades B2B hoje são simples e quer o primeiro dia mais rápido. Logto. A sua experiência de programação no primeiro dia foi a mais rápida no meu teste lado a lado. Aceite que está a apostar num ecossistema mais jovem e reveja a escolha se os requisitos crescerem para casos-limite de federação que não testou.

Está a construir algo em que os fluxos de autenticação fazem parte da experiência do produto. Ory Hydra (mais Kratos, mais Keto se precisar de permissões). Vai escrever mais código. Vai ter mais controlo. Se essa troca não lhe é óbvia, não é o público do Ory. Escolha uma das outras três.

Se duas destas descrições lhe assentam, opte por ZITADEL por omissão. É o que encaixa de forma mais ampla e o que entregaria a uma pequena equipa fundadora sem fazer muitas perguntas adicionais.

O que a auto-hospedagem lhe custa (em operações)

Aqui vem a parte menos romântica do artigo.

A sua disciplina de cópias de segurança do PostgreSQL passa agora a ser algo de que o seu negócio depende. Nestas implantações, o estado de identidade que tem de proteger pode incluir registos de utilizador, credenciais com hash, segredos de MFA, credenciais de cliente OAuth e dados de sessão. Perca esse estado e os seus clientes podem perder a capacidade de iniciar sessão. Configure cópias automáticas antes de o primeiro utilizador real se registar, teste o restauro e coloque a saúde das cópias no mesmo canal de alertas que a disponibilidade da sua aplicação.

O ritmo de versões muda ao longo do tempo. O ZITADEL v4.16.1 saiu a 17 de julho de 2026 depois de várias versões em junho, e cada projeto aqui mantém a sua própria cadência e política de compatibilidade. Trate essa cadência como uma questão de manutenção, não como um atalho para julgar a qualidade. Leia as notas de versão antes de correr docker compose pull e agende uma janela de correções recorrente. Saltar atualizações do fornecedor de identidade durante meses pode deixá-lo atrás de correções de segurança e compatibilidade na sua primeira auditoria a sério.

As coisas banais que o apanham sempre desprevenido: a renovação de certificados TLS (use um proxy inverso com Let's Encrypt, automatize as renovações e alerte em caso de falha), a configuração do servidor de envio para e-mails de verificação e reposição de palavra-passe (SES, SendGrid, Postmark: escolha um e configure bem SPF/DKIM/DMARC ou os seus e-mails de reposição vão parar ao spam), a rotação de credenciais de cliente OAuth quando um engenheiro sai, e limitar a taxa nos endpoints de login para que um ataque de credential stuffing não lhe pregue o CPU.

Dica: se usa um Postgres gerido, não assuma que o utilizador de base de dados em execução também consegue criar o esquema. Crie previamente a base de dados e o utilizador, atribua os privilégios de propriedade ou de instalação necessários, e corra a primeira configuração com as credenciais que cada ferramenta espera. Caso contrário, a primeira execução pode falhar com um erro vago de permissões de base de dados e vai queimar uma hora a perseguir a pista errada.

Aquilo que a via auto-hospedada lhe poupa em dólares, cobra-lhe em responsabilidade. Depois da instalação, reserve algumas horas de engenharia por mês para manter a camada de identidade saudável. As equipas que alocam zero tempo costumam descobrir o custo mais tarde: durante uma falha, num caso-limite estranho de SAML ou na primeira auditoria de segurança.

Onde os implantar

Um VPS Linux a correr Docker Compose pode ser um ponto de partida sensato para avaliação e cargas modestas, mas o dimensionamento em produção e a alta disponibilidade dependem do tráfego, dos requisitos de segurança e da sua tolerância a indisponibilidade. Eis como se encaixam as opções de implantação mais comuns:

• Hospedagem compartilhada não consegue correr nenhum deles. Precisam de armazenamento persistente, portas personalizadas, acesso root para o runtime de contentores e um backend de base de dados a sério. O PostgreSQL é o caminho por omissão para a maioria desta lista, mas não é literalmente a única base de dados suportada por todas as ferramentas.
• Kubernetes consegue correr os quatro, mas o caminho oficial é irregular. ZITADEL, FusionAuth, e Ory publicam charts Helm oficiais, enquanto a documentação de auto-hospedagem do Logto se foca na implantação com Docker e VM. Para um SaaS B2B pequeno que ainda não chegou ao ponto em que o Kubernetes se paga noutros pontos, costuma ser sobre-engenharia. Recorra a ele quando o resto da sua infraestrutura já lá estiver.
• O bare metal serve se já estiver em bare metal. A maioria das equipas de SaaS B2B não está.

Para um piloto pequeno de nó único, começaria com 4 GB de RAM, 2 vCPU e 60 GB de armazenamento NVMe, e depois faria testes de carga ao fluxo de login real. É uma base de planeamento, não um mínimo universal de produção. As aplicações são relativamente leves, mas o PostgreSQL precisa de memória e o hashing de palavras-passe precisa de folga de CPU. As orientações de produção do ZITADEL recomendam disponibilizar quatro núcleos de CPU para picos de hashing de palavras-passe.

Quando o produto for real e o tráfego sustentado, redimensione a partir de medições. Armazenamento rápido ajuda a latência do PostgreSQL, enquanto a folga de CPU importa durante o hashing concorrente de palavras-passe. Vigie a memória, a E/S da base de dados, a latência de login e a saturação de CPU em vez de assumir que um recurso importa mais do que os outros.

Correr CIAM em produção significa que a sua disponibilidade passa a ser problema seu. Nós usamos instâncias Cloudzy Linux VPS para este tipo de carga, com armazenamento NVMe e um SLA de disponibilidade de 99,95% na plataforma subjacente. A Cloudzy oferece também um VPS ZITADEL num clique caso prefira saltar o script de aprovisionamento inicial; as outras três disponibilizam imagens de contentor oficiais para uma instalação com Docker. Para uma visão de nível de gestão sobre como o controlo de acessos encaixa no resto da sua postura de segurança, o guia de boas práticas de IAM aborda o tema pelo lado das políticas.

Perguntas frequentes

A licença AGPL do ZITADEL afeta o meu SaaS?

Normalmente não para uma implantação não modificada e integrada em separado, mas isto não é aconselhamento jurídico. As obrigações AGPL do ZITADEL aplicam-se ao próprio ZITADEL. Se modificar o ZITADEL e operar essa versão modificada como serviço de rede, a licença pode exigir que disponibilize o código-fonte correspondente sob AGPL. A posição publicada do ZITADEL é que usar simplesmente uma instância não modificada como serviço de identidade do seu SaaS não obriga, por si só, a licenciar a sua aplicação separada sob AGPL. Leia o anúncio de licenciamento do ZITADEL e obtenha aconselhamento jurídico se modificar, redistribuir, incorporar ou oferecer o software a terceiros. Existe também uma licença comercial.

Porque é que o Keycloak ou o Authentik não estão nesta lista?

O Keycloak e o Authentik são excelentes ferramentas de identidade auto-hospedadas (uso-as), mas excluir o Keycloak por lhe faltarem organizações B2B seria hoje errado: as versões atuais do Keycloak incluem Organizations, grupos de organização e controlos de administração delegada. Deixei-o de fora porque esta comparação se foca em quatro opções com um caminho mais direto para um SaaS B2B de equipa pequena; o Keycloak merece uma avaliação própria quando a operação da JVM, a profundidade do ecossistema e a flexibilidade ao nível de realm são relevantes. O Authentik continua a encaixar melhor no SSO interno e de aplicações internas do que na modelação de tenants nativa do produto.

Auto-hospedar sai mais barato do que o Auth0?

Com poucos MAU, muitas vezes não. As suas horas de engenharia custam mais do que a fatura do Auth0 no escalão de startup inicial. A auto-hospedagem ganha economicamente à escala em que o preço por MAU do CIAM gerido ultrapassa o custo combinado de um VPS pequeno mais as poucas horas de engenharia por mês que lhe vai dedicar. O ponto de equilíbrio exato depende do custo-hora da sua equipa, da sua curva de crescimento de MAU e de o produto precisar ou não de funcionalidades empresariais que o empurrem para os escalões mais caros do Auth0. Trate a poupança como real, mas não imediata.

Qual é o tamanho mínimo de VPS para um CIAM em produção?

Para um piloto pequeno de nó único, 4 GB de RAM, 2 vCPU e armazenamento NVMe são um ponto de partida razoável, não uma garantia de produção. Dimensione a partir do tamanho da sua base de dados, da carga de logins concorrentes, do custo do hashing de palavras-passe e do seu objetivo de disponibilidade. As próprias orientações de produção do ZITADEL recomendam ter quatro núcleos de CPU disponíveis para picos de hashing; outras ferramentas e padrões de tráfego precisam dos seus próprios testes de carga.

Posso migrar mais tarde de um CIAM gerido para auto-hospedado?

Sim, mas planeie-o como um projeto a sério. As reposições de palavra-passe não são inevitáveis: a exportabilidade e os formatos de hash suportados variam, e alguns destinos suportam a migração de utilizadores em bloco ou just-in-time enquanto outros obrigam a uma reposição. Fatores de MFA, clientes OAuth, sessões ativas, estado de verificação de e-mail e mapeamentos de tenants ou papéis exigem tratamento à parte. Se já suspeita que vai auto-hospedar mais tarde, registe essas restrições de exportação e migração antes de escolher o fornecedor gerido.