Il costo dell’SSO nel software self-hosted

Qual è il costo dell’SSO

Nel software self-hosted, il costo dell’SSO è il modello in cui l’applicazione è gratuita, ma il single sign-on (SSO) è l’unica funzionalità da acquistare. Puoi eseguire l’intero sistema sul tuo VPS senza chiavi di licenza e senza limiti sul numero di utenti. Poi apri nella documentazione la pagina relativa all’autenticazione e trovi OpenID Connect (OIDC) o SAML (Security Assertion Markup Language) inclusi in un piano a pagamento.

Questo aspetto è più importante di una normale funzionalità soggetta a pagamento, perché l’SSO permette a un insieme di servizi self-hosted di comportarsi come un unico sistema. Un identity provider (IdP) ti offre un account per ogni persona, un’unica policy per le password, un unico punto in cui abilitare l’autenticazione a più fattori (MFA) e un unico punto in cui disabilitare l’accesso di un utente. Senza un IdP, ogni applicazione mantiene un piccolo database locale degli utenti e devi amministrarlo manualmente.

Questo modello è abbastanza diffuso da avere una classifica pubblica. La SSO Wall of Shame disponibile su sso.tax elenca i vendor che applicano un sovrapprezzo elevato per il single sign-on, con voci risalenti al 2018. Il suo autore definisce una soglia ragionevole: "Se il supporto SSO comporta un aumento del prezzo del 10%, non compari in questo elenco." La maggior parte dei prodotti presenti nell’elenco è software proprietario. La stessa logica di prezzo compare ora anche nei progetti open source che ospiti in autonomia.

Perché i maintainer inseriscono il single sign-on in un piano a pagamento

Ci sono due motivi, ed entrambi sono legittimi. Il supporto per SSO è costoso e si tratta di una delle poche funzionalità per cui una grande organizzazione è disposta a pagare.

Il costo del supporto è reale, perché un'integrazione con un identity provider non è mai davvero conclusa. Ogni IdP formatta le proprie claim in modo leggermente diverso. Il mapping dei gruppi, la durata delle sessioni, gli URL di redirect e la differenza tra gli orologi producono ciascuno problemi di login. Un problema di login blocca contemporaneamente tutti gli utenti, quindi queste richieste di assistenza sono urgenti. Poi arrivano le richieste successive: gruppi annidati, mapping dei ruoli, provisioning automatico con SCIM (system for cross-domain identity management) e audit log che verranno esaminati dal team di conformità.

Il lato dei ricavi è una questione aritmetica, non di malafede. Un'azienda che non può collegare l'applicazione al proprio IdP non la distribuirà affatto. Per questo SSO traccia una separazione netta tra l'utente che paga e quello che non paga. Un progetto open core deve collocare quella separazione da qualche parte. SSO si presta meglio di quasi qualsiasi altra funzionalità, ed è per questo che molti progetti scelgono questa soluzione.

È necessaria una correzione alla contestazione più comune: controllate il changelog prima di presumere che una funzionalità sia stata rimossa, perché una rimozione compare nelle release notes. Nei progetti che ho verificato per questo articolo, le funzionalità SSO a pagamento erano state sviluppate fin dall'inizio per il piano a pagamento. Non ho trovato casi in cui un SSO gratuito funzionante sia stato ritirato. Grafana è un esempio tipico. La pagina SAML riporta una nota di una riga, "Available in Grafana Enterprise and Grafana Cloud", mentre OAuth generico verso il proprio issuer funziona nella build open source.

Qual è il costo effettivo della tassa SSO

Il costo economico è la parte minore. I piani a pagamento vengono fatturati per utente, quindi la spesa cresce insieme al team, mentre hosting e aggiornamenti restano a tuo carico.

Il costo maggiore è il lavoro manuale sulla gestione delle identità, che si concentra in quattro aree.

