Authentik vs ZITADEL vs Keycloak: que SSO auto-hospedado deve escolher?

Tem oito contentores Docker a correr num VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, uma página de estado e uma aplicação interna que escreveu você mesmo. Cada um tem o seu próprio login. Copia e cola palavras-passe do seu gestor todas as manhãs e começou a perguntar-se se o single sign-on compensa o custo operacional.

Normalmente compensa. A questão é qual fornecedor de identidade executar.

O Keycloak é a escolha predefinida mais conhecida, mas a melhor opção depende de como é a sua stack, de quantos utilizadores gere e de estar a integrar software que já executa ou a construir a autenticação nas suas próprias aplicações.

Esta comparação de SSO auto-hospedado analisa Authentik, ZITADEL, Keycloak e Authelia através das decisões que importam depois da implementação: suporte de protocolos, gestão de utilizadores, fluxo de trabalho para programadores, requisitos de recursos e o que acontece quando o seu fornecedor de identidade fica em baixo.

Porque é que o SSO auto-hospedado importa

Assim que várias aplicações dependem das mesmas pessoas e grupos, os logins separados deixam de ser convenientes. Um fornecedor de identidade auto-hospedado dá-lhe um único sítio para gerir contas, MFA, pertença a grupos e políticas de acesso, em vez de configurar esses controlos separadamente em cada aplicação.

A contrapartida é igualmente importante: o IdP passa a ser infraestrutura de que outras aplicações dependem. Novos logins e renovações de tokens podem falhar quando está indisponível, por isso cópias de segurança, acesso de recuperação, atualizações e disponibilidade importam mais aqui do que numa aplicação auto-hospedada comum.

TL;DR

Escolha o Authentik se quer a melhor opção predefinida

Para um homelab, uma stack de ferramentas internas ou uma equipa pequena que liga aplicações existentes via OIDC ou SAML, o Authentik é a escolha predefinida mais sólida. O seu fluxo de administração é mais acessível do que o do Keycloak, suporta vários métodos de integração e a sua configuração oficial de Docker Compose começa em 2 núcleos de CPU e 2 GB de RAM.

Escolha o ZITADEL se está a construir aplicações

Escolha o ZITADEL quando a autenticação faz parte do produto que está a construir. O seu modelo de organizações, as APIs, a multi-tenancy, OIDC, SAML, passkeys, MFA e o suporte para fornecedores de identidade LDAP fazem mais sentido para equipas de aplicações SaaS e B2B do que para um homelab típico.

Escolha o Keycloak se precisa de funcionalidades de identidade empresariais

Escolha o Keycloak quando precisa de federação LDAP ou Active Directory mais profunda, vários realms, políticas de autorização detalhadas ou de um ambiente já construído em torno do Keycloak. A documentação recomenda um limite de memória de 2 GB para contentores Keycloak pequenos prontos para produção; um VPS tudo-em-um que também executa PostgreSQL precisa de margem adicional.

Alternativa: escolha o Authelia se precisa sobretudo de uma barreira de login

Escolha o Authelia quando o seu principal problema é proteger aplicações na camada do proxy inverso em vez de executar uma plataforma de identidade completa. Também pode atuar como fornecedor OpenID Connect, mas a autenticação no proxy inverso continua a ser o seu centro de gravidade.

O que verificar antes de escolher uma ferramenta de SSO

Antes de comparar funcionalidades, confronte cada ferramenta com as aplicações, protocolos e fontes de identidade que já precisa de suportar.

Quantas aplicações precisam de SSO?

Comece pelas aplicações, não pelo fornecedor de identidade. Uma stack com seis aplicações que já suportam OIDC ou SAML é um problema diferente de uma stack de ferramentas internas antigas que não sabem nada de nenhum dos protocolos. O primeiro caso aponta para um IdP completo. O segundo pode precisar de autenticação na camada do proxy inverso.

As suas aplicações suportam OIDC ou SAML?

O OIDC é a escolha comum para aplicações web modernas. O SAML ainda importa em software empresarial e integrações mais antigas. O LDAP pode importar quando a aplicação espera um diretório em vez de um fluxo SSO web. Verifique o que cada aplicação aceita realmente antes de escolher o IdP que ficará no meio.

