Imposto do SSO: OIDC e SAML em planos pagos

O que é o imposto do SSO

O imposto do SSO em software autoalojado é o padrão em que a aplicação é gratuita, mas o início de sessão único (SSO) é a única funcionalidade que tem de comprar. Pode executar tudo no seu próprio VPS, sem uma chave de licença e sem limite de utilizadores. Depois, abre a página de autenticação na documentação e encontra OpenID Connect (OIDC) ou SAML (security assertion markup language) incluído num plano pago.

Isto é mais importante do que uma funcionalidade comum bloqueada por pagamento, porque o SSO é o que faz um conjunto de serviços autoalojados comportar-se como um único sistema. Um fornecedor de identidade (IdP) fornece uma conta por pessoa, uma política de palavras-passe, um único local para ativar a autenticação multifator (MFA) e um único local para desativar o acesso de alguém. Sem isso, cada aplicação mantém a sua própria pequena base de dados de utilizadores, e tem de gerir cada uma manualmente.

Este padrão é suficientemente antigo para ter um registo público. O SSO Wall of Shame em sso.tax lista fornecedores que cobram um prémio elevado pelo início de sessão único, com entradas desde 2018, e o seu autor define um critério razoável: "Se o suporte para SSO aumentar o preço em 10%, não está nesta lista." A maior parte dessa lista é composta por software fechado. A mesma lógica de preços surge agora em projetos de código aberto que aloja por conta própria.

Por que os mantenedores colocam o início de sessão único numa modalidade paga

Há duas razões, e ambas são legítimas. O SSO é dispendioso de suportar e é uma das poucas funcionalidades pelas quais uma organização grande está disposta a pagar.

O custo do suporte é real porque uma integração de identidade nunca fica concluída. Cada IdP formata as suas claims de forma ligeiramente diferente. O mapeamento de grupos, a duração da sessão, os URLs de redirecionamento e a diferença de relógio podem causar problemas de início de sessão. Um problema de início de sessão bloqueia todos os utilizadores ao mesmo tempo, pelo que esses pedidos de suporte são urgentes. Depois surgem os pedidos relacionados: grupos aninhados, mapeamento de funções, aprovisionamento automático com SCIM (system for cross-domain identity management) e logs de auditoria que uma equipa de conformidade irá consultar.

A vertente da receita resulta de uma questão aritmética, não de malícia. Uma empresa que não consiga ligar a aplicação ao seu próprio IdP não a implementará de todo. Por isso, o SSO estabelece uma separação clara entre o utilizador que paga e o que não paga. Um projeto open core tem de colocar essa separação em algum ponto. O SSO adapta-se a esse modelo melhor do que quase qualquer outra funcionalidade, razão pela qual tantos projetos o escolhem.

Há uma correção a fazer à queixa habitual: consulte o changelog antes de presumir que uma funcionalidade foi removida, porque uma remoção aparece nas release notes. Nos projetos que analisei para este artigo, as funcionalidades de SSO pagas foram desenvolvidas para a modalidade paga desde o início. Não encontrei nenhum caso em que um SSO gratuito funcional tenha sido retirado. O Grafana é um exemplo típico. A sua página sobre SAML inclui uma nota de uma linha: "Available in Grafana Enterprise and Grafana Cloud". Já o OAuth genérico contra o seu próprio issuer funciona na versão open source.

O custo real do SSO

O dinheiro é a parte menor. Os planos pagos são vendidos por utilizador, por isso a fatura cresce com a equipa, enquanto o alojamento e as atualizações continuam a ser responsabilidade sua.

O custo maior é o trabalho manual de gestão de identidades, que surge em quatro áreas.

• Um armazenamento de palavras-passe por aplicação, pelo que uma palavra-passe reutilizada cria uma falha em todas as aplicações que a partilham.
• Desativação de acessos feita de memória. Tem de se lembrar de todos os serviços a que uma pessoa teve acesso, e o serviço que esquecer é precisamente o que pode causar problemas.
• MFA configurado aplicação a aplicação, quando a aplicação sequer o suporta.
• Logins partilhados, que é o que acaba por acontecer em equipas pequenas sujeitas a esta pressão.