• Un archivio delle password per ogni applicazione: una password riutilizzata diventa quindi una vulnerabilità in tutte le applicazioni che la condividono.
• La disattivazione degli accessi affidata alla memoria. Devi ricordare tutti i servizi utilizzati da una persona; quello che dimentichi è proprio il servizio rilevante.
• MFA configurata applicazione per applicazione, quando l'applicazione la supporta.
• Credenziali condivise, che è ciò che accade realmente nei piccoli team sottoposti a questa pressione.

Quest'ultimo punto merita una frase a parte. Quando un team condivide un unico account amministratore in un gestore documentale, il trail di audit registra un solo nome per ogni operazione; quindi non puoi sapere chi ha eliminato la fattura. Anche le autorizzazioni per utente smettono di funzionare, perché esiste un solo utente. Questo è il danno reale della tassa SSO: spinge i piccoli team verso un unico account condiviso, che è peggiore di qualsiasi alternativa.

Checklist da eseguire prima di adottare un'applicazione

Esegui questa checklist prima di docker compose up, non dopo che l'applicazione ha già 400 documenti.

1. Apri la pagina relativa all'autenticazione nella documentazione e leggi la nota sul livello disponibile all'inizio della pagina. Le funzionalità a pagamento sono indicate da un badge o da una frase di una riga sulla disponibilità.
2. Verifica che l'applicazione supporti OIDC o SAML con il tuo issuer, invece di supportare soltanto un elenco fisso di provider pubblici.
3. Controlla la mappatura di ruoli e gruppi. Creare l'utente copre metà del lavoro; assegnare manualmente i permessi in dieci applicazioni è l'altra metà, ed è quella più onerosa.
4. Verifica se l'applicazione accetta in un header il nome utente autenticato da un proxy considerato attendibile e se puoi specificare quale proxy deve considerare attendibile.
5. Leggi la cronologia delle licenze in git e verifica se i contributori firmano un CLA (contributor licence agreement).
6. Controlla la procedura di deprovisioning. Verifica cosa accade ai token API (application programming interface) e alle sessioni attive quando l'account dell'IdP viene disabilitato.

Il punto 2 è la causa principale della maggior parte delle delusioni. Un pulsante "Sign in with Google" non indica il supporto OIDC con il tuo identity provider: è un'integrazione fissa con un solo fornitore. Il supporto effettivo richiede un issuer URL; tutto il resto viene ricavato tramite discovery. Puoi verificare in un solo comando il comportamento del tuo provider.

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

Un provider funzionante restituisce tre URL. Un risultato vuoto o un errore 404 indica generalmente che il percorso di discovery è errato. Il percorso dipende dal provider: Keycloak lo pubblica in /realms/<realm>/.well-known/openid-configuration. Se l'applicazione non dispone di alcun campo per un issuer URL, non può comunicare con il tuo IdP, indipendentemente da quanto indicato nell'elenco delle funzionalità.

Il punto 6 viene spesso verificato solo settimane dopo la cessazione dell'utente. Disabilitare l'account nell'IdP impedisce i nuovi accessi. Non revoca un token API emesso in precedenza dall'applicazione, perché è l'applicazione a convalidare il token e non interroga mai l'IdP. Il deprovisioning richiede quindi due passaggi: disabilitare l'account nell'IdP, quindi eliminare l'utente o i relativi token all'interno di ogni applicazione.

Cosa indicano realmente i badge dei piani

Questi dati sono stati verificati sulla documentazione dei singoli progetti ad agosto 2026. Iniziamo dalle funzionalità a pagamento.

Grafana indica SAML come "Available in Grafana Enterprise and Grafana Cloud", insieme alla sincronizzazione dei team e al provisioning SCIM. OAuth generico, GitHub OAuth, LDAP (lightweight directory access protocol) e il proxy di autenticazione sono tutti inclusi nella build open source, quindi anche chi gestisce un piccolo ambiente self-hosted può accedere tramite il proprio provider. Il limite della versione a pagamento riguarda SAML, non il single sign-on nel suo complesso. Questa è la distinzione che l'espressione "SSO tax" tende a semplificare eccessivamente.

Metabase è più esplicito. La documentazione afferma: "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." L'edizione open source mantiene l'accesso tramite password e LDAP.