Está a gerir utilizadores ou a integrar o login numa aplicação?

Se a maior parte do seu trabalho vai acontecer numa interface de administração enquanto liga aplicações existentes, o Authentik é o ponto de partida natural. Se a autenticação faz parte de um produto que está a construir e espera aprovisionar organizações, utilizadores e permissões por código, o ZITADEL está muito mais próximo desse fluxo de trabalho.

Precisa de LDAP, Active Directory ou políticas avançadas?

Authentik, ZITADEL e Keycloak conseguem todos ligar-se de alguma forma a fontes de identidade baseadas em LDAP, por isso o LDAP por si só já não decide a comparação. O Keycloak torna-se mais interessante quando a federação de diretórios se combina com vários realms, mappers detalhados, requisitos de sincronização ou políticas de autorização ao nível do recurso.

Authentik vs ZITADEL vs Keycloak vs Authelia

As quatro ferramentas sobrepõem-se no SSO, mas abordam a identidade de direções diferentes: integração de aplicações, identidade de produto, IAM empresarial e acesso via proxy inverso.

Authentik

O Authentik executa a sua implementação base como um servidor, um worker e uma base de dados PostgreSQL. O Redis já não faz parte da stack: o Authentik removeu completamente a dependência na versão 2025.10. A documentação atual de Docker Compose exige um anfitrião com pelo menos 2 núcleos de CPU e 2 GB de RAM.

O traço definidor é a interface de administração. O motor de fluxos do Authentik, o aprovisionamento de aplicações e as políticas por grupos são mais acessíveis do que o modelo de configuração mais amplo do Keycloak. Se alguma vez configurou uma aplicação OIDC no Keycloak e depois passou tempo a perceber porque faltavam claims no token, a diferença nota-se depressa.

Suporta SAML, OAuth2/OIDC, LDAP e RADIUS. É a escolha predefinida certa para um homelab ou uma equipa de engenharia pequena que executa uma stack de aplicações auto-hospedadas.

ZITADEL

O ZITADEL é escrito principalmente em Go, tem licença AGPL-3.0 e está na linha de versões v4.x. A implementação inclui uma API em Go, uma interface de login em Next.js e PostgreSQL, e os requisitos atuais suportam PostgreSQL 14 a 18. A documentação oficial de Docker Compose exige um anfitrião com pelo menos 2 GB de RAM.

O traço definidor é a API. O ZITADEL expõe uma superfície de identidade completa por gRPC e REST e é construído desde o início sobre um modelo multi-tenant. Se está a construir um produto SaaS e quer que a camada de login seja programável, automatizável e multi-tenant por predefinição, o ZITADEL está mais próximo do que procura do que as alternativas.

Suporta OIDC, SAML, passkeys, MFA, fornecedores de identidade LDAP e uma interface SCIM v2 atualmente marcada como Preview. O seu modelo de organizações e o fluxo de trabalho API-first tornam-no mais adequado a equipas de produto do que a um simples homelab.

Keycloak

O Keycloak é uma plataforma Java de gestão de identidades e acessos que corre sobre Quarkus. Tem uma superfície de configuração maior do que as outras opções aqui, sobretudo quando entram em jogo Realms, Clients, Roles, federação de utilizadores e Authorization Services.

A documentação oficial de contentores recomenda um limite de memória de 2 GB para implementações pequenas prontas para produção. Esse valor cobre apenas o contentor do Keycloak; se o PostgreSQL partilhar o mesmo VPS, dê mais margem ao anfitrião.

A razão para aceitar essa complexidade é concreta. O Keycloak consegue federar diretórios LDAP e Active Directory, registar eventos de utilizadores e administradores e aplicar autorização detalhada com políticas RBAC, ABAC, baseadas no utilizador, baseadas no contexto e de outros tipos. Se precisa desses controlos, a configuração extra tem um propósito.

Authelia

O Authelia é o mais pequeno dos quatro: licença Apache 2.0, um único binário Go, atualmente na v4.39.x. A arquitetura é diferente das outras três: o Authelia fica à frente de um proxy inverso (nginx, Traefik, Caddy, HAProxy) e decide se os pedidos podem chegar ao backend.

