Ferramentas de SSO e controle de acesso auto-hospedado

Um escritor do XDA recentemente descreveu quatro coisas que fez para proteger um servidor Plex antes de expô-lo à internet: aplicar TLS, parar de anunciar a porta 32400 direto pelo roteador, colocar a coisa atrás de um proxy reverso e ativar two-factor para a conta. Tudo sensato. Tudo incompleto. O proxy reverso encerra o TLS e roteia nomes de host, e então entrega a solicitação para o aplicativo, que fica decidir por conta própria se a pessoa do outro lado deve estar lá. Cada serviço acaba com sua própria página de login, suas próprias regras de senha e sua própria ideia do que significa “fazer logout”.

É essa lacuna que os melhores aplicativos de SSO auto-hospedado preenchem. Um provedor de identidade fica atrás do proxy reverso, cada serviço se reporta a ele, MFA é aplicada uma vez para tudo, e remover o acesso de alguém é um único toggle em vez de um passeio por doze painéis de administrador. Observamos 8 opções que estão sendo desenvolvidas ativamente e rodando em laboratórios caseiros reais hoje, desde provedores de identidade completos com seu próprio banco de dados até um único contêiner que responde uma pergunta sim-ou-não por requisição.

O que procurar em um aplicativo de SSO auto-hospedado

Comparação rápida

Aplicativo Melhor para Armazenamento de usuários próprio Protocolos Forward auth Licença
Authentik Um provedor de identidade completo com UI web Sim OIDC, SAML, LDAP, RADIUS Sim, proxy outpost MIT core, paid enterprise tier
Authelia Um portal leve ao lado do seu proxy reverso Sim, arquivo ou LDAP OIDC provider, forward auth Sim, native Apache 2.0
Tinyauth Obter qualquer login na frente de alguns aplicativos rapidamente Sim, plus OAuth e LDAP OIDC, forward auth Sim, native AGPL 3.0
LLDAP Um diretório compartilhado que outros podem ler Sim, apenas LDAP LDAP Não GPL 3.0
oauth2-proxy Aparafusando um IdP existente na frente de um aplicativo Não OIDC e OAuth2 client Sim, via nginx auth_request MIT
Zitadel Trilhas de auditoria e configurações multi-inquilino Sim OIDC, SAML, SCIM, LDAP Via OIDC AGPL 3.0
Keycloak Cobertura de protocolo e federação mais ampla Sim OIDC, SAML Via oauth2-proxy Apache 2.0
Pomerium Política decidida por requisição, não por login Não OIDC client É o proxy Apache 2.0

Por que a camada de identidade é aquela que as pessoas pulam

Os guias de proxy reverso estão em toda parte, e terminam no ponto onde o tráfego chega ao aplicativo. Guias de firewall terminam na porta. Nenhum responde a pergunta que importa quando um nome de host é público: quem é permitido, comprovado como e revogado quando.

O resultado é um laboratório caseiro onde o proxy reverso é bem configurado e os aplicativos atrás dele estão cada um protegidos por tudo que seu desenvolvedor enviou. Alguns têm TOTP. Alguns têm uma única senha de administrador compartilhada em uma variável de ambiente. Alguns têm um assistente de configuração que fica aberto até alguém visitá-lo. Um provedor de identidade na frente de todos eles transforma essa superfície desigual em uma única porta, e a porta é a única coisa que você precisa acertar.

Os aplicativos

1. Authentik: melhor em geral para SSO auto-hospedado

Authentik é aquele em que a maioria dos laboratórios caseiros acabam, e por uma boa razão: ele cobre ambos os lados do problema. Aplicativos que falam OIDC ou SAML conseguem um provedor de identidade apropriado com um endpoint de descoberta, claims de grupo e telas de consentimento. Aplicativos que não falam nada conseguem um proxy outpost, que seu proxy reverso chama como forward auth e que passa o nome de usuário e email autenticados como headers. Tudo é configurado através de uma UI web, incluindo o construtor de fluxo, que permite decidir exatamente quando MFA é exigida e quando uma sessão pode ser reutilizada. Inscrição, recuperação e redefinição de senha são self-service, o que importa quando alguém além de você precisa de uma conta.

