Authentik: il mio SSO centralizzato con OAuth2 e OpenID Connect¶

Un unico login per governarli tutti — come ho unificato l'accesso a tutti i miei servizi self-hosted con Authentik

Se gestisci un homelab con più servizi, conosci bene la noia di ricordare N credenziali diverse per N applicazioni diverse. Proxmox, Nextcloud, Gitea, Portainer, il blog… ognuno con la sua pagina di login, il suo database di utenti, le sue regole di sessione.

Ho risolto tutto questo con Authentik, un Identity Provider open-source che funge da SSO (Single Sign-On) per tutta la mia infrastruttura — incluso questo blog che stai leggendo adesso.

Cos'è Authentik¶

Authentik è un Identity Provider (IdP) moderno e self-hosted. Supporta i protocolli standard del settore:

• OAuth2 / OpenID Connect (OIDC) — per autenticare app web e API
• SAML 2.0 — per integrazioni enterprise
• LDAP — come proxy verso directory esistenti
• SCIM — per il provisioning automatico degli utenti
• Proxy — per proteggere app che non supportano nativamente alcun protocollo

In pratica, Authentik diventa il punto centrale di fiducia: le applicazioni delegano il login ad Authentik, che gestisce l'identità, le sessioni e i permessi. L'utente si autentica una volta sola e accede a tutto.

La mia infrastruttura¶

Il mio server principale è una macchina OVH su cui gira Proxmox VE. All'interno ho diverse VM e LXC container, tra cui:

• Una VM dedicata con Docker dove vive Authentik
• Una VM con NGINX come reverse proxy (con certificati Let's Encrypt via Cloudflare)
• VM/LXC per i vari servizi: Nextcloud, Gitea, Portainer, questo blog, e altri

Authentik è raggiungibile all'indirizzo auth.gwserver.it e funge da IdP per tutti i servizi sopra elencati.

Stack Docker di Authentik¶

Authentik si compone di due soli container — server e worker — perché ho scelto di non includere PostgreSQL e Redis nel compose di Authentik: li ho esternalizzati su istanze già esistenti nella mia rete interna.

services:
  server:
    image: ghcr.io/goauthentik/server:2026.2.2
    restart: unless-stopped
    command: server
    env_file:
      - .env
    volumes:
      - /home/hersel/docker-volume/authentik/media:/media
      - /home/hersel/docker-volume/authentik/custom-templates:/templates
    ports:
      - "9180:9000"
      - "9444:9443"

  worker:
    image: ghcr.io/goauthentik/server:2026.2.2
    restart: unless-stopped
    command: worker
    env_file:
      - .env
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /home/hersel/docker-volume/authentik/media:/media
      - /home/hersel/docker-volume/authentik/certs:/certs
      - /home/hersel/docker-volume/authentik/custom-templates:/templates

Tutta la configurazione sensibile sta in un file .env separato, che include le connessioni ai servizi esterni:

AUTHENTIK_SECRET_KEY=<chiave-segreta-generata>
AUTHENTIK_ERROR_REPORTING__ENABLED=false

# PostgreSQL su VM dedicata
AUTHENTIK_POSTGRESQL__HOST=192.168.1.99
AUTHENTIK_POSTGRESQL__PORT=5432
AUTHENTIK_POSTGRESQL__USER=authentik
AUTHENTIK_POSTGRESQL__NAME=authentik
AUTHENTIK_POSTGRESQL__PASSWORD=***

# Redis su VM esistente (condiviso con altri servizi)
AUTHENTIK_REDIS__HOST=192.168.1.79
AUTHENTIK_REDIS__PORT=6379
AUTHENTIK_REDIS__PASSWORD=***

Qualche nota sul setup:

• PostgreSQL (192.168.1.99) gira su un LXC container dedicato, condiviso tra più servizi dell'infrastruttura — non ha senso avere un'istanza Postgres per ogni applicazione
• Redis (192.168.1.79) è anch'esso un LXC container, la stessa istanza usata da Nextcloud e altri servizi — database separati, stesso server
• Le porte host sono 9180 (HTTP) e 9444 (HTTPS) — non quelle default — perché il reverse proxy NGINX fa da front-end e gestisce lui TLS verso l'esterno
• Il worker monta /var/run/docker.sock per poter interagire con il daemon Docker locale (necessario per alcune funzionalità come gli avamposti in-cluster)
• I volumi su /home/hersel/docker-volume/authentik/ contengono media caricati, template personalizzati e certificati gestiti dal worker

Il server espone l'interfaccia web e le API OIDC/OAuth2. Il worker gestisce i task asincroni: invio email, sincronizzazioni LDAP, esecuzione delle policy, gestione degli avamposti.

Come funziona l'integrazione: OAuth2 + OIDC¶

Per ogni applicazione che voglio integrare, in Authentik creo due elementi:

1. Provider¶

Il Provider definisce il protocollo e i parametri di autenticazione. Per OAuth2/OIDC configuro:

• Client ID e Client Secret — le credenziali che l'app userà per autenticarsi con Authentik
• Redirect URI — dove Authentik rimanda l'utente dopo il login
• Scopes — quali informazioni condividere (email, profilo, gruppi…)
• Signing Key — la chiave con cui Authentik firma i JWT

2. Application¶

L'Application in Authentik è la rappresentazione della tua app: nome, icona, URL di lancio e — crucialmente — le policy di accesso che determinano chi può loggarsi.

Il flusso è classico OAuth2 Authorization Code:

Utente → App → Redirect a Authentik → Login → Consent → 
Authorization Code → App scambia Code per Token → Accesso

Con OIDC, oltre all'access token, l'app riceve un ID Token (JWT) contenente le informazioni sull'utente — username, email, gruppi — senza dover fare ulteriori chiamate.

I servizi integrati¶

Attualmente ho 6 applicazioni collegate ad Authentik:

Tutte usano Fornitore OAuth2/OpenID — nessuna eccezione. Significa che ognuna di queste app delega completamente l'autenticazione ad Authentik.

Il blog stesso usa Authentik¶

Sì, anche questo blog che stai leggendo è protetto da Authentik. Il login avviene tramite il flusso OIDC standard: cliccando "Accedi" vieni rediretto su auth.gwserver.it, inserisci le credenziali una volta sola, e torni autenticato sul blog.

Questo è il bello del SSO: se hai già una sessione Authentik attiva (perché ti sei loggato su Nextcloud o su Gitea, per esempio), il login sul blog avviene in modo trasparente, senza reinserire le credenziali.

Perché Authentik e non altre soluzioni¶

Ho valutato diverse alternative prima di scegliere Authentik:

• Keycloak — potentissimo ma complesso da configurare e pesante in termini di risorse
• Authelia — ottimo come proxy di autenticazione, ma meno flessibile come IdP completo
• Zitadel — moderno e promettente, ma meno maturo della community
• Dex — minimale, pensato principalmente per Kubernetes

Authentik ha vinto per il bilanciamento tra funzionalità e usabilità: interfaccia admin chiara, documentazione buona, aggiornamenti frequenti e una community attiva. La UI di amministrazione è particolarmente ben fatta — basta guardare la dashboard con le statistiche di login per capire quanto sia utile in produzione.

Dashboard e monitoraggio¶

Una delle feature che apprezzo di più è la dashboard di panoramica: mostra in tempo reale login, autorizzazioni, accessi falliti per ogni applicazione. Si vede immediatamente chi sta usando cosa e se ci sono anomalie.

Dal pannello admin ho visibilità su:

• Stato avamposto — i proxy Authentik distribuiti nella rete
• Stato di sincronizzazione — utenti sincronizzati da LDAP o altre sorgenti
• App con maggior utilizzo — proxmox in testa con 28 login, seguito da Nextcloud e Portainer
• Log eventi — ogni login, autorizzazione e modifica registrata con utente, timestamp e IP

Conclusioni¶

Authentik ha trasformato la mia infrastruttura da un insieme di silos separati a un sistema coerente e governabile. Un singolo punto di autenticazione significa:

• Una sola password da memorizzare (o da gestire nel password manager)
• Revoca istantanea — disabilito un account in Authentik e l'utente perde accesso a tutto
• Visibilità centralizzata — so sempre chi ha fatto login dove e quando
• Onboarding semplice — aggiungere un nuovo servizio richiede pochi minuti

Se gestisci un homelab e non hai ancora un IdP centralizzato, ti consiglio di valutarlo seriamente. Il setup iniziale richiede qualche ora, ma il ritorno in termini di comodità e sicurezza vale abbondantemente l'investimento.