O Authelia inclui também um fornecedor OpenID Connect. A documentação ainda descreve a implementação OIDC como beta aberta, mas o fornecedor tem certificação OpenID para os perfis Basic OP, Implicit OP, Hybrid OP, Form Post OP e Config OP. O seu conjunto de funcionalidades OIDC é mais reduzido do que o que o Authentik ou o Keycloak oferecem para gestão de identidades, e é por isso que o Authelia continua a fazer mais sentido quando a autenticação no proxy inverso é a tarefa principal.

Voltaremos ao Authelia numa secção própria. Em resumo: o centro de gravidade do Authelia é o controlo no proxy inverso, não a gestão completa de identidades.

Comparação de funcionalidades

A tabela abaixo limita a comparação às diferenças que afetam a implementação e a administração do dia a dia.

Que ferramenta serve para que stack?

A melhor opção muda consoante quem opera o IdP e como as aplicações se integram com ele.

Melhor opção para um homelab

O Authentik é a escolha predefinida para um homelab onde a maioria das aplicações já suporta OIDC ou SAML. Dá-lhe um fornecedor de identidade completo sem o obrigar a adotar o modelo IAM mais amplo do Keycloak. Se a maior parte da stack precisa de um ecrã de login no proxy inverso em vez de SSO nativo, o Authelia pode ser a escolha mais simples.

Melhor opção para a stack de uma pequena empresa

O Authentik serve a maioria das stacks pequenas de aplicações internas, sobretudo quando o objetivo é uma única camada de identidade para ferramentas como Grafana, Gitea, Nextcloud e Vaultwarden. O Keycloak torna-se mais atrativo quando um diretório existente, vários realms ou políticas de autorização mais profundas fazem parte do requisito.

Melhor opção para programadores e produtos SaaS

O ZITADEL é a melhor opção quando a autenticação faz parte do produto que está a construir. O seu modelo de organizações, a multi-tenancy, as APIs e a superfície de automação fazem mais sentido quando utilizadores e tenants precisam de ser aprovisionados a partir do código da aplicação e não principalmente através de um painel de administração.

LER

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

Melhor opção para equipas empresariais ou com fortes exigências de conformidade

O Keycloak faz sentido quando a lista de requisitos inclui federação de diretórios complexa, vários realms, políticas de autorização detalhadas e uma equipa capaz de operar a complexidade IAM adicional. Auto-hospedar o Keycloak não torna um ambiente conforme por si só; cópias de segurança, disponibilidade, registo, revisões de acesso e controlo de alterações continuam a ser responsabilidade da sua equipa.

Melhor opção para aplicações sem SSO nativo

O Authelia é a escolha mais clara quando a autenticação tem de acontecer antes de os pedidos chegarem à aplicação. Funciona especialmente bem com proxies inversos que protegem ferramentas internas antigas, dashboards e serviços que não suportam OIDC nem SAML por si mesmos.

A parte difícil de auto-hospedar SSO

Depois de o SSO ser obrigatório, um erro de configuração ou uma recuperação falhada pode afetar várias aplicações de uma vez.

Instalação e configuração

Pôr os contentores a correr é apenas o primeiro passo. DNS, TLS, URIs de redirecionamento, claims de tokens, mapeamentos de grupos, entrega de email e acesso de recuperação são os pontos onde uma implementação de SSO começa a tornar-se infraestrutura em vez de mais uma aplicação Docker.

Recursos do servidor

O IdP é apenas parte do orçamento de recursos. PostgreSQL, proxies inversos, workers, hashing de palavras-passe, registos e sincronização de diretórios podem todos competir por CPU e memória quando partilham um VPS.

Gestão de base de dados e cópias de segurança

Authentik, ZITADEL e as implementações normais de produção do Keycloak dependem de uma base de dados. Faça cópia de segurança dessa base de dados fora do servidor, documente como restaurá-la e teste o restauro. Uma tarefa de cópia bem-sucedida não é o mesmo que um procedimento de recuperação que funciona.

Riscos de bloqueio e recuperação

Um URI de redirecionamento errado, um segredo de cliente expirado, uma ligação ao diretório quebrada ou uma política demasiado restritiva podem bloquear os administradores juntamente com toda a gente. Mantenha um caminho de recuperação que não dependa do fluxo de autenticação que está a tentar reparar.

Manter o IdP disponível