Este último ponto merece uma frase própria. Quando uma equipa partilha uma conta de administrador num gestor de documentos, o registo de auditoria associa tudo a um único nome, pelo que não é possível saber quem eliminou a fatura. As permissões por utilizador também deixam de funcionar, porque existe apenas um utilizador. Esse é o verdadeiro impacto do custo do SSO: empurra as equipas pequenas para uma única conta partilhada, que é pior do que qualquer uma das alternativas.

Checklist para executar antes de adotar qualquer ferramenta

Execute esta verificação antes de docker compose up, não depois de a aplicação armazenar 400 documentos.

1. Abra a página de autenticação na documentação e leia a nota sobre os níveis no topo. As funcionalidades pagas têm um distintivo ou uma frase de disponibilidade.
2. Confirme que a aplicação comunica por OIDC ou SAML com o seu próprio issuer, em vez de usar uma lista fixa de fornecedores públicos.
3. Verifique o mapeamento de funções e grupos. Criar o utilizador é metade do trabalho. Atribuir permissões manualmente em 10 aplicações é a metade mais difícil.
4. Verifique se a aplicação aceita, num cabeçalho enviado por um proxy confiável, um nome de utilizador autenticado e se pode definir explicitamente em qual proxy confia.
5. Leia o histórico da licença no git e verifique se os contribuidores assinam um CLA (contributor licence agreement).
6. Verifique o processo de desativação de utilizadores. Descubra o que acontece aos tokens de API (application programming interface) e às sessões ativas quando a conta no IdP é desativada.

O item 2 é onde ocorre a maior parte das desilusões. Um botão "Iniciar sessão com Google" não é OIDC com o seu fornecedor de identidade. É uma integração fixa com um único fornecedor. O suporte real pede um URL de issuer. Tudo o resto vem da descoberta. Pode confirmar o lado do seu fornecedor com um comando.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Um fornecedor funcional devolve 3 URLs. Um resultado vazio ou um erro 404 normalmente significa que o caminho de descoberta está errado. Esse caminho depende do fornecedor: o Keycloak publica-o em /realms/<realm>/.well-known/openid-configuration. Se a aplicação não tiver sequer um campo para um URL de issuer, não consegue comunicar com o seu IdP, independentemente do que indique a lista de funcionalidades.

O item 6 apanha muitas pessoas semanas depois de alguém sair da organização. Desativar a conta no IdP impede novos inícios de sessão. Isso não revoga um token de API emitido anteriormente pela aplicação, porque a própria aplicação valida esse token e nunca consulta o IdP. O processo de desativação tem, portanto, 2 passos: desativar a conta no IdP e, depois, eliminar o utilizador ou os respetivos tokens dentro de cada aplicação.

O que os níveis realmente indicam

Estes dados foram confirmados na documentação de cada projeto em agosto de 2026. Comece pelas opções pagas.

O Grafana apresenta o SAML como "Available in Grafana Enterprise and Grafana Cloud", juntamente com a sincronização de equipas e o aprovisionamento SCIM. O OAuth genérico, o GitHub OAuth, o LDAP (lightweight directory access protocol) e o auth proxy estão todos incluídos na versão open source. Assim, quem aloja um serviço pequeno ainda pode iniciar sessão através do seu próprio fornecedor. A funcionalidade paga começa no SAML, e não no single sign-on em geral. Esta é a nuance que a expressão "SSO tax" tende a simplificar demasiado.

O Metabase é mais direto. A documentação afirma: "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." A edição open source mantém o início de sessão por palavra-passe e o LDAP.

O Passbolt identifica a documentação de SSO como Pro e Cloud. Por isso, a edição community não inclui esta funcionalidade. Os fornecedores documentados incluem Keycloak e Entra ID.

