SSO: un solo login per tutte le app self-hosted, senza pagare

Chi installa su un proprio server – in self-hosting – applicazioni come Immich per la libreria fotografica, Paperless-ngx per i documenti, Grafana per il monitoraggio o strumenti di collaborazione e project management si accorge presto di un problema: ogni servizio tende a creare il proprio sistema di utenti, password e autenticazione. SSO (Single Sign-On) permette di usare un unico sistema di autenticazione per accedere a più applicazioni, evitando di creare e gestire credenziali separate per ogni servizio.

Con protocolli standard come OpenID Connect (OIDC), applicazioni diverse possono delegare il login a un Identity Provider centrale, ad esempio Authentik, Keycloak, Pocket ID o Authelia. L’utente si autentica presso quel sistema e le applicazioni ricevono le informazioni necessarie per riconoscerlo, senza che ciascuna di esse debba mantenere un proprio insieme indipendente di credenziali.

Il problema nasce quando il supporto SSO, pur essendo tecnicamente disponibile, è riservato alle edizioni a pagamento dei vari software. Succede anche nel software self-hosted: il programma può essere installato gratuitamente sul proprio server, ma per collegarlo a un provider OIDC o SAML è richiesta l’adesione a un piano Pro o Enterprise.

La SSO tax è arrivata anche nel mondo self-hosted

La definizione SSO tax nasce soprattutto nel mercato SaaS (Software-as-a-Service): un servizio offre prezzi relativamente abbordabili per utente, ma se un’azienda vuole collegarlo al proprio Identity Provider tramite SAML o OIDC deve acquistare il piano Enterprise, spesso molto più costoso.

Nel software self-hosted la situazione appare ancora più curiosa. Come accennato nell’introduzione, spesso, l’applicazione gira sul server dell’utente, il database è locale e l’infrastruttura è amministrata autonomamente; tuttavia, il componente necessario per delegare il login può trovarsi nell’edizione Pro.

Il progetto ssno.tax nasce come risposta a questo modello. Raccoglie applicazioni self-hosted che consentono di configurare gratuitamente un proprio provider OpenID Connect, offrendo un riferimento utile per chi vuole scegliere software compatibili con un’infrastruttura di autenticazione centralizzata senza trovarsi davanti a un paywall.

ssno.tax nasce nella comunità self-hosted e utilizza un archivio pubblico su GitHub dal quale è automaticamente generato il sito. L’obiettivo consiste nel raccogliere applicazioni che permettano di configurare un provider OIDC personalizzato. In altre parole, l’amministratore deve poter indicare il proprio Identity Provider e non essere obbligato a utilizzare esclusivamente Google, Microsoft, GitHub o un altro servizio deciso dallo sviluppatore.

“Accedi con Google” e “supporto OIDC” possono utilizzare tecnologie strettamente correlate, ma dal punto di vista di chi amministra un’infrastruttura self-hosted risolvono problemi differenti. Nel primo caso l’identità dipende da Google; nel secondo si può installare, ad esempio, Pocket ID o Authentik sul proprio server e utilizzare quell’identità per tutte le applicazioni compatibili.

OpenID Connect: perché è importante nel self-hosting

OIDC è spesso confuso con OAuth 2.0, ma i due standard non sono equivalenti. OAuth 2.0 nasce principalmente per l’autorizzazione: permette a un’applicazione di ottenere un token con il quale accedere a determinate risorse per conto dell’utente.

OpenID Connect aggiunge a OAuth 2.0 un livello dedicato all’identità. La stessa OpenID Foundation lo definisce come un identity layer costruito sopra OAuth 2.0: il client può verificare chi è l’utente sulla base dell’autenticazione effettuata dall’Authorization Server e ricevere alcune informazioni sulla sua identità attraverso i cosiddetti claim.

In una configurazione self-hosted, il flusso funziona così: supponiamo di avere Immich, Grafana, Paperless-ngx e un altro servizio installati sul server. Invece di creare quattro account indipendenti, configuriamo tutti i programmi affinché utilizzino lo stesso provider OIDC.

Quando apriamo Immich e premiamo il pulsante di accesso, l’applicazione reindirizza il browser verso l’Identity Provider. È quest’ultimo a verificare l’utente, eventualmente chiedendo password, passkey o secondo fattore. Al termine restituisce a Immich un token che certifica l’identità autenticata.

OpenID Foundation descrive precisamente questo modello: il client invia la richiesta all’OpenID Provider, il provider autentica l’utente e restituisce un ID Token, normalmente accompagnato da un Access Token. Il vantaggio diventa evidente quando le applicazioni aumentano.

Come si collega un’applicazione a un provider OIDC

Le schermate cambiano da programma a programma, ma i parametri richiesti sono quasi sempre riconoscibili. L’Identity Provider assegna innanzitutto all’applicazione un Client ID, cioè un identificatore. Per le applicazioni server viene spesso creato anche un Client Secret.

L’applicazione deve quindi conoscere l’indirizzo dell’issuer, ad esempio: https://id.example.com. Da quell’indirizzo può recuperare automaticamente, se supporta OIDC Discovery, gli endpoint necessari per autenticazione, token e informazioni sull’utente.

Bisogna poi registrare una Redirect URI, ovvero l’indirizzo al quale il provider può rispedire il browser una volta completata l’autenticazione. Potrebbe assumere una forma simile alla seguente: https://immich.example.com/auth/login

Tra gli scope compare almeno openid: è proprio la presenza di questa informazione che trasforma il normale processo OAuth in una richiesta OpenID Connect. A seconda del software possono servire anche profile, email e altri scope o claim specifici.

Le applicazioni più evolute permettono infine di associare gruppi dell’Identity Provider ai ruoli locali. Il gruppo admins, per esempio, può trasformarsi automaticamente nel ruolo amministratore dell’applicazione.

Le applicazioni self-hosted che non fanno pagare il SSO

L’aspetto più interessante della raccolta ssno.tax è la varietà dei programmi censiti. Non si parla soltanto di strumenti destinati ad aziende o amministratori di sistema: molte applicazioni sono popolari anche nei laboratori domestici e sono ampiamente utilizzate nei server personali.

Foto, documenti e password

Tra gli esempi più conosciuti c’è il già citato Immich, piattaforma self-hosted per archiviare foto e video, spesso utilizzata come alternativa a Google Foto. Il supporto OIDC permette di evitare account separati e far autenticare gli utenti attraverso il provider già utilizzato per gli altri servizi.

Compare anche Paperless-ngx, applicazione molto apprezzata per digitalizzare, indicizzare e organizzare documenti. In un server domestico o aziendale può contenere fatture, contratti, ricevute e documentazione amministrativa: poter collegare l’accesso al sistema centrale delle identità evita di mantenere un ulteriore archivio di password.

Monitoraggio e strumenti per amministratori

Un altro nome importante è Grafana, utilizzato per visualizzare metriche e costruire dashboard a partire da database, sistemi di monitoraggio e infrastrutture. L’edizione open source consente di integrare provider compatibili OIDC tramite la configurazione Generic OAuth, rendendo possibile utilizzare lo stesso account impiegato per gli altri strumenti amministrativi.

Nella raccolta troviamo inoltre Vaultwarden, implementazione server compatibile con i client Bitwarden. Il caso è particolarmente interessante perché riguarda direttamente la gestione delle credenziali: collegare Vaultwarden a un Identity Provider permette di inserire anche il password manager in una politica di autenticazione centralizzata.

Produttività, organizzazione personale e servizi multimediali

Tra gli strumenti di produttività figurano invece Vikunja, dedicato alla gestione di attività e progetti, e Wekan, software Kanban self-hosted. Per applicazioni di questo tipo l’SSO diventa particolarmente utile quando il server viene utilizzato da un gruppo di persone: l’amministratore può gestire gli utenti dal provider centrale senza creare manualmente un account all’interno di ogni servizio.

La lista comprende anche Actual Budget per la gestione finanziaria personale, Mealie per ricette e pianificazione dei pasti, Audiobookshelf per audiolibri e podcast, Matomo per l’analisi del traffico web, oltre a strumenti più tecnici come Firezone per l’accesso remoto alle risorse di rete.

Anche le applicazioni AI entrano nel Single Sign-On

Ci sono infine applicazioni legate all’intelligenza artificiale, tra cui Open WebUI e LibreChat, che permettono di creare interfacce self-hosted per modelli linguistici e servizi AI.

Anche qui OIDC può diventare rilevante: se un’interfaccia viene utilizzata da più persone, l’amministratore può controllarne l’accesso attraverso la stessa infrastruttura di identità usata per gli altri servizi.

Perché SSO non serve soltanto nelle grandi aziende

Classificare SSO come una caratteristica esclusivamente “enterprise” ha una sua logica commerciale, ma è cosa ampiamente discutibile, soprattutto nell’ambito del self-hosting.

Immaginiamo una famiglia o un piccolo ufficio con dieci servizi: senza autenticazione centralizzata, rimuovere un utente significa entrare in ciascuna applicazione e disattivare manualmente il relativo account. Con un Identity Provider, l’operazione può ridursi alla disabilitazione dell’identità centrale.

Lo stesso vale per le politiche di autenticazione: invece di configurare separatamente MFA (autenticazione multifattore) o passkey in ogni prodotto, una parte importante della protezione è trasferita all’Identity Provider.

C’è inoltre un vantaggio spesso sottovalutato: le applicazioni non devono conoscere la password dell’utente: l’autenticazione avviene presso il provider e il servizio riceve le informazioni necessarie attraverso token firmati.

Per un amministratore self-hosted significa ridurre il numero di database contenenti credenziali e avere un punto centrale nel quale controllare accessi e identità.

Attenzione: centralizzare l’identità centralizza anche il rischio

SSO non significa automaticamente maggiore sicurezza. Con dieci password indipendenti, la compromissione di un’applicazione può riguardare un singolo account; con un Identity Provider utilizzato da tutta l’infrastruttura, la compromissione dell’identità principale può invece aprire le porte a molti servizi contemporaneamente.

Il provider diventa quindi uno dei sistemi più sensibili dell’intera installazione: è perciò opportuno proteggerlo con MFA o passkey, limitarne l’esposizione, mantenere aggiornato il software e predisporre almeno una procedura di recupero amministrativo che non dipenda dall’SSO stesso.

Vale quindi la pena mantenere, quando possibile, un account locale di emergenza con credenziali robuste, conservate offline e utilizzate esclusivamente per il recupero.