Uma falha do IdP não termina necessariamente de imediato todas as sessões de aplicação existentes. As sessões em curso podem continuar até os seus próprios tokens ou cookies expirarem, mas novos logins e renovações de tokens podem falhar. Teste esse modo de falha antes de tornar o SSO obrigatório em toda a stack.

Quando não deve auto-hospedar SSO

Auto-hospedar deixa de ser um bom negócio quando a sua equipa não consegue restaurar e operar a camada de identidade com a fiabilidade que as suas aplicações exigem.

Quando a identidade gerida é mais segura

A identidade gerida vale a pena quando o custo de operar o IdP é superior ao controlo que ganha ao auto-hospedá-lo. Serviços como Auth0, Clerk, WorkOS e Microsoft Entra ID transferem para o fornecedor grande parte da disponibilidade da plataforma, das correções e da manutenção da infraestrutura.

Continua responsável pela configuração das aplicações, pelas permissões e pelo planeamento da recuperação, mas já não por manter a própria plataforma de identidade online.

Quando a sua equipa não consegue lidar com uma paragem

Se ninguém na equipa consegue restaurar o IdP, reparar o PostgreSQL, substituir um segredo expirado ou diagnosticar uma ligação de federação falhada durante uma paragem, auto-hospedar a identidade pode ser o compromisso operacional errado.

A falha vai além de uma única aplicação indisponível. Novos logins e renovações de tokens em várias aplicações podem falhar ao mesmo tempo.

Quando as exigências de conformidade são demasiado altas

A identidade auto-hospedada pode ser usada em ambientes regulados, mas executar o software por conta própria não produz automaticamente os controlos ou as evidências que um auditor espera. A sua equipa continua responsável pelo registo, revisões de acesso, cópias de segurança, gestão de alterações, disponibilidade, resposta a incidentes e por toda a documentação que o enquadramento aplicável exigir.

O SSO auto-hospedado não é um símbolo de estatuto. Se a sua equipa não consegue operar a camada de identidade em segurança, pagar por identidade gerida pode ser a melhor decisão de engenharia.

Onde a Cloudzy ajuda

A Cloudzy muda a camada de implementação; não elimina o trabalho de configuração de identidade nem de operação descrito acima.

O problema da implementação manual de SSO

Uma implementação manual de SSO significa preparar o servidor, instalar a aplicação e a base de dados, configurar o proxy inverso, definir DNS e TLS e só então começar a configuração da identidade propriamente dita. Nada disso substitui o trabalho de OIDC, SAML, diretório ou políticas que vem a seguir.

Implementação de SSO com um clique na Cloudzy

A Cloudzy tem implementações com um clique para Authentik e Keycloak. A aplicação Authentik de um clique está no marketplace da Cloudzy. A aplicação Keycloak de um clique também está no marketplace da Cloudzy. O ZITADEL não está hoje no marketplace, por isso implemente-o com a sua configuração de Docker Compose num VPS padrão. A instalação com um clique põe a aplicação base a correr, enquanto a configuração de identidade, DNS, cópias de segurança, atualizações, políticas e testes de recuperação continuam sob o seu controlo.

Quando usar um VPS separado para o seu IdP

Alojar o IdP junto com as suas aplicações é razoável num homelab onde uma paragem é aceitável. Para uma stack crítica para o negócio, separar o fornecedor de identidade elimina um domínio de falha partilhado óbvio: reiniciar, esgotar ou comprometer o servidor de aplicações deixa de significar derrubar também a camada de identidade.

Um VPS separado não é o mesmo que alta disponibilidade, mas dá ao IdP o seu próprio orçamento de recursos, calendário de manutenção e fronteira de recuperação.

Recomendações de dimensionamento do VPS

Dimensione toda a stack, não apenas o processo do IdP, sobretudo quando o PostgreSQL e um proxy inverso partilham o mesmo VPS.

Requisitos de VPS para o Authentik

A documentação oficial de Docker Compose do Authentik exige um anfitrião com pelo menos 2 núcleos de CPU e 2 GB de RAM. Esse é o ponto de partida correto para uma implementação pequena. Dê mais margem ao servidor quando PostgreSQL, outposts adicionais, sincronização de diretórios ou tráfego de login mais pesado partilharem o mesmo anfitrião.

