Authentik : du SSO façon Okta sans payer par utilisateur

Après avoir déployé cinq ou six services auto-hébergés — Nextcloud, Gitea, Mattermost, Grafana — le problème se répète : chaque app a son propre compte, son propre mot de passe, sa propre gestion du 2FA. Okta ou Auth0 résolvent ça en entreprise, mais facturent par utilisateur actif. Authentik fait le même travail : un fournisseur d'identité central, devant lequel chaque application self-hosted redirige pour l'authentification.

Authentik est un serveur d'identité et d'accès (IAM). Il centralise les comptes utilisateurs, gère le 2FA (TOTP, WebAuthn, clés de sécurité physiques), et parle les protocoles standards que la plupart des applications modernes supportent nativement : OAuth2/OIDC, SAML, LDAP, et un mode proxy générique pour les apps qui ne parlent aucun de ces protocoles. Une fois connecté à Authentik, l'utilisateur accède à toutes les apps intégrées sans se reconnecter.

Installation avec Docker Compose

services:
  postgresql:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_PASSWORD: authentikpass
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik
    volumes:
      - database:/var/lib/postgresql/data
 
  redis:
    image: redis:alpine
    restart: always
 
  server:
    image: ghcr.io/goauthentik/server:latest
    command: server
    restart: always
    environment:
      AUTHENTIK_SECRET_KEY: une-clé-longue-générée
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__PASSWORD: authentikpass
      AUTHENTIK_REDIS__HOST: redis
    ports:
      - "9000:9000"
    depends_on:
      - postgresql
      - redis
 
  worker:
    image: ghcr.io/goauthentik/server:latest
    command: worker
    restart: always
    environment:
      AUTHENTIK_SECRET_KEY: une-clé-longue-générée
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__PASSWORD: authentikpass
      AUTHENTIK_REDIS__HOST: redis
    depends_on:
      - postgresql
      - redis
 
volumes:
  database:

AUTHENTIK_SECRET_KEY chiffre les sessions et doit être générée une seule fois puis conservée — openssl rand -base64 60 fait l'affaire. Premier accès sur http://votre-serveur:9000/if/flow/initial-setup/ pour créer le compte administrateur akadmin.

Connecter une application via OAuth2

La plupart des applications modernes (Grafana, Gitea, Nextcloud) supportent OAuth2/OIDC nativement. Côté Authentik, créer un Provider puis une Application :

Providers > Créer > OAuth2/OIDC Provider
  Client type : Confidential
  Redirect URI : https://grafana.mondomaine.fr/login/generic_oauth
  Scopes : openid, email, profile

Authentik génère un Client ID et un Client Secret à coller dans la config de l'application cible :

[auth.generic_oauth]
enabled = true
name = Authentik
client_id = CLIENT_ID_GENERE
client_secret = CLIENT_SECRET_GENERE
scopes = openid email profile
auth_url = https://auth.mondomaine.fr/application/o/authorize/
token_url = https://auth.mondomaine.fr/application/o/token/
api_url = https://auth.mondomaine.fr/application/o/userinfo/

Une fois configuré, se connecter à Grafana redirige vers Authentik, demande les identifiants (et le 2FA si activé), puis renvoie vers Grafana déjà authentifié.

Mode proxy pour les apps sans OAuth natif

Certaines applications self-hosted (Uptime Kuma, un dashboard interne custom) n'implémentent aucun protocole SSO. Authentik couvre ce cas avec un Proxy Provider : il s'intercale en reverse proxy devant l'app et bloque l'accès tant que l'utilisateur n'est pas authentifié auprès d'Authentik.

location / {
    auth_request /outpost.goauthentik.io/auth/nginx;
    error_page 401 = @goauthentik_proxy_signin;
    proxy_pass http://uptime-kuma:3001;
}
 
location /outpost.goauthentik.io {
    proxy_pass http://authentik-proxy:9000/outpost.goauthentik.io;
}

Cette approche protège n'importe quel service HTTP interne derrière une authentification centralisée, même un vieux script maison qui n'a jamais entendu parler d'OAuth.

2FA et clés de sécurité

Authentik supporte TOTP (Google Authenticator, Aegis), les notifications push via son app mobile, et WebAuthn pour les clés physiques (YubiKey, Titan Key). La politique de 2FA se configure par flux d'authentification — possibilité d'exiger le 2FA uniquement pour les comptes admin, ou pour tout le monde.

Flows > default-authentication-flow > Stages
  Ajouter : Authenticator Validation Stage
  Types autorisés : TOTP, WebAuthn

LDAP pour les apps legacy

Pour les applications qui ne parlent que LDAP (certains NAS, certains outils d'entreprise anciens), Authentik expose un outpost LDAP qui traduit les requêtes LDAP vers son propre annuaire d'utilisateurs — évite de maintenir un second annuaire séparé juste pour ces cas.

Authentik vs Keycloak vs Authelia

Authelia est plus simple à déployer mais se limite au rôle de forward-auth devant un reverse proxy — pas de gestion OAuth2/SAML complète. Keycloak est la référence historique côté entreprise mais tourne sur la JVM, plus lourd sur un petit serveur. Authentik occupe le terrain intermédiaire : interface soignée, protocoles complets, sans le poids de Keycloak.

Authentik demande de comprendre les bases d'OAuth2 et de SAML pour en tirer pleinement parti — ce n'est pas le projet par lequel commencer son parcours self-hosted. Mais une fois cinq ou six services déployés derrière Docker, centraliser l'authentification et le 2FA en un seul endroit élimine la dette de sécurité qui s'accumule silencieusement à chaque nouveau compte créé.