Onde falha: é o mais pesado das opções leves. O deployment padrão é um contêiner de servidor, um contêiner de worker, Postgres e Redis, e o projeto pede aproximadamente 2 núcleos de CPU e 2 GB de RAM antes de adicionar qualquer coisa. O sistema de fluxo é poderoso e consequentemente fácil de configurar errado, e um fluxo de autenticação quebrado o bloqueia da interface de administrador tão efetivamente quanto todos os outros.

Custo: o núcleo é licenciado MIT e gratuito sem limites de usuários. Um tier de enterprise pago adiciona suporte e recursos voltados para empresas em vez de lares.

Plataformas: Docker ou Kubernetes em Linux, e Docker Desktop em Windows e macOS.

Baixar: goauthentik.io · GitHub

Conclusão: execute Authentik para SSO auto-hospedado se quiser um sistema que lide com aplicativos modernos e aqueles que nunca implementarão OIDC, e você tem RAM de sobra.

2. Authelia: melhor opção leve com configuração que você pode controlar versão

Authelia é um único binário Go que fica ao lado do seu proxy reverso e responde uma pergunta por requisição. Usuários vivem em um arquivo YAML ou diretório LDAP que Authelia não possui, regras de acesso vivem no mesmo YAML, e a configuração inteira é um artefato que você pode fazer commit em um repositório privado e restaurar em um minuto. Suporta TOTP, chaves de segurança WebAuthn, Duo push e passkeys, e é OpenID Certified como um provedor OIDC, então aplicativos que falam OIDC podem falar com ele diretamente em vez de via headers. Integrações de forward auth estão documentadas para nginx, Traefik, Caddy, HAProxy e Envoy.

Onde falha: não há UI de admin. Adicionar um usuário significa editar um arquivo e recarregar, o que é fine para um lar e doloroso para qualquer coisa maior. Redefinição de senha precisa de uma configuração de mail funcionando. A sintaxe de registro do cliente OIDC é inflexível, e um typo em um URI de redirecionamento produz uma mensagem de erro que não diz qual ponta está errada.

Custo: gratuito e licenciado Apache 2.0.

Plataformas: Docker ou um binário estático em Linux, plus Docker em Windows e macOS.

Baixar: authelia.com · GitHub

Conclusão: a escolha certa se suas regras de acesso são estáveis, você é confortável em YAML, e prefere fazer backup de um arquivo do que de um banco de dados.

3. Tinyauth: melhor para obter um login na frente das coisas esta noite

Tinyauth é o que você usa quando Authelia parece muita cerimônia. Um contêiner, uma config, e uma página de login na frente de qualquer coisa que seu proxy reverso roteia para ele. Ele lida com usuários locais, LDAP e logins OAuth de provedores como GitHub e Google, suporta TOTP e aplica regras de acesso por aplicativo. A versão 5.1.0 pegou OpenID Certification para o perfil Basic OP em meados de 2026, então não é mais apenas um shim forward-auth: aplicativos que falam OIDC podem usá-lo como seu provedor. Integrações documentadas cobrem Traefik, nginx e Caddy.

Onde falha: é jovem, e o projeto em si adverte que mudanças de configuração ocorrem frequentemente entre releases, então upgrades precisam ler notas de release em vez de puxar uma nova tag cegamente. Sem SAML, sem RADIUS, e sem inscrição self-service para pessoas que não estão no diretório. Se seu laboratório caseiro cresce além de um punhado de serviços com grupos distintos, você o superará.

Custo: gratuito e licenciado AGPL 3.0.

Plataformas: Docker em Linux, Windows e macOS.

Baixar: tinyauth.app · GitHub

Conclusão: a resposta honesta mais rápida para “não há login na frente disso em absoluto,” e pequeno o suficiente que custa quase nada rodando ao lado de algo maior depois.

4. LLDAP: melhor para um diretório de usuários que outros podem ler

LLDAP não é um portal SSO. É um pequeno servidor Rust que fala LDAP suficiente para outro software se autenticar contra, com uma UI web para gerenciar usuários e grupos e uma opção para usuários redefinir sua própria senha por email. Esse escopo estreito é o ponto: Authelia, Authentik, Keycloak, Nextcloud, Jellyfin e uma longa lista de aplicativos auto-hospedados podem todos ler dele, então você obtém um lugar onde contas são criadas e um lugar onde são desativadas. Armazena dados em SQLite por padrão, com MySQL, MariaDB e PostgreSQL como alternativas, e expõe uma API GraphQL se você gerencia usuários do código.

Onde falha: intencionalmente não é um servidor LDAP completo. Navegadores LDAP genéricos frequentemente falham contra ele, seu esquema de hash de senha significa que não pode distribuir hashes para outro serviço validar, e o projeto nomeia Synology como incompatível. Não faz nenhuma autorização por conta própria, então algo mais ainda precisa aplicar regras de acesso.

Custo: gratuito e licenciado GPL 3.0.

Plataformas: Docker ou um binário em Linux, e Docker em Windows e macOS.

Baixar: GitHub

Conclusão: emparelhe com Authelia ou Tinyauth quando quiser um diretório compartilhado sem ficar com um deployment LDAP real, e pule inteiramente se seu provedor de identidade já possui seus usuários.

5. oauth2-proxy: melhor para colocar um IdP que você já executa na frente de um aplicativo

oauth2-proxy não possui contas próprias. É um cliente que envia visitantes para um provedor OIDC ou OAuth2 que você já tem, verifica o resultado, e então ou faz proxy da requisição para seu aplicativo ou responde a auth_request do nginx com um sim ou não. Suporta OIDC genérico ao lado de integrações dedicadas para Google, Microsoft Entra ID, GitHub e outros, e implementações específicas de provedor podem extrair membros do grupo e repassá-lo como headers. É um projeto CNCF Sandbox e vem fazendo silenciosamente este trabalho há anos.

Onde falha: resolve exatamente um problema e espera que você tenha resolvido os outros. Sem gerenciamento de usuários, sem MFA próprio, e sem mecanismo de política além de listas de permissão de emails, domínios e grupos. Obter claims de grupo através de um aplicativo significa combinar manualmente os nomes de claim do seu provedor, e o modo de falha é um login bem-sucedido sem permissões.

Custo: gratuito e licenciado MIT.

Plataformas: Docker ou um binário em Linux, macOS e Windows.

Baixar: oauth2-proxy docs · GitHub

Conclusão: a escolha certa quando você já está executando Authentik, Keycloak ou Zitadel e precisa que um aplicativo teimoso o respeite.

6. Zitadel: melhor quando você quer um rastreamento de auditoria de cada evento de identidade

Zitadel é uma plataforma de identidade Go construída em event sourcing, o que significa que cada mudança para um usuário, um papel ou uma sessão é armazenada como um evento imutável em vez de uma linha atualizada. Para um laboratório caseiro isso soa como overengineering até a primeira vez que você precisa responder quando uma conta foi criada e por quem. Cobre OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0 e LDAP, suporta OTP via app, email e SMS, plus U2F e passkeys FIDO2, e é multi-tenant desde o início se você hospeda serviços para mais de um lar ou negócio secundário.

Onde falha: requer PostgreSQL 14 ou posterior, e a configuração assume que você entende o modelo de organização e projeto antes de criar seu primeiro aplicativo. O design API-first é excelente se você programa sua infraestrutura e mais pesado do que necessário se você só quer uma página de login. Auto-hospedagem é AGPL 3.0, que vale a pena ler se você planeja construir algo comercial em cima.

Custo: gratuito para auto-hospedagem. O serviço hospedado é faturado separadamente.

Plataformas: Docker ou Kubernetes em Linux, plus binários para Linux e macOS.

Baixar: zitadel.com · GitHub

Conclusão: escolha Zitadel sobre Authentik quando logging de estilo compliance ou multi-tenancy é um requisito real em vez de uma boa ideia.

7. Keycloak: melhor para cobertura de protocolo e federação mais ampla

Keycloak é a opção empresarial, agora um projeto CNCF com mais de uma década de uso em produção atrás. Se algum software suporta SSO em tudo, quase certamente documenta uma integração Keycloak. Ele se federas contra LDAP e Active Directory existentes, corretores para provedores externos, faz autorização fine-grained com seu próprio mecanismo de política, e lida com os cantos SAML incômodos que ferramentas mais leves pulam. Começar é genuinamente rápido com start-dev em Docker, que roda contra um banco de dados incorporado para avaliação.

Onde falha: start-dev não é uma configuração de produção, e passar para uma significa um banco de dados externo, uma configuração de nome de host que faz quase todos tropeçarem a primeira vez, e um runtime Java cujo uso de memória começa onde Authelia termina. Não tem seu próprio modo forward-auth, então aplicativos que não falam OIDC ou SAML precisam de oauth2-proxy na frente. O console de administrador assume um vocabulário (realms, clients, mappers) que nenhum guia de laboratório caseiro o teria ensinado.

Custo: gratuito e licenciado Apache 2.0.

Plataformas: Docker ou uma distribuição Java em Linux, Windows e macOS.

Baixar: keycloak.org · GitHub

Conclusão: vale a pena o custo de setup se você precisa de federação SAML ou está praticando para a mesma stack no trabalho, e é difícil justificar para seis contêineres atrás do Traefik.

8. Pomerium: melhor para política decidida por requisição, não por login

Pomerium inverte o arranjo habitual. Em vez de um provedor de identidade que concede uma sessão e um proxy que confia nela, Pomerium é o proxy, e avalia uma política em cada requisição única usando identidade de um provedor OIDC upstream plus contexto sobre a requisição em si. Políticas são escritas como configuração em vez de clicadas juntas, então regras de acesso vivem no mesmo repositório que o resto da sua infraestrutura. É clientless, significando ninguém precisa instalar um app VPN para chegar a um serviço interno, e é licenciado Apache 2.0 com um plano de controle gerenciado vendido separadamente para organizações que querem uma GUI.

Onde falha: não possui usuários, então você ainda precisa de Authentik, Keycloak, Zitadel ou um provedor hospedado atrás. O deployment típico é mais de um contêiner com armazenamento persistente. E porque substitui seu proxy reverso em vez de ficar ao lado, adotar Pomerium significa refazer roteamento e certificados que já funcionam, o que é muita interferência para um laboratório caseiro que só quer uma página de login.

Custo: gratuito e open source para auto-hospedagem. O plano de controle hospedado é um produto pago.

Plataformas: Docker ou Kubernetes em Linux, plus binários para Linux e macOS.

Baixar: pomerium.com · GitHub

Conclusão: escolha quando decisões de acesso precisem considerar mais que “essa pessoa fez login uma hora atrás,” e overengineer para qualquer coisa menor.

O atrito que ninguém menciona nos guias de configuração

Metade dos seus aplicativos não falam OIDC. Forward auth é o fallback: o proxy reverso pergunta ao provedor de identidade, e em sucesso passa headers como Remote-User e Remote-Email para o aplicativo. Isso só funciona se o aplicativo pode ser configurado para confiar nesses headers, e é apenas seguro se o aplicativo não é acessível exceto através do proxy. Vincule o contêiner a uma rede Docker interna em vez de uma porta de host, porque um aplicativo que confia em headers de identidade confiará neles de qualquer um que possa alcançá-lo diretamente.

Quando o provedor de identidade está inativo, tudo está inativo. Postgres preenche um disco, uma atualização de contêiner falha, um certificado expira, e de repente nada em casa faz login. Decida o caminho de break-glass antes de precisar: mantenha pelo menos uma rota para sua infraestrutura que não atravesse o provedor de identidade, como SSH sobre uma VPN de malha ou acesso de console na rede local, e saiba qual serviço você temporariamente excluiria de forward auth para restaurar o resto. Escreva em algum lugar que não está atrás do login que você acabou de perder.

Backups devem cobrir o armazenamento de identidade, não apenas a configuração. Para Authelia o estado é um arquivo YAML mais um pequeno banco de dados de registros TOTP e WebAuthn. Para Authentik, Zitadel ou Keycloak é um banco de dados Postgres mais uma chave secreta, e restaurar o banco sem a chave secreta correspondente lhe dá um serviço que inicia e depois recusa cada sessão. Despeje o banco de dados em um cronograma, armazene a chave secreta separadamente, e teste uma restauração uma vez em vez de descobrir a lacuna durante uma interrupção.

SSO na frente de um servidor de mídia quebra aplicativos nativos. Esta é a armadilha específica no cenário Plex. Um app de TV ou cliente móvel não consegue completar um fluxo de login baseado em navegador, então colocar forward auth em todo o nome de host detém esses clientes de se conectarem em absoluto. A solução habitual é excluir caminhos de API do SSO, que silenciosamente o leva de volta à autenticação do servidor de mídia para exatamente o tráfego que carrega sua biblioteca. A resposta mais limpa é manter o tráfego de cliente nativo em uma VPN de malha e aplicar SSO apenas à interface web, ou usar um provedor de identidade que o servidor de mídia suporta diretamente em vez de embrulhá-lo de fora.

Nunca faça o provedor de identidade o elo mais fraco. Sua interface de administrador deve ser acessível apenas pela sua rede interna ou sobre VPN, MFA deve ser obrigatório para cada conta que pode mudar a política, e verificação de certificado fica em todo lugar. Um provedor de identidade mal configurado é pior que nenhum, porque concentra acesso em vez de distribuir.

Como escolher o certo

Para a maioria das pessoas abrindo um servidor caseiro para a internet pela primeira vez, a resposta honesta é Authentik se o hardware pode suportá-lo, e Authelia se não conseguir. Ambos lhe dão um login, MFA aplicada, e um lugar para revogar acesso, que é o ponto inteiro.

FAQ

Qual é a melhor solução SSO auto-hospedado para um laboratório caseiro?

Authentik cobre a gama mais ampla de situações, porque funciona como um provedor de identidade completo para aplicativos que falam OIDC ou SAML e como um gateway forward-auth para aplicativos que não falam nenhum. Authelia é uma opção melhor em hardware limitado ou quando você quer toda a configuração em um arquivo controlado por versão. Ambos são gratuitos e ambos aplicam MFA em cada serviço atrás deles.

Preciso de SSO se meu proxy reverso já tem TLS e senha?

Eles resolvem problemas diferentes. TLS protege o tráfego em trânsito e basic auth protege um único nome de host com um segredo compartilhado que não pode ser revogado por pessoa ou apoiado por MFA. SSO dá a cada pessoa sua própria identidade, aplica um segundo fator uma vez para tudo, e permite que você remova acesso em um lugar. Um proxy reverso é onde SSO é aplicado, não um substituto para ele.

Posso colocar SSO na frente do Plex ou Jellyfin?

Parcialmente. A interface web funciona bem atrás de forward auth. Aplicativos nativos em telefones, TVs e set-top boxes não conseguem completar um fluxo de login baseado em navegador, então eles quebram a menos que você exclua os caminhos da API, o que enfraquece a proteção para o tráfego que mais importa. Mantenha clientes nativos em uma VPN de malha e proteja a interface web com SSO, ou use um provedor de identidade que o servidor de mídia integra diretamente.

O que acontece se meu provedor de identidade fica offline?

Cada serviço atrás para de aceitar logins, e as sessões existentes expiram em seu cronograma normal. Planeje: mantenha acesso de rede local ou VPN para seu host que não dependa do provedor de identidade, mantenha uma forma documentada de desativar forward auth em um serviço, e armazene códigos de recuperação e backups de banco de dados em algum lugar acessível sem fazer login.

Keycloak é overkill para um servidor caseiro?

Geralmente, sim. Os pontos fortes do Keycloak são federação SAML, brokering para provedores externos e autorização fine-grained em escala organizacional, e seu custo é um runtime Java, um banco de dados externo e um vocabulário que você precisa aprender primeiro. Para uma dúzia de contêineres atrás de um proxy reverso, Authentik ou Authelia entregam o mesmo resultado prático com muito menos configuração.

Essas ferramentas armazenam minhas senhas, e como faço backup?

Authentik, Authelia, Zitadel, Keycloak, LLDAP e Tinyauth todos armazenam credenciais de alguma forma. oauth2-proxy e Pomerium não armazenam nada e delegam upstream. Para aqueles que o fazem, faça backup do banco de dados ou arquivo de configuração junto com a chave secreta da instância, porque uma restauração sem a chave secreta correspondente invalida cada sessão e segundo fator inscrito.