Requisitos de VPS para o ZITADEL

A implementação oficial de Docker Compose do ZITADEL exige pelo menos 2 GB de RAM para o anfitrião. Dimensione um VPS tudo-em-um para o ZITADEL, a sua interface de login, o PostgreSQL e o proxy inverso em conjunto, em vez de tratar o serviço Go isoladamente.

Requisitos de VPS para o Keycloak

A documentação de contentores do Keycloak recomenda um limite de memória de 2 GB para implementações Keycloak pequenas prontas para produção. Esse valor aplica-se apenas ao contentor do Keycloak, não a um VPS inteiro que também executa PostgreSQL.

Se o Keycloak e o PostgreSQL partilharem um VPS, 4 GB de RAM de sistema são um ponto de partida sensato. Trate isso como orientação prática para o anfitrião e não como o mínimo oficial do Keycloak.

Requisitos de VPS para o Authelia

O Authelia não publica um mínimo de servidor de 1 GB ou 2 GB diretamente comparável. Dimensione o anfitrião para o Authelia juntamente com o proxy inverso, o backend de armazenamento, o diretório de utilizadores e quaisquer outros serviços que partilhem a máquina.

O Authelia tem geralmente uma pegada de implementação menor do que um IdP completo ao lado do PostgreSQL, mas os requisitos reais de VPS dependem do resto da stack.

Exemplo de configuração: Authentik com Vaultwarden

O Vaultwarden adicionou suporte nativo de SSO OpenID Connect na versão 1.35.0, em dezembro de 2025. O Authentik é um exemplo útil porque a integração expõe as peças OIDC que também vai encontrar noutras aplicações: URIs de redirecionamento, credenciais de cliente, scopes, URLs de emissor e acesso de recuperação.

Configuração básica do Authentik

No Authentik:

1. Crie um mapeamento de scope de email personalizado para o Vaultwarden. O Vaultwarden exige que o scope email devolva email_verified: true ou nenhum valor email_verified, enquanto o scope de email predefinido do Authentik devolve atualmente false.
2. Crie um par aplicação e fornecedor OAuth2/OpenID Connect.
3. Adicione https://vault.example.com/identity/connect/oidc-signin como URI de redirecionamento estrito do tipo Authorization.
4. Selecione qualquer chave de assinatura disponível.
5. Anote o Client ID, o Client Secret e o slug da aplicação.
6. Defina a validade do token de acesso para mais de cinco minutos.
7. Adicione o mapeamento offline_access do Authentik aos scopes selecionados.
8. Substitua o mapeamento de email predefinido pelo mapeamento personalizado de email verificado do passo 1.

Configuração OIDC básica do Vaultwarden

Use:

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

Substitua os domínios de exemplo, o slug da aplicação, o ID de cliente e o segredo de cliente pelos valores da sua própria implementação e reinicie o Vaultwarden.

LER

Auto-Hospedar o Gestor de Palavras-Passe Bitwarden: Guia Completo

O que testar antes de impor o SSO

Deixe SSO_ONLY definido como false enquanto testa login, logout, renovação de tokens, correspondência de contas e recuperação. Teste também o que acontece quando o Authentik está temporariamente indisponível.

Quando tanto o SSO como a recuperação funcionarem como esperado, pode decidir se exigir SSO em todos os logins faz sentido para a sua implementação.

Os mesmos conceitos OIDC aplicam-se a outras aplicações auto-hospedadas, mas os URIs de redirecionamento, scopes, claims e licenças diferem. Consulte a documentação de SSO de cada aplicação em vez de copiar diretamente a configuração do Vaultwarden.

Quando o Authelia é melhor do que um IdP completo

O Authelia torna-se mais atrativo quando a aplicação não precisa de todo de entender o fornecedor de identidade.

Autenticação no proxy inverso

O Authelia foi concebido principalmente para proteger aplicações na camada do proxy inverso. Define regras de controlo de acesso e o Authelia decide se um pedido deve chegar ao backend antes de a própria aplicação tratar da autenticação.

Proteger aplicações sem OIDC

Isto é útil para ferramentas internas antigas, dashboards e serviços que não suportam OIDC nem SAML. Em vez de modificar cada aplicação, pode colocar a autenticação à frente dela, no proxy inverso.