Passbolt indica la documentazione SSO come disponibile per Pro e Cloud, quindi l'edizione community non include questa funzionalità. I provider documentati includono Keycloak ed Entra ID.

Ora consideriamo l'altro lato, perché questo schema non è affatto universale.

• GitLab Self-Managed indica "Tier: Free, Premium, Ultimate" nella pagina relativa a SAML, quindi usare SAML con il proprio GitLab non comporta costi.
• Paperless-ngx configura OIDC tramite django-allauth con PAPERLESS_SOCIALACCOUNT_PROVIDERS, nasconde il modulo di accesso locale con PAPERLESS_DISABLE_REGULAR_LOGIN e associa i claim ai gruppi con PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka usa OIDC_ISSUER, OIDC_CLIENT_ID e OIDC_CLIENT_SECRET, imposta per impostazione predefinita gli scope su openid profile email e promuove gli amministratori in base a un role claim con OIDC_ADMIN_ROLES.
• BookStack abilita il passaggio con AUTH_METHOD=oidc, quindi associa i gruppi del provider ai propri ruoli con OIDC_USER_TO_GROUPS=true e OIDC_GROUPS_CLAIM.
• Vaultwarden ha introdotto il "support for SSO with OpenID Connect" nella versione 1.35.0, il 27 dicembre 2025, tramite una pull request di un contributor che aveva mantenuto la funzionalità in un fork.
• listmonk supporta l'accesso OIDC insieme ai propri ruoli utente dalla versione v4.0.0.

Tieni conto di queste informazioni quando scegli, non dopo aver preso una decisione. Una bacheca kanban Planka e le altre alternative self-hosted a Trello non gestiscono tutte l'identità nello stesso modo, e lo stesso vale per BookStack, Wiki.js e Outline. La disponibilità di OIDC gratuita è una caratteristica da valutare come i limiti dello spazio di archiviazione o il supporto per i client mobili. Se stai ancora definendo l'elenco, cosa eseguire in self-hosting nel 2026 è un punto di partenza ragionevole; inoltre, sia il gestore documentale Paperless-ngx sia Vaultwarden offrono oggi OIDC gratuitamente.

Perché un reverse proxy davanti all'applicazione non è il single sign-on

La soluzione più comune è il forward auth. Il reverse proxy mette in attesa ogni richiesta, chiede a un servizio di autenticazione se il browser ha eseguito l'accesso e inoltra la richiesta all'applicazione solo dopo una risposta positiva. authentik lo chiama proxy provider e offre una modalità forward auth per una singola applicazione e un'altra per un intero dominio. Anche Authelia e oauth2-proxy svolgono questa funzione.

Un blocco site di Caddy ha il seguente aspetto, secondo l'esempio fornito da 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
}

In Caddy è importante rispettare le maiuscole e le minuscole nei nomi degli header, perché un nome non corrispondente arriva vuoto. Per ogni richiesta autorizzata, l'outpost imposta X-authentik-username, X-authentik-email, X-authentik-groups e altri header.

Questo è il vantaggio. Nessuno raggiunge l'applicazione senza passare prima dal provider di identità. Di conseguenza, un modulo di accesso non aggiornato non è più esposto a Internet e l'MFA si applica contemporaneamente a tutto ciò che si trova dietro il proxy.

Questo è ciò che non si ottiene: l'identità all'interno dell'applicazione. L'applicazione continua ad avere i propri account e una propria gestione delle sessioni di accesso. Se tutti superano il proxy e accedono a un unico account amministratore condiviso, avete una solida porta d'ingresso e una sessione anonima unica dietro di essa. Il log di audit continua a mostrare un solo nome. Non è ancora possibile assegnare autorizzazioni diverse alle singole persone. Chiamare questa configurazione SSO è un errore di sicurezza, perché il processo di revoca dell'accesso è valido solo in parte: rimuovere la persona dal proprio IdP chiude la porta d'ingresso, ma un token API creato nell'applicazione continua a funzionare per chiunque possa raggiungere direttamente l'applicazione.

Rendere sicura l'autenticazione tramite header

