Hai otto container Docker in esecuzione su un VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, una pagina di stato e un'app interna che hai scritto tu. Ognuno ha il proprio login. Ogni mattina copi e incolli password dal tuo password manager, e hai iniziato a chiederti se il single sign-on valga il costo operativo.
Di solito sì. La domanda è quale identity provider far girare.
Keycloak è la scelta predefinita più familiare, ma la soluzione migliore dipende da com'è fatto il tuo stack, da quanti utenti gestisci e dal fatto che tu stia integrando software già in uso o costruendo l'autenticazione dentro le tue applicazioni.
Questo confronto tra SSO self-hosted esamina Authentik, ZITADEL, Keycloak e Authelia attraverso le decisioni che contano una volta in produzione: supporto dei protocolli, gestione utenti, flusso di lavoro per sviluppatori, requisiti di risorse e cosa succede quando il tuo identity provider va giù.
Perché l'SSO self-hosted conta
Quando più applicazioni dipendono dalle stesse persone e dagli stessi gruppi, i login separati smettono di essere comodi. Un identity provider self-hosted ti dà un unico posto in cui gestire account, MFA, appartenenza ai gruppi e policy di accesso, invece di configurare quei controlli separatamente in ogni applicazione.
Il rovescio della medaglia è altrettanto importante: l'IdP diventa infrastruttura da cui dipendono le altre applicazioni. Nuovi login e rinnovi dei token possono fallire quando non è disponibile, quindi backup, accesso di emergenza, aggiornamenti e uptime contano più qui che per una normale app self-hosted.
TL;DR
Scegli Authentik se vuoi la migliore opzione predefinita
Per un homelab, uno stack di strumenti interni o un piccolo team che collega applicazioni esistenti tramite OIDC o SAML, Authentik è la scelta predefinita più solida. Il suo flusso di amministrazione è più accessibile di quello di Keycloak, supporta diversi metodi di integrazione e la sua configurazione Docker Compose ufficiale parte da 2 core CPU e 2 GB di RAM.
Scegli ZITADEL se stai costruendo applicazioni
Scegli ZITADEL quando l'autenticazione fa parte del prodotto che stai costruendo. Il suo modello a organizzazioni, le API, la multi-tenancy, OIDC, SAML, le passkey, la MFA e il supporto per identity provider LDAP hanno più senso per team di applicazioni SaaS e B2B che per un homelab tipico.
Scegli Keycloak se ti servono funzioni di identità enterprise
Scegli Keycloak quando ti serve una federazione LDAP o Active Directory più profonda, più realm, policy di autorizzazione granulari o un ambiente già costruito attorno a Keycloak. La sua documentazione consiglia un limite di memoria di 2 GB per i container Keycloak più piccoli pronti per la produzione; un VPS tutto-in-uno che esegue anche PostgreSQL ha bisogno di margine aggiuntivo.
Alternativa: scegli Authelia se ti serve soprattutto un muro di login
Scegli Authelia quando il tuo problema principale è proteggere le applicazioni a livello di reverse proxy invece di far girare una piattaforma di identità completa. Può anche fungere da provider OpenID Connect, ma l'autenticazione al reverse proxy resta il suo baricentro.
Cosa verificare prima di scegliere uno strumento SSO
Prima di confrontare le funzionalità, misura ogni strumento sulle applicazioni, i protocolli e le fonti di identità che devi già supportare.
Quante app hanno bisogno dell'SSO?
Parti dalle applicazioni, non dall'identity provider. Uno stack con sei applicazioni che già supportano OIDC o SAML è un problema diverso da uno stack di vecchi strumenti interni che non sanno nulla di nessuno dei due protocolli. Il primo caso punta verso un IdP completo. Il secondo potrebbe richiedere l'autenticazione a livello di reverse proxy.
Le tue app supportano OIDC o SAML?
OIDC è la scelta comune per le applicazioni web moderne. SAML conta ancora nel software enterprise e nelle integrazioni più vecchie. LDAP può contare quando l'applicazione si aspetta una directory anziché un flusso SSO web. Verifica cosa accetta davvero ogni applicazione prima di scegliere l'IdP che starà nel mezzo.
Stai gestendo utenti o integrando il login in un'app?
Se la maggior parte del tuo lavoro avverrà in un'interfaccia di amministrazione mentre colleghi applicazioni esistenti, Authentik è il punto di partenza naturale. Se l'autenticazione fa parte di un prodotto che stai costruendo e prevedi di creare organizzazioni, utenti e permessi via codice, ZITADEL è molto più vicino a quel flusso di lavoro.
Ti servono LDAP, Active Directory o policy avanzate?
Authentik, ZITADEL e Keycloak possono tutti collegarsi in qualche forma a fonti di identità basate su LDAP, quindi LDAP da solo non decide più il confronto. Keycloak diventa più interessante quando la federazione di directory si combina con più realm, mapper dettagliati, requisiti di sincronizzazione o policy di autorizzazione a livello di risorsa.
Authentik vs ZITADEL vs Keycloak vs Authelia
I quattro strumenti si sovrappongono sull'SSO, ma affrontano l'identità da direzioni diverse: integrazione delle applicazioni, identità di prodotto, IAM enterprise e accesso tramite reverse proxy.
Authentik
Authentik esegue il suo deployment di base come server, worker e database PostgreSQL. Redis non fa più parte dello stack: Authentik ha rimosso completamente la dipendenza nella release 2025.10. La documentazione Docker Compose attuale richiede un host con almeno 2 core CPU e 2 GB di RAM.
Il tratto distintivo è l'interfaccia di amministrazione. Il motore di flussi di Authentik, il provisioning delle applicazioni e le policy basate sui gruppi sono più accessibili del modello di configurazione più ampio di Keycloak. Se hai mai configurato un'applicazione OIDC in Keycloak e poi passato del tempo a capire perché mancavano i claim del token, la differenza si nota in fretta.
Supporta SAML, OAuth2/OIDC, LDAP e RADIUS. È la scelta predefinita giusta per un homelab o un piccolo team di ingegneri che gestisce uno stack di app self-hosted.
ZITADEL
ZITADEL è scritto principalmente in Go, con licenza AGPL-3.0, e si trova sulla linea di release v4.x. Il deployment include un'API in Go, un'interfaccia di login in Next.js e PostgreSQL, e i requisiti attuali supportano PostgreSQL da 14 a 18. La documentazione Docker Compose ufficiale richiede un host con almeno 2 GB di RAM.
Il tratto distintivo è l'API. ZITADEL espone una superficie di identità completa via gRPC e REST ed è costruito fin dall'inizio su un modello multi-tenant. Se stai costruendo un prodotto SaaS e vuoi che il livello di login sia programmabile, automatizzabile e multi-tenant per impostazione predefinita, ZITADEL è più vicino a ciò che cerchi rispetto alle alternative.
Supporta OIDC, SAML, passkey, MFA, identity provider LDAP e un'interfaccia SCIM v2 attualmente contrassegnata come Preview. Il suo modello a organizzazioni e il flusso di lavoro API-first lo rendono più adatto ai team di prodotto che a un semplice homelab.
Keycloak
Keycloak è una piattaforma Java di gestione di identità e accessi che gira su Quarkus. Ha una superficie di configurazione più ampia delle altre opzioni qui presentate, soprattutto quando entrano in gioco Realms, Clients, Roles, federazione utenti e Authorization Services.
La sua documentazione ufficiale sui container consiglia un limite di memoria di 2 GB per i deployment più piccoli pronti per la produzione. Quel valore copre il solo container Keycloak; se PostgreSQL condivide lo stesso VPS, dai all'host più margine.
La ragione per accettare quella complessità è concreta. Keycloak può federare directory LDAP e Active Directory, registrare eventi di utenti e amministratori e applicare un'autorizzazione granulare con policy RBAC, ABAC, basate sull'utente, basate sul contesto e di altri tipi. Se ti servono quei controlli, la configurazione aggiuntiva ha uno scopo.
Authelia
Authelia è il più piccolo dei quattro: licenza Apache 2.0, un singolo binario Go, attualmente alla v4.39.x. L'architettura è diversa dagli altri tre: Authelia sta davanti a un reverse proxy (nginx, Traefik, Caddy, HAProxy) e decide se le richieste possono raggiungere il backend.
Authelia include anche un provider OpenID Connect. La sua documentazione descrive ancora l'implementazione OIDC come beta aperta, ma il provider è certificato OpenID per i profili Basic OP, Implicit OP, Hybrid OP, Form Post OP e Config OP. Le sue funzionalità OIDC sono più limitate di quelle che Authentik o Keycloak offrono per la gestione delle identità, ed è per questo che Authelia ha ancora più senso quando l'autenticazione al reverse proxy è il compito principale.
Torneremo su Authelia in una sezione dedicata. In breve: il baricentro di Authelia è il controllo al reverse proxy, non la gestione completa delle identità.
Confronto delle funzionalità
La tabella qui sotto limita il confronto alle differenze che incidono sul deployment e sull'amministrazione quotidiana.
| Funzione | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Protocolli supportati | OAuth2/OIDC, SAML, LDAP, RADIUS, autenticazione tramite proxy | OAuth2/OIDC, SAML, identity provider LDAP, SCIM v2 in Preview | OAuth2/OIDC, SAML, federazione LDAP e Active Directory | Provider OIDC più autenticazione al reverse proxy |
| Gestione di utenti e gruppi | Utenti, gruppi, policy, flussi, associazioni alle applicazioni | Utenti, organizzazioni, progetti, ruoli, grant | Utenti, gruppi, realm, ruoli client, ruoli realm, federazione | Gestione utenti leggera, di solito basata su file o LDAP |
| Esperienza sviluppatore | API disponibile, ma l'interfaccia di amministrazione è il punto di forza principale | API-first, solido modello a organizzazioni e multi-tenant | API REST mature con un modello IAM più ampio da imparare | Principalmente guidato dalla configurazione |
| Funzionalità enterprise | Policy, federazione, outpost, controlli di accesso alle applicazioni | Organizzazioni, progetti, passkey, federazione, SCIM v2 in Preview | Federazione profonda, più realm, eventi, Authorization Services | Regole di controllo accessi e forte integrazione con il reverse proxy |
| Facilità di configurazione | Punto di partenza più semplice per la maggior parte degli stack di applicazioni self-hosted | Ideale quando il team ragiona in termini di API e identità di prodotto | Più concetti e configurazione, ma controlli più profondi | Il più semplice quando il compito è soprattutto l'autenticazione al reverse proxy |
| Risorse consigliate | Minimo Compose ufficiale: 2 core CPU e 2 GB di RAM | Minimo Compose ufficiale per l'host: 2 GB di RAM | 2 GB di memoria container consigliati per i deployment di produzione più piccoli | Nessun minimo di RAM ufficiale direttamente confrontabile |
Quale strumento per quale stack?
La scelta migliore cambia in base a chi gestisce l'IdP e a come le applicazioni si integrano con esso.
Opzione migliore per un homelab
Authentik è la scelta predefinita per un homelab in cui la maggior parte delle applicazioni supporta già OIDC o SAML. Ti dà un identity provider completo senza obbligarti ad adottare il modello IAM più ampio di Keycloak. Se la maggior parte dello stack ha bisogno di una schermata di login al reverse proxy invece dell'SSO nativo, Authelia potrebbe essere la scelta più semplice.
Opzione migliore per lo stack di una piccola azienda
Authentik si adatta alla maggior parte dei piccoli stack di applicazioni interne, soprattutto quando l'obiettivo è un unico livello di identità per strumenti come Grafana, Gitea, Nextcloud e Vaultwarden. Keycloak diventa più interessante quando una directory esistente, più realm o policy di autorizzazione più profonde fanno parte dei requisiti.
Opzione migliore per sviluppatori e prodotti SaaS
ZITADEL è la scelta più adatta quando l'autenticazione fa parte del prodotto che stai costruendo. Il suo modello a organizzazioni, la multi-tenancy, le API e la superficie di automazione hanno più senso quando utenti e tenant devono essere creati dal codice dell'applicazione invece che principalmente da un pannello di amministrazione.
Opzione migliore per team enterprise o con forti esigenze di conformità
Keycloak ha senso quando l'elenco dei requisiti include una federazione di directory complessa, più realm, policy di autorizzazione dettagliate e un team in grado di gestire la complessità IAM aggiuntiva. Ospitare Keycloak da soli non rende un ambiente conforme di per sé; backup, disponibilità, logging, revisioni degli accessi e controlli delle modifiche restano a carico del tuo team.
Opzione migliore per app senza SSO nativo
Authelia è la scelta più netta quando l'autenticazione deve avvenire prima che le richieste raggiungano l'applicazione. Funziona particolarmente bene con reverse proxy che proteggono vecchi strumenti interni, dashboard e servizi che non supportano OIDC o SAML da soli.
La parte difficile dell'SSO self-hosted
Una volta che l'SSO è obbligatorio, un errore di configurazione o un ripristino fallito può colpire più applicazioni contemporaneamente.
Installazione e configurazione
Far girare i container è solo il primo passo. DNS, TLS, URI di redirect, claim dei token, mappature dei gruppi, invio delle email e accesso di emergenza sono i punti in cui un deployment SSO inizia a diventare infrastruttura invece di un'altra app Docker.
Risorse del server
L'IdP è solo una parte del budget di risorse. PostgreSQL, reverse proxy, worker, hashing delle password, log e sincronizzazione delle directory possono tutti contendersi CPU e memoria quando condividono un solo VPS.
Gestione di database e backup
Authentik, ZITADEL e i normali deployment di produzione di Keycloak dipendono da un database. Fai il backup di quel database fuori dal server, documenta come ripristinarlo e prova il ripristino. Un job di backup riuscito non è la stessa cosa di una procedura di ripristino funzionante.
Rischi di blocco e ripristino
Un URI di redirect sbagliato, un client secret scaduto, una connessione alla directory interrotta o una policy troppo rigida possono chiudere fuori gli amministratori insieme a tutti gli altri. Mantieni un percorso di ripristino che non dipenda dal flusso di autenticazione che stai cercando di riparare.
Mantenere l'IdP disponibile
Un'interruzione dell'IdP non termina necessariamente subito tutte le sessioni applicative esistenti. Le sessioni in corso possono continuare finché i loro token o cookie non scadono, ma nuovi login e rinnovi dei token possono fallire. Testa quella modalità di guasto prima di rendere l'SSO obbligatorio in tutto lo stack.
Quando non dovresti ospitare l'SSO da solo
Il self-hosting smette di essere un buon compromesso quando il tuo team non riesce a ripristinare e gestire il livello di identità con l'affidabilità che le tue applicazioni richiedono.
Quando l'identità gestita è più sicura
L'identità gestita vale la spesa quando il costo di gestione dell'IdP supera il controllo che guadagni ospitandolo da solo. Servizi come Auth0, Clerk, WorkOS e Microsoft Entra ID spostano sul fornitore gran parte della disponibilità della piattaforma, delle patch e della manutenzione dell'infrastruttura.
Resti responsabile della configurazione delle applicazioni, dei permessi e della pianificazione del ripristino, ma non più di tenere online la piattaforma di identità in sé.
Quando il tuo team non può gestire un'interruzione
Se nessuno nel team è in grado di ripristinare l'IdP, riparare PostgreSQL, sostituire un secret scaduto o diagnosticare una connessione di federazione fallita durante un'interruzione, ospitare l'identità da soli potrebbe essere il compromesso operativo sbagliato.
Il guasto va oltre una singola applicazione non disponibile. Nuovi login e rinnovi dei token su più applicazioni possono fallire nello stesso momento.
Quando le esigenze di conformità sono troppo alte
L'identità self-hosted può essere usata in ambienti regolamentati, ma far girare il software da soli non produce automaticamente i controlli o le evidenze che un auditor si aspetta. Il tuo team resta responsabile di logging, revisioni degli accessi, backup, gestione delle modifiche, disponibilità, risposta agli incidenti e di tutta la documentazione richiesta dal framework applicabile.
L'SSO self-hosted non è uno status symbol. Se il tuo team non può gestire in sicurezza il livello di identità, pagare per un'identità gestita può essere la decisione ingegneristica migliore.
Dove Cloudzy aiuta
Cloudzy cambia il livello di deployment; non elimina il lavoro di configurazione dell'identità e di gestione descritto sopra.
Il problema del deployment SSO manuale
Un deployment SSO manuale significa preparare il server, installare applicazione e database, configurare il reverse proxy, impostare DNS e TLS, e solo allora iniziare la configurazione dell'identità vera e propria. Niente di tutto questo sostituisce il lavoro su OIDC, SAML, directory o policy che viene dopo.
Deployment SSO con un clic su Cloudzy
Cloudzy offre deployment con un clic per Authentik e Keycloak. L'app Authentik con un clic è nel marketplace di Cloudzy. Anche l'app Keycloak con un clic è nel marketplace di Cloudzy. ZITADEL oggi non è nel marketplace, quindi distribuiscilo con la sua configurazione Docker Compose su un VPS standard. L'installazione con un clic fa partire l'applicazione di base, mentre configurazione dell'identità, DNS, backup, aggiornamenti, policy e test di ripristino restano sotto il tuo controllo.
Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.
Vedi piani LinuxQuando usare un VPS separato per il tuo IdP
Ospitare l'IdP insieme alle tue applicazioni è ragionevole per un homelab in cui un'interruzione è accettabile. Per uno stack critico per il business, separare l'identity provider elimina un evidente dominio di guasto condiviso: riavviare, saturare o compromettere il server applicativo non significa più buttare giù anche il livello di identità.
Un VPS separato non equivale all'alta disponibilità, ma dà all'IdP il proprio budget di risorse, il proprio calendario di manutenzione e il proprio confine di ripristino.
Raccomandazioni per il dimensionamento del VPS
Dimensiona l'intero stack, non solo il processo dell'IdP, soprattutto quando PostgreSQL e un reverse proxy condividono lo stesso VPS.
Requisiti VPS per Authentik
La documentazione Docker Compose ufficiale di Authentik richiede un host con almeno 2 core CPU e 2 GB di RAM. È il punto di partenza corretto per un piccolo deployment. Dai al server più margine quando PostgreSQL, outpost aggiuntivi, la sincronizzazione delle directory o un traffico di login più intenso condividono lo stesso host.
Requisiti VPS per ZITADEL
Il deployment Docker Compose ufficiale di ZITADEL richiede almeno 2 GB di RAM per l'host. Dimensiona un VPS tutto-in-uno per ZITADEL, la sua interfaccia di login, PostgreSQL e il reverse proxy insieme, invece di considerare il servizio Go isolatamente.
Requisiti VPS per Keycloak
La documentazione sui container di Keycloak consiglia un limite di memoria di 2 GB per i deployment Keycloak più piccoli pronti per la produzione. Quel valore si applica al solo container Keycloak, non a un intero VPS che esegue anche PostgreSQL.
Se Keycloak e PostgreSQL condividono un VPS, 4 GB di RAM di sistema sono un punto di partenza sensato. Consideralo un'indicazione pratica per l'host, non il minimo ufficiale di Keycloak.
Requisiti VPS per Authelia
Authelia non pubblica un minimo per il server di 1 GB o 2 GB direttamente confrontabile. Dimensiona l'host per Authelia insieme al reverse proxy, al backend di storage, alla directory utenti e a qualsiasi altro servizio che condivide la macchina.
Authelia ha in genere un'impronta di deployment più piccola rispetto a un IdP completo affiancato da PostgreSQL, ma i requisiti VPS reali dipendono dal resto dello stack.
Esempio di configurazione: Authentik con Vaultwarden
Vaultwarden ha aggiunto il supporto nativo all'SSO OpenID Connect nella versione 1.35.0, a dicembre 2025. Authentik è un esempio utile perché l'integrazione espone i pezzi OIDC che incontrerai anche con altre applicazioni: URI di redirect, credenziali client, scope, URL dell'issuer e accesso di emergenza.
Configurazione di base di Authentik
In Authentik:
- Crea una mappatura personalizzata dello scope email per Vaultwarden. Vaultwarden richiede che lo scope email restituisca email_verified: true oppure nessun valore email_verified, mentre lo scope email predefinito di Authentik attualmente restituisce false.
- Crea una coppia applicazione e provider OAuth2/OpenID Connect.
- Aggiungi https://vault.example.com/identity/connect/oidc-signin come URI di redirect rigoroso di tipo Authorization.
- Seleziona una qualsiasi chiave di firma disponibile.
- Annota Client ID, Client Secret e lo slug dell'applicazione.
- Imposta la validità dell'access token a più di cinque minuti.
- Aggiungi la mappatura offline_access di Authentik agli scope selezionati.
- Sostituisci la mappatura email predefinita con la mappatura personalizzata per email verificata del passaggio 1.
Configurazione OIDC di base di Vaultwarden
Usa:
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=trueSostituisci i domini di esempio, lo slug dell'applicazione, il client ID e il client secret con i valori del tuo deployment, poi riavvia Vaultwarden.
Cosa testare prima di imporre l'SSO
Lascia SSO_ONLY impostato su false mentre testi login, logout, rinnovo dei token, abbinamento degli account e ripristino. Testa anche cosa succede quando Authentik è temporaneamente non disponibile.
Una volta che sia l'SSO sia il ripristino funzionano come previsto, puoi decidere se richiedere l'SSO per ogni login ha senso per il tuo deployment.
Gli stessi concetti OIDC valgono per altre applicazioni self-hosted, ma URI di redirect, scope, claim e licenze differiscono. Consulta la documentazione SSO di ogni applicazione invece di copiare direttamente la configurazione di Vaultwarden.
Quando Authelia è meglio di un IdP completo
Authelia diventa più interessante quando l'applicazione non ha alcun bisogno di capire l'identity provider.
Autenticazione al reverse proxy
Authelia è progettato principalmente per proteggere le applicazioni a livello di reverse proxy. Tu definisci regole di controllo accessi e Authelia decide se una richiesta debba raggiungere il backend prima che l'applicazione stessa gestisca l'autenticazione.
Proteggere app senza OIDC
È utile per vecchi strumenti interni, dashboard e servizi che non supportano OIDC o SAML. Invece di modificare ogni applicazione, puoi mettere l'autenticazione davanti ad essa, al reverse proxy.
Authelia può anche fungere da provider OIDC, ma l'autenticazione al reverse proxy resta il suo punto di forza principale.
Usare Authelia insieme ad Authentik
Puoi usare Authentik per le applicazioni che supportano OIDC o SAML e Authelia per quelle che hanno bisogno dell'autenticazione al reverse proxy.
Non ti servono necessariamente entrambi. Anche Authentik supporta la protezione delle applicazioni tramite proxy, quindi usare Authelia al suo fianco ha senso solo quando il flusso reverse proxy di Authelia risolve in modo più pulito una parte specifica del tuo stack.
Domande frequenti
Authentik è meglio di Keycloak?
Per la maggior parte degli homelab e dei piccoli stack di applicazioni self-hosted, Authentik è più accessibile. Il suo flusso di amministrazione si concentra su applicazioni, provider, gruppi e policy senza esporre tutta insieme così tanta complessità IAM.
Keycloak ha più senso quando ti servono specificamente la sua federazione più profonda, il modello a realm o gli Authorization Services. Authentik è la scelta predefinita più solida per un SSO self-hosted più semplice; Keycloak si adatta agli ambienti che hanno bisogno di quei controlli aggiuntivi.
ZITADEL è meglio di Keycloak?
ZITADEL è più adatto quando stai costruendo un prodotto e vuoi identità gestita via API, organizzazioni e multi-tenancy. Keycloak è più adatto quando ti servono il suo modello di autorizzazione più profondo, gli ampi controlli di federazione o un ambiente già costruito attorno a Keycloak.
Qual è la differenza tra Authentik e Authelia?
Authentik è un identity provider completo costruito attorno a utenti, gruppi, applicazioni, provider, flussi e policy. Le applicazioni possono integrarsi con esso direttamente tramite protocolli come OIDC e SAML.
Authelia è incentrato sull'autenticazione e sul controllo accessi al reverse proxy. Include anche un provider OIDC, ma la protezione al reverse proxy resta il suo caso d'uso principale.
Scegli Authentik quando le applicazioni si integrano direttamente con un IdP. Scegli Authelia quando l'autenticazione deve avvenire soprattutto prima che il traffico raggiunga l'applicazione.
Posso far girare Authentik su un VPS da 1 GB?
Non come punto di partenza supportato. La documentazione Docker Compose attuale di Authentik richiede almeno 2 core CPU e 2 GB di RAM. Il deployment di base attuale usa il server Authentik, il worker e PostgreSQL; Redis è stato rimosso completamente in Authentik 2025.10.
Usa 2 GB come punto di partenza minimo per una piccola installazione e aggiungi margine quando altri servizi condividono la macchina.
Vaultwarden supporta l'SSO OIDC?
Sì. Vaultwarden ha aggiunto il supporto all'SSO OpenID Connect nella versione 1.35.0, a dicembre 2025. Richiede un provider OIDC esterno come Authentik, Keycloak o ZITADEL.
La configurazione esatta dipende dal provider. Con le release attuali di Authentik, l'integrazione documentata include una mappatura personalizzata dello scope email verificata, offline_access, le credenziali client e l'URL dell'issuer dell'applicazione Authentik.
Devo far girare il mio IdP sullo stesso VPS delle mie app?
Per un homelab in cui un'interruzione è accettabile, ospitarli insieme può essere ragionevole. Per applicazioni critiche per il business, un VPS separato dà all'identity provider il proprio budget di risorse e toglie il server applicativo dal dominio di guasto condiviso.
Questo non crea alta disponibilità di per sé, ma un riavvio del server applicativo, un problema di risorse o una compromissione non butta più giù automaticamente anche l'IdP.
Quale SSO self-hosted è il più facile da usare?
Authentik è il punto di partenza più facile per la maggior parte delle persone che collegano applicazioni self-hosted esistenti. La sua interfaccia di amministrazione rende applicazioni, provider, gruppi e policy più accessibili rispetto al modello più ampio di realm e autorizzazione di Keycloak.
Authelia può essere più semplice quando ti serve solo l'autenticazione al reverse proxy. ZITADEL ha più senso quando la persona che configura l'identità è uno sviluppatore che lavora principalmente tramite API.
Discussione
Commenti
Accedi per partecipare alla discussione.