O Authelia também pode atuar como fornecedor OIDC, mas a autenticação no proxy inverso continua a ser o seu principal ponto forte.

Usar o Authelia em conjunto com o Authentik

Pode usar o Authentik para as aplicações que suportam OIDC ou SAML e o Authelia para as aplicações que precisam de autenticação no proxy inverso.

Não precisa necessariamente de ambos. O Authentik também suporta proteção de aplicações via proxy, por isso usar o Authelia ao lado dele só faz sentido quando o fluxo de proxy inverso do Authelia resolve de forma mais limpa uma parte específica da sua stack.

Perguntas frequentes

O Authentik é melhor do que o Keycloak?

Para a maioria dos homelabs e stacks pequenas de aplicações auto-hospedadas, o Authentik é mais acessível. O seu fluxo de administração concentra-se em aplicações, fornecedores, grupos e políticas sem expor tanta complexidade IAM de uma vez.

O Keycloak faz mais sentido quando precisa especificamente da sua federação mais profunda, do modelo de realms ou dos Authorization Services. O Authentik é a escolha predefinida mais sólida para SSO auto-hospedado mais simples; o Keycloak serve ambientes que precisam desses controlos adicionais.

O ZITADEL é melhor do que o Keycloak?

O ZITADEL é a melhor opção quando está a construir um produto e quer identidade orientada por API, organizações e multi-tenancy. O Keycloak é a melhor opção quando precisa do seu modelo de autorização mais profundo, dos extensos controlos de federação ou de um ambiente já construído em torno do Keycloak.

Qual é a diferença entre o Authentik e o Authelia?

O Authentik é um fornecedor de identidade completo construído em torno de utilizadores, grupos, aplicações, fornecedores, fluxos e políticas. As aplicações podem integrar-se com ele diretamente através de protocolos como OIDC e SAML.

O Authelia centra-se na autenticação e no controlo de acesso no proxy inverso. Também inclui um fornecedor OIDC, mas a proteção no proxy inverso continua a ser o seu principal caso de uso.

Escolha o Authentik quando as aplicações se integram diretamente com um IdP. Escolha o Authelia quando a autenticação precisa sobretudo de acontecer antes de o tráfego chegar à aplicação.

Posso correr o Authentik num VPS de 1 GB?

Não como ponto de partida suportado. A documentação atual de Docker Compose do Authentik exige pelo menos 2 núcleos de CPU e 2 GB de RAM. A implementação base atual usa o servidor Authentik, o worker e o PostgreSQL; o Redis foi completamente removido no Authentik 2025.10.

Use 2 GB como ponto de partida mínimo para uma instalação pequena e adicione margem quando outros serviços partilharem a máquina.

O Vaultwarden suporta SSO OIDC?

Sim. O Vaultwarden adicionou suporte de SSO OpenID Connect na versão 1.35.0, em dezembro de 2025. Requer um fornecedor OIDC externo como Authentik, Keycloak ou ZITADEL.

A configuração exata depende do fornecedor. Com as versões atuais do Authentik, a integração documentada inclui um mapeamento personalizado de scope de email verificado, offline_access, credenciais de cliente e o URL de emissor da aplicação Authentik.

Devo correr o meu IdP no mesmo VPS que as minhas aplicações?

Para um homelab onde uma paragem é aceitável, alojá-los juntos pode ser razoável. Para aplicações críticas para o negócio, um VPS separado dá ao fornecedor de identidade o seu próprio orçamento de recursos e retira o servidor de aplicações do domínio de falha partilhado.

Isso não cria alta disponibilidade por si só, mas um reinício do servidor de aplicações, um problema de recursos ou um comprometimento deixa de derrubar automaticamente o IdP.

Qual SSO auto-hospedado é o mais fácil de usar?

O Authentik é o ponto de partida mais fácil para a maioria das pessoas que ligam aplicações auto-hospedadas existentes. A sua interface de administração torna aplicações, fornecedores, grupos e políticas mais acessíveis do que o modelo mais amplo de realms e autorização do Keycloak.

O Authelia pode ser mais simples quando só precisa de autenticação no proxy inverso. O ZITADEL faz mais sentido quando a pessoa que configura a identidade é um programador que trabalha principalmente através de APIs.