Agora, o outro lado, porque este padrão está longe de ser universal.

• O GitLab Self-Managed apresenta "Tier: Free, Premium, Ultimate" na página de SAML. Assim, usar SAML com o seu próprio GitLab não tem custos.
• O Paperless-ngx configura OIDC através do django-allauth com PAPERLESS_SOCIALACCOUNT_PROVIDERS, oculta o formulário de início de sessão local com PAPERLESS_DISABLE_REGULAR_LOGIN e associa claims a grupos com PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• O Planka aceita OIDC_ISSUER, OIDC_CLIENT_ID e OIDC_CLIENT_SECRET, define por predefinição os seus scopes como openid profile email e promove administradores a partir de uma role claim com OIDC_ADMIN_ROLES.
• O BookStack ativa a funcionalidade com AUTH_METHOD=oidc e associa os grupos do fornecedor às suas próprias roles com OIDC_USER_TO_GROUPS=true e OIDC_GROUPS_CLAIM.
• O Vaultwarden adicionou "support for SSO with OpenID Connect" na versão 1.35.0, em 27 December 2025, através de um pull request de um colaborador que mantinha a funcionalidade num fork.
• O listmonk inclui início de sessão OIDC juntamente com as suas user roles desde a versão 4.0.0.

Use esta informação quando estiver a escolher, e não depois de se comprometer com uma opção. Um quadro kanban Planka e as outras alternativas self-hosted ao Trello não tratam a identidade da mesma forma. O mesmo acontece com BookStack, Wiki.js e Outline. O OIDC gratuito é uma funcionalidade que pode avaliar tal como os limites de armazenamento ou os clientes móveis. Se ainda estiver a preparar a lista, o que alojar por conta própria em 2026 é um ponto de partida razoável. Tanto o gestor de documentos Paperless-ngx como o Vaultwarden oferecem OIDC gratuito atualmente.

Por que um reverse proxy à frente da aplicação não é single sign-on

A solução habitual é usar autenticação encaminhada. O reverse proxy retém cada pedido, pergunta a um serviço de autenticação se este navegador tem uma sessão iniciada e só depois encaminha o pedido para a aplicação. O authentik chama a isto um proxy provider, com um modo de forward auth para uma única aplicação e outro para um domínio inteiro. O Authelia e o oauth2-proxy fazem o mesmo trabalho.

Um bloco de site do Caddy tem este aspeto, seguindo o exemplo do próprio authentik.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

A capitalização dos nomes destes cabeçalhos é importante no Caddy, porque um nome diferente chega vazio. Em cada pedido que aprova, o outpost define X-authentik-username, X-authentik-email, X-authentik-groups e mais alguns.

Eis o que isto permite. Ninguém chega à aplicação sem passar primeiro pelo seu fornecedor de identidade. Assim, um formulário de início de sessão sem correções já não fica exposto à Internet, e a MFA aplica-se de uma só vez a tudo o que está atrás do proxy.

Eis o que isto não permite: estabelecer a identidade dentro da aplicação. A aplicação continua a ter as suas próprias contas e a sua própria noção de quem tem uma sessão iniciada. Se todas as pessoas passarem pelo proxy e chegarem à mesma conta de administrador partilhada, terá uma entrada protegida e uma única sessão anónima atrás dela. O log de auditoria continuará a mostrar um único nome. As permissões continuarão sem poder variar entre pessoas. Chamar SSO a esta configuração é um erro de segurança, porque o processo de remoção de acessos só é parcialmente eficaz: remover a pessoa do seu IdP fecha a entrada, mas um token de API que ela tenha criado dentro da aplicação continuará a funcionar para qualquer pessoa que consiga aceder diretamente à aplicação.

Como tornar a autenticação por cabeçalho segura