Alcune applicazioni accettano un nome utente dal proxy. In questo modo puoi identificare ogni utente senza acquistare un sistema SSO. Il nome dell'impostazione varia da un progetto all'altro.

Grafana la chiama auth proxy ed è disabilitata per impostazione predefinita. Il nome dell'header predefinito è X-WEBAUTH-USER. Puoi sostituirlo con quello impostato dal proxy.

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

whitelist è la riga che spesso viene ignorata. La documentazione di Grafana specifica che serve a impedire agli utenti di falsificare l'header. Deve quindi contenere esclusivamente l'indirizzo del proxy. Gitea offre la stessa funzionalità con nomi diversi e utilizza un valore predefinito più sicuro.

[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 è impostato per impostazione predefinita su 127.0.0.0/8,::1/128. REVERSE_PROXY_LIMIT indica quanti proxy Gitea considererà attendibili nella catena. Impostando questo limite su zero disabiliti completamente la gestione dell'header.

Paperless-ngx offre PAPERLESS_ENABLE_HTTP_REMOTE_USER con PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. La documentazione include questo avviso, che si applica a tutte queste impostazioni:

Questo consente di autenticarsi semplicemente aggiungendo un header Remote-User: <username> a una richiesta. Usare con cautela.

Per mantenere sicura l'autenticazione tramite header sono necessarie due regole, entrambe legate alla raggiungibilità. Innanzitutto, l'applicazione deve essere raggiungibile soltanto tramite il proxy. Chiunque possa aprire un socket verso l'applicazione può infatti inviare quell'header e impersonare qualsiasi utente. In Docker, ports: ["8000:8000"] pubblica la porta su tutte le interfacce. Esegui il binding sull'indirizzo di loopback con ports: ["127.0.0.1:8000:8000"], oppure rimuovi la porta pubblicata e collega il proxy alla stessa rete Docker. In secondo luogo, il proxy deve eliminare ogni copia dell'header ricevuta dal client. L'unico valore visibile all'applicazione deve essere quello impostato dal proxy dopo l'autenticazione.

Verifica entrambi gli aspetti. Esegui il primo comando da un computer esterno al tuo VPS e il secondo direttamente sul server.

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

curl dovrebbe fallire la connessione e ss dovrebbe stampare 127.0.0.1:8000 anziché 0.0.0.0:8000. Se la prima riga è HTTP/1.1 302 Found, l'applicazione risponde direttamente su Internet. Chiunque può quindi accedere come un utente arbitrario specificandone il nome in un header.

Quando non esiste un SSO gratuito, decidete invece di lamentarvi

Quattro opzioni, nell'ordine in cui le proverei.

1. Scegliete l'applicazione che include OIDC. Se due progetti svolgono lo stesso lavoro e uno comunica gratuitamente con il vostro identity provider, questa è una differenza reale nei costi di gestione.
2. Usate il forward auth in modo trasparente. Per uno strumento di amministrazione con un solo account e un solo operatore, è sufficiente un proxy davanti all'applicazione; l'identità del singolo utente all'interno dell'applicazione non aggiunge alcun vantaggio.
3. Pagate. Se l'applicazione è centrale per il vostro lavoro e il prezzo per utente è compatibile con le dimensioni del team, il pagamento contribuisce a mantenere il progetto. L'alternativa è pagare con il tempo libero delle vostre serate.
4. Chiedete al progetto upstream, dopo aver cercato nel sistema di issue tracking. Il supporto OIDC di Vaultwarden è nato dal fork di un contributor e da una pull request rimasta aperta a lungo. Una richiesta di funzionalità accompagnata da un'implementazione funzionante può quindi essere inclusa anche nell'edizione gratuita.

Nulla di tutto questo funziona senza un identity provider di vostra proprietà, che è il componente da realizzare per primo. Eseguire authentik su un VPS vi fornisce un provider OIDC e SAML, oltre al forward auth outpost usato sopra; il confronto tra Keycloak, authentik e Zitadel illustra i compromessi, se preferite non fare ancora una scelta definitiva.

Cronologia delle licenze e motivo della sua presenza nella checklist

L'ultimo elemento della checklist riguarda il futuro, perché la classificazione attuale dei livelli è soltanto una fotografia temporanea. Due casi ben documentati mostrano quanto rapidamente possa cambiare lo scenario, in entrambe le direzioni. Il 10 August 2023 HashiCorp ha adottato la Business Source License 1.1 per tutte le release future, mentre le release precedenti sono rimaste soggette alla MPL 2.0 (Mozilla Public License). Redis è passato alla SSPL (Server Side Public License) nel March 2024, quindi il 1 May 2025 ha annunciato che Redis 8 viene distribuito anche con licenza AGPLv3 (GNU Affero General Public License).

Considerate entrambi i casi come indicazioni sul meccanismo, non sulle motivazioni. La licenza che leggete oggi si applica alla versione che installate oggi, e un progetto che detiene tutti i diritti d'autore può modificare autonomamente i termini della release successiva. Per questo la domanda sulla CLA è inclusa nella checklist: l'assegnazione ampia dei diritti d'autore è ciò che rende possibile una relicensing unilaterale.

Controllate personalmente la cronologia di un progetto prima di basarvi su di esso.

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

Un elenco breve di commit, composto soprattutto da quelli del primo import, è un segnale positivo. Diverse riscritture del file della licenza indicano che dovete leggere il messaggio di ogni commit prima di pianificare le attività sulla base dei termini attuali.

FAQ

Qual è il costo dell'SSO?

Il costo dell'SSO consiste nel far pagare il single sign-on come funzionalità premium, mentre il resto del prodotto è gratuito o economico. Nel software self-hosted si presenta come un'applicazione open source eseguibile senza una licence key, in cui l'accesso tramite OIDC o SAML è disponibile in un piano a pagamento. Il nome deriva dalla SSO Wall of Shame di sso.tax, che tiene traccia dei vendor che applicano un sovrapprezzo elevato per questa funzionalità. Per chi gestisce autonomamente i servizi, la conseguenza è che ogni app mantiene il proprio database degli utenti e gli account devono essere creati e rimossi manualmente.

Un reverse proxy con forward auth equivale a un SSO?

No. Il forward auth protegge il punto di accesso: il proxy verifica l'identità con l'identity provider prima che una richiesta raggiunga l'app. L'applicazione continua però a usare i propri account. Se tutti accedono tramite un unico login condiviso, si ottiene una sola sessione anonima e un audit log con un unico nome. L'identità individuale viene mantenuta solo quando l'app legge il nome utente da un header. Possono farlo il proxy di autenticazione di Grafana, l'autenticazione reverse proxy di Gitea e PAPERLESS_ENABLE_HTTP_REMOTE_USER di Paperless-ngx. Queste impostazioni sono sicure solo finché l'app non è raggiungibile se non tramite il proxy, perché l'header è una semplice stringa che qualsiasi client può inviare.

Quali app self-hosted includono OIDC nell'edizione gratuita?

Verificato sulla documentazione dei progetti ad agosto 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk e Vaultwarden supportano tutti OIDC nelle rispettive build gratuite. GitLab Self-Managed indica inoltre SAML nel livello Tier: Free. La build open source di Grafana supporta OAuth generico tramite il proprio issuer, mentre SAML è una funzionalità Enterprise. Verifica queste informazioni nella pagina dedicata all'autenticazione del progetto prima dell'installazione, perché gli elenchi cambiano con le release.

Conviene pagare il piano che abilita il single sign-on?

La decisione dipende da 2 numeri: quante persone hanno bisogno di un account e quante app dovresti altrimenti gestire manualmente. Per uno o 2 amministratori, il forward auth davanti a un account locale è sufficiente e il piano a pagamento offre pochi vantaggi. In un team con ingressi e uscite frequenti, un account non rimosso durante l'offboarding può costare più della licence, mentre il pagamento finanzia la manutenzione da cui dipendi. Se il prezzo non è sostenibile, la scelta più pratica è usare un'app che includa OIDC invece di aggirare il limite di un'app che non lo supporta.