Algumas aplicações aceitam um nome de utilizador enviado pelo proxy. Isto fornece uma identidade por utilizador sem um SSO pago. A definição tem um nome diferente em cada projeto.

O Grafana chama-lhe auth proxy e é fornecida desativada. O nome do cabeçalho predefinido é X-WEBAUTH-USER. Pode configurá-la para usar qualquer cabeçalho definido pelo seu proxy.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist é a linha que muitas pessoas ignoram. A documentação do Grafana é explícita: esta definição existe para impedir que os utilizadores falsifiquem o cabeçalho. Por isso, deve conter apenas o endereço do seu proxy. O Gitea tem a mesma funcionalidade com nomes diferentes e é fornecido com uma predefinição mais segura.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES tem o valor predefinido 127.0.0.0/8,::1/128. REVERSE_PROXY_LIMIT define quantos proxies o Gitea irá considerar fiáveis na cadeia. Definir esse limite como zero desativa completamente o processamento do cabeçalho.

O Paperless-ngx disponibiliza PAPERLESS_ENABLE_HTTP_REMOTE_USER com PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. A documentação inclui o aviso aplicável a todas estas definições:

Isto permite autenticar simplesmente adicionando um cabeçalho Remote-User: <username> a um pedido. Utilize com cuidado!

Duas regras mantêm a autenticação por cabeçalho segura, e ambas dizem respeito à acessibilidade. Primeiro, a aplicação deve estar inacessível, exceto através do proxy. Qualquer pessoa que consiga abrir um socket para a aplicação pode enviar esse cabeçalho e assumir a identidade de qualquer utilizador. No Docker, ports: ["8000:8000"] publica em todas as interfaces. Por isso, associe-o ao endereço de loopback com ports: ["127.0.0.1:8000:8000"] ou remova a porta publicada e coloque o proxy na mesma rede Docker. Segundo, o proxy deve eliminar qualquer cópia do cabeçalho recebida do cliente. Assim, o único valor que a aplicação vê é o valor definido pelo proxy depois da autenticação.

Verifique ambos. Execute o primeiro comando numa máquina fora do seu VPS e o segundo no próprio servidor.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

O curl deve falhar ao estabelecer a ligação, e ss deve apresentar 127.0.0.1:8000 em vez de 0.0.0.0:8000. Se a primeira linha for HTTP/1.1 302 Found, a aplicação está a responder diretamente à Internet pública. Nesse caso, qualquer pessoa pode iniciar sessão como qualquer utilizador, indicando o nome desse utilizador num cabeçalho.

Quando não há SSO gratuito, decida em vez de reclamar

Quatro opções, pela ordem em que eu as tentaria.

1. Escolha a aplicação que inclui OIDC. Quando dois projetos fazem o mesmo trabalho e um deles comunica gratuitamente com o seu fornecedor de identidade, essa é uma diferença real no custo de operação.
2. Use forward auth de forma objetiva. Para uma ferramenta de administração com uma conta e um operador, um proxy à frente é suficiente, e a identidade de cada utilizador dentro da aplicação não traz qualquer benefício.
3. Pague. Se a aplicação for central para o seu trabalho e o preço por utilizador for compatível com o tamanho da sua equipa, o dinheiro ajuda a manter o projeto, e a alternativa é pagar com as suas noites.
4. Contacte o projeto upstream depois de pesquisar o issue tracker. O suporte de OIDC do Vaultwarden surgiu através de um fork de um contribuidor e de um pull request que se manteve aberto durante muito tempo. Por isso, um pedido de funcionalidade acompanhado de uma implementação funcional pode, por vezes, chegar à edição gratuita.

Nada disto funciona sem um fornecedor de identidade próprio, e essa é a peça que deve construir primeiro. Executar o authentik numa VPS fornece um fornecedor de OIDC e SAML, além do outpost de forward auth usado acima. A comparação entre Keycloak, authentik e Zitadel apresenta os compromissos envolvidos caso prefira ainda não assumir esse compromisso.

Histórico de licenças e por que ele está na checklist

O último item da checklist trata do futuro, porque a organização atual dos níveis é apenas um retrato momentâneo. Dois casos bem documentados mostram a rapidez com que esse cenário pode mudar, em ambas as direções. A HashiCorp adotou a Business Source License 1.1 para todos os lançamentos futuros em 10 August 2023, enquanto os lançamentos anteriores continuaram sob a MPL 2.0 (Mozilla Public License). A Redis mudou para a SSPL (server side public license) em March 2024 e anunciou em 1 May 2025 que a Redis 8 também seria distribuída sob a AGPLv3 (GNU Affero General Public License).

Considere os dois casos como evidências sobre o mecanismo, não sobre a motivação. A licença que você consulta hoje se aplica à versão que instala hoje, e um projeto que detém todos os direitos autorais pode alterar unilateralmente os termos do próximo lançamento. É por isso que a questão da CLA está na checklist, pois a cessão ampla de direitos autorais é o que torna possível uma relicenciamento unilateral.

Verifique você mesmo o histórico de um projeto antes de adotá-lo como base.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Uma lista curta de commits, principalmente do primeiro import, é um bom sinal. Várias reescritas do arquivo de licença significam que você deve ler a mensagem de cada commit antes de planejar com base nos termos atuais.

FAQ

Qual é o custo do SSO?

O custo do SSO é a prática de cobrar pelo single sign-on como funcionalidade premium, enquanto o restante do produto é gratuito ou barato. Em software self-hosted, isto aparece como uma aplicação open source que pode ser executada sem uma chave de licença, mas em que o login OIDC ou SAML está incluído num plano pago. O nome vem do SSO Wall of Shame em sso.tax, que acompanha fornecedores que cobram um valor elevado por esta funcionalidade. Para quem aloja os próprios serviços, a consequência é cada aplicação manter a sua própria base de dados de utilizadores, pelo que as contas têm de ser criadas e removidas manualmente.

Um reverse proxy com forward auth é o mesmo que SSO?

Não. O forward auth protege a entrada: o proxy consulta o fornecedor de identidade antes de qualquer pedido chegar à aplicação. A aplicação continua a utilizar as suas próprias contas. Se todos entrarem com um único login partilhado, obtém uma única sessão anónima e um log de auditoria com apenas um nome. Só existe identidade individual real quando a aplicação lê o nome de utilizador a partir de um cabeçalho. O auth proxy do Grafana, a autenticação de reverse proxy do Gitea e o PAPERLESS_ENABLE_HTTP_REMOTE_USER do Paperless-ngx conseguem fazer isso. Estas definições só são seguras enquanto a aplicação não puder ser acedida sem passar pelo proxy, porque o cabeçalho é uma cadeia de texto simples que qualquer cliente pode enviar.

Que aplicações self-hosted incluem OIDC na edição gratuita?

Verificado na documentação dos projetos em agosto de 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk e Vaultwarden suportam OIDC nas suas versões gratuitas, e o GitLab Self-Managed indica SAML no nível Tier: Free. A versão open source do Grafana suporta OAuth genérico com o seu próprio issuer, enquanto o SAML é uma funcionalidade Enterprise. Confirme na página de autenticação do próprio projeto antes de instalar, porque estas listas mudam com os releases.

Devo pagar pelo plano que desbloqueia o single sign-on?

Decida com base em dois números: quantas pessoas precisam de contas e quantas aplicações teria de administrar manualmente. Para um ou dois administradores, o forward auth à frente de uma conta local é suficiente, e o plano pago oferece pouco benefício. Numa equipa em que as pessoas entram e saem, uma conta esquecida durante a remoção de acessos custa mais do que a licença, e o pagamento financia a manutenção de que depende. Se o preço não for adequado, a opção prática é escolher uma aplicação que inclua OIDC, em vez de contornar as limitações de uma aplicação que não o inclua.