🔐SSO Authelia

Authelia est un serveur d’authentification et d’autorisation open source fournissant une authentification à deux facteurs et une authentification unique (SSO) pour vos applications via un portail Web.

SSO Authelia

Site web officiel : https://www.authelia.com/

• Open source
• SSO
• Authentification 2F avec Yubikey
• OTP basé sur le temps avec Google Authenticator
• Prend en charge LDAP
• Prend en charge Active Directory
• Fonctionne avec les proxys inverses
• Notifications push avec duo
• Bloquer les attaques de force brute
• Vérification d’identité
• Une meilleure gestion des mots de passe
• Flux de travail flexible
• UI intuitif

Prérequis et liens

Un serveur debian + nginx

Installation deb ou binaire

Installation par fichier deb

# Téléchargement fichier deb
wget https://github.com/authelia/authelia/releases/download/v4.39.13/authelia_4.39.13-1_amd64.deb
# droits à l'utilisateur _apt pour l'installation
sudo chown _apt: authelia_4.39.13-1_amd64.deb
# installation authelia et ses dépendances
sudo apt install ./authelia_4.39.13-1_amd64.deb
# redis est utilisé
sudo apt install redis

Installation binaire

# Téléchargement 
wget https://github.com/authelia/authelia/releases/download/v4.39.19/authelia-v4.39.19-linux-amd64.tar.gz
tar xzvf authelia-v4.39.19-linux-amd64.tar.gz
# Mise à jour binaire
# si timer 
sudo systemctl stop authelia.timer
sudo systemctl stop authelia.service 
sudo cp authelia /usr/bin/authelia
# si timer
sudo systemctl start authelia.timer
sudo systemctl start authelia.service 
# Effacer
rm authelia*
# version
authelia -v  # authelia version v4.39.19

Générateur id et secret client

Authelia fournit un moyen simple d’effectuer de telles actions.

ID client

Les utilisateurs peuvent facilement générer un identifiant/identifiant client en suivant le guide Génération d’une chaîne alphanumérique aléatoire
Par exemple, les utilisateurs peuvent exécuter la commande

authelia crypto rand --length 72 --charset rfc3986

pour générer un identifiant/identifiant client de 72 caractères qui est imprimé.
Cette commande aléatoire évite également les problèmes avec une application client/partie de confiance codant correctement les caractères car elle utilise les caractères non réservés RFC3986 .

Si un jeu de caractères différent est utilisé et que la valeur est différente lors du codage de l’URL, il imprimera également cette valeur séparément.

secret client

Les utilisateurs peuvent facilement générer un secret client en suivant le guide Génération d’un hachage de mot de passe aléatoire
Par exemple, les utilisateurs peuvent exécuter la commande

authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986

⚠️ Veuillez noter le mot de passe en clair ainsi que le hachage $pbkdf2 du mot de passe pour une utilisation ultérieure.

pour à la fois générer un secret client de 72 caractères qui est imprimé et doit être utilisé avec la partie utilisatrice et le hacher à l’aide de PBKDF2 qui peut être stocké dans la configuration Authelia. Cette commande aléatoire évite également les problèmes avec une application client/partie de confiance codant correctement les caractères car elle utilise les caractères non réservés RFC3986 .

Si un jeu de caractères différent est utilisé et que la valeur est différente lors du codage de l’URL, il imprimera également cette valeur séparément.

Réglage des facteurs de travail

Lors du hachage des secrets du client, Authelia effectue l’opération de hachage pour authentifier le client lors de la réception des demandes. Cette opération de hachage prend du temps, de par sa conception (la partie travail du facteur travail) pour empêcher un attaquant de tenter d’obtenir le secret client. Le temps nécessaire dépend de votre matériel et du facteur de travail.

Si les opérations de votre client expirent, vous devrez peut-être réduire le facteur de travail à un niveau approprié pour votre client et les capacités de votre matériel.

Pour tester la durée de différents facteurs de travail, vous pouvez la mesurer ainsi :

time authelia crypto hash generate pbkdf2 --variant sha512 --iterations 310000 --password insecure_password

Générer une chaîne alphanumérique aléatoire

Certaines sections de la configuration recommandent de générer une chaîne aléatoire. Il y a plusieurs façons d’accomplir cela et la Les méthodes suivantes ne sont que des suggestions.

Authelia. Le conteneur de docker Authelia ou binaire CLI peut être utilisé pour générer une chaîne alphanumérique aléatoire.

Utilisez le authelia crypto rand --helpcommander ou voir le guide de référence authelia crypto rand pour plus d’informations sur toutes les options disponibles.

authelia crypto rand --length 64 --charset alphanumeric

OpenSSL. La commande openssl sur Linux peut être utilisée pour générer une chaîne alphanumérique aléatoire:

openssl rand -hex 64

Linux de base. Les commandes Linux de base peuvent être utilisées pour générer une chaîne alphanumérique aléatoire:

LENGTH=64
tr -cd '[:alnum:]' < /dev/urandom | fold -w "${LENGTH}" | head -n 1 | tr -d '\n' ; echo

Configuration

Configuration authelia sur serveur cwwk rnmkcy.eu 192.168.0.205

• Serveur: 127.0.0.1:9091
• Gestion utilisateurs: LLDAP
• Authentification: TOTP + Webauthnn
• Stockage: Base mysql
• Notification: SMTP

Clé de configuration	Signification	Exemple
jwt_secret	Une chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > jwt_secret.txt et collez-la ici entre guillemets.
default_redirection_url	Si l’utilisateur navigue directement vers auth.myhome.com, Authelia ne peut pas déduire où le rediriger. Il s’agira donc probablement d’une page lister-toutes-les-applications-disponibles	https://www.myhome.com
default_2fa_method	2FA est l’abréviation de 2 factor authentication (authentification à deux facteurs). Il s’agit du processus ennuyeux qui vous demande d’entrer le code que vous avez reçu par SMS ou par l’intermédiaire d’une application d’authentification.	“totp”, au moins c’est gratuit
server/host	Attention! Le serveur d’authentification est un serveur qui ne peut pas être utilisé par les utilisateurs de l’Internet. Si vous laissez la valeur par défaut 0.0.0.0 alors Authelia écoutera sur l’interface réseau de votre serveur. Mais ce n’est pas ce que vous voulez une fois que le serveur est en production, puisque nous allons le faire fonctionner derrière un reverse proxy pour HTTPS.	Lors de la configuration, laissez 0.0.0.0 mais changez pour 127.0.0.1 une fois que tout est configuré.
log/level	Changez pour info une fois que tout est en cours d’exécution	info
authentication_backend	Activez les sous-clés file et file/path pour faciliter l’utilisation dans un premier temps. Ci-dessous, vous trouverez ce qu’il faut stocker dans ce chemin d’accès	Changez path en /etc/authelia/users_db.yml
access_control	Cette partie est un peu complexe, donc regardez ci-dessous pour une explication	Voir ci-dessous
access_control/rule/…/policy	N’importe lequel de deny (rejette la requête), bypass (relai transparent de la connexion), one_factor (demande de login & mots de passe), two_factor (demande de login & mot de passe + preuve de possession d’un appareil)	Voir ci-dessous pour un exemple
session/domain	Typiquement, définir le domaine de base	myhost.com
session/secret	Une autre chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > session_secret.txt et collez-la ici entre guillemets.
storage	Activez cette option, car elle est nécessaire pour stocker les données de session.
storage/encryption_key	Une autre chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > session_secret.txt et collez-la ici entre guillemets
notifier	Vous devez définir au moins un notificateur pour que Authelia puisse communiquer avec vous et ses utilisateurs

LLDAP

LLDAP est utilisé pour la gestion utilisateur

Stockage géré par une base mariadb (mysl)
Créer une base mariadb
Host : 127.0.0.1
Base : authelia
Utilisateur : authelia
Mot de passe : Mot_de_passe_base_authelia

En ligne de commande

sudo mariadb -e "create database authelia; grant all privileges on authelia.* to authelia@'localhost' identified by 'Mot_de_passe_base_authelia'; flush privileges;"

WebAuthn

Paramètre user_verification :

• discouraged : Le client sera découragé de demander une vérification à l’utilisateur.
• preferred : Le client, s’il est conforme, demandera à l’utilisateur une vérification si l’appareil la prend en charge.
• required : Le client demandera à l’utilisateur une vérification ou échouera si l’appareil ne prend pas en charge la vérification.

attestation_conveyance_preference:

• none : Le client recevra l’instruction de ne pas effectuer de transfert de propriété.
• indirect : Le client reçoit l’instruction d’effectuer le transfert de propriété, mais il peut choisir la manière de le faire, y compris en utilisant une AC d’anonymisation tierce.
• direct : Le client recevra l’instruction d’effectuer le transfert avec une déclaration d’attestation directement signée par le dispositif.

Activation service authelia

Lancer, activer et vérifier

sudo systemctl enable authelia --now
sudo journalctl -u authelia 

oct. 30 18:56:33 alder systemd[1]: Started authelia.service - Authelia authentication and authorization server.

auth.rnmkcy.eu

Comme Authelia affiche une page de connexion/authentification, il doit être exécuté sur un canal de transport crypté pour éviter les attaques de l’homme du milieu (MITM).

Il ne démarrera pas tant que ce canal n’aura pas été correctement configuré.

Comme d’habitude avec HTTPS, pour démarrer une connexion TLS, vous avez besoin d’un certificat. La solution la plus simple est d’utiliser Let’s Encrypt ou ZeroSSL avec son outil certbot pour automatiser la récupération et le renouvellement des certificats. Il ne s’agit pas d’un tutoriel sur la mise en place du HTTPS, donc je liste les étapes à réaliser avec un reverse proxy NGINX, n’hésitez pas à personnaliser si vous utilisez un autre reverse proxy pour le HTTPS.

Proxy nginx

Le fichier /etc/nginx/conf.d/auth.rnmkcy.eu.conf

server {
    listen 80;
    server_name auth.rnmkcy.eu;

    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name auth.rnmkcy.eu;

    include /etc/nginx/conf.d/ssl-modern.inc;
    ssl_session_cache shared:SSL:2m;

    location / {
        set $upstream_authelia http://127.0.0.1:9091;
        proxy_pass $upstream_authelia;

        client_body_buffer_size 128k;

        #Timeout if the real server is dead
        proxy_next_upstream error timeout invalid_header http_500 http_502     http_503;

        # Advanced Proxy Config
        send_timeout 5m;
        proxy_read_timeout 360;
        proxy_send_timeout 360;
        proxy_connect_timeout 360;

        # Basic Proxy Config
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Uri $request_uri;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_redirect  http://  $scheme://;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_cache_bypass $cookie_session;
        proxy_no_cache $cookie_session;
        proxy_buffers 64 256k;

        # If behind reverse proxy, forwards the correct IP
#        set_real_ip_from 10.0.0.0/8;
#        set_real_ip_from 192.168.10.0/16;
#        set_real_ip_from 192.168.0.0/16;
#        set_real_ip_from fc00::/7;
#        real_ip_header X-Forwarded-For;
#        real_ip_recursive on;
    }

}

Recharger nginx

sudo systemctl reload nginx

Dirigez votre navigateur vers https://auth.rnmkcy.eu et vous devriez voir apparaître la page de connexion de Authelia.

Modifier votre application pour le SSO

Authelia affiche une page de connexion/authentification, il doit être exécuté sur un canal de transport https

L’application doit être adaptée pour traiter avec un serveur d’authentification externe.
Lorsque Authelia a validé l’utilisateur, il redirige vers votre application.
Cette redirection contient des en-têtes spécifiques que votre application doit traiter pour procéder à sa création de session habituelle (typiquement, votre application émettra son Set-Cookie ou une requête de stockage local ou un jeton JWT ou …).
Il s’agit simplement de contourner la page de connexion.

Nginx snippets

Création dossier snippets

sudo mkdir -p /etc/nginx/snippets

Les fichiers de configuration nginx

Le premier extrait est une route interne /authelia qui n’est pas accessible depuis l’internet, qui est utilisée dans vos applications pour affirmer que la session Authelia est valide.

Snippet authelia.conf

sudo nano /etc/nginx/snippets/authelia.conf

Contenu

# Point de terminaison virtuel créé par nginx 
# pour transférer les demandes d’authentification.
# Internal Authelia verify endpoint
location = /authelia {
    # accessible uniquement en interne (subrequests) — requêtes externes → 404
    internal;
    # n'envoie pas le corps de la requête au backend (gain d'efficacité)
    proxy_pass_request_body off;
    # neutralise Content-Length (évite d'envoyer une taille quand pas de body)
    proxy_set_header Content-Length "";
    # transmet l'hôte original ($host) au backend
    proxy_set_header Host $host;
    # URL complète d'origine (schéma://host + request_uri)
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    # indique le protocole d'origine (http ou https)
    proxy_set_header X-Forwarded-Proto $scheme;
    # transmet l'hôte d'origine (inclut le port si présent)
    proxy_set_header X-Forwarded-Host $http_host;
    # transmet l'URI d'origine (chemin + query string)
    proxy_set_header X-Forwarded-Uri $request_uri;
    # ajoute l'IP cliente à X-Forwarded-For (conserve proxys intermédiaires)
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # envoie l'IP source de la connexion nginx (IP client directe)
    proxy_set_header X-Real-IP $remote_addr;
    # redirige la sous-requête vers l'API interne Authelia /api/verify sur localhost:9091
    proxy_pass http://127.0.0.1:9091/api/verify;
    # délai maximum pour lire la réponse du backend = 10 secondes
    proxy_read_timeout 10s;
}

Vous aurez aussi besoin d’un snippet pour l’authentification (interne) elle-même, donc sauvegardez ce snippet sous /etc/nginx/snippets/auth.conf:
Typiquement, ce snippets fait en sorte que NGINX génère une requête vers l’emplacement interne /authelia à chaque fois qu’une requête d’utilisateur est faite vers votre application. Il vérifie le code de résultat HTTP de la requête interne. Si c’est 200, la requête de l’utilisateur est acceptée, sinon il est redirigé vers la page de login Authelia.

Snippet auth.conf

sudo nano /etc/nginx/snippets/auth.conf

Contenu

# Protect with Authelia
# effectue une sous-requête interne vers /authelia pour vérifier l'accès
auth_request /authelia;
# stocke l'URL complète demandée (schéma://host+URI) dans la variable $target_url
auth_request_set $target_url $scheme://$http_host$request_uri;
# récupère le header Remote-User renvoyé par Authelia (nom d'utilisateur authentifié)
auth_request_set $user $upstream_http_remote_user;
# récupère le header Remote-Groups renvoyé par Authelia (groupes / rôles)
auth_request_set $groups $upstream_http_remote_groups;
# transmet l'utilisateur authentifié au backend en tant que header Remote-User
proxy_set_header Remote-User $user;
# transmet les groupes de l'utilisateur au backend en tant que header Remote-Groups
proxy_set_header Remote-Groups $groups;

# en cas de 401 (non autorisé) renvoie une redirection 302 vers le portail d'authentification,
# avec ?rd=<URL d'origine> pour que l'IDP puisse rediriger l'utilisateur vers la ressource demandée après login
error_page 401 =302 https://auth.rnmkcy.eu/?rd=$target_url;

Exemple de protection

• Un exemple de SSO avec Authelia et Owntone
• Security key

Enfin, dans la description de votre site d’application, vous devrez inclure ces extraits. Le fichier authelia.conf va dans le bloc serveur et le fichier auth.conf va dans n’importe quel endroit que vous voulez protéger.
Vous éviterez typiquement de protéger les actifs statiques et les redirections, puisqu’il n’y a pas d’intérêt à vérifier l’authentification pour ceux-ci.

Application site

Authentification Totp Yubikeys Passkeys

Totp

On va ajouter une authentification TOTP
Se connecter sur authelia et cliquer sur authelia

Mot de passe usage unique

Sur la boîte de réception

Saisir le code ID

Suivre la procédure

Si vous n”avez pas google authenticator
Prendre une photo avec l’appareil android pour décoder

Cliquer sur le lien pour copier le code

Copier le contenu de secret dans le totp de cockpit keepassxc

Cliquer sur suivant et décocher qrcode

Vérification fonctionnement avec un code généré par cockpi keepassxc

Si tout est OK

et un message de confirmation

Yubikeys WebAuthn

Configuration authelia prérequise

## WebAuthn Actif
##
webauthn:
  ## Désactiver Webauthn avec true.
  disable: false

# l'application web utilisant la double authentification
access_control:
  default_policy: deny
  rules:
    - domain:
        - "site.rnmkcy.eu"
      policy: two_factor

Clé yubikey insérée dans un port USB

Se connecter sur le lien https://auth.rnmkcy.eu avec Firefox
Saisir utilisateur “yann” et son mot de passe

Choisir la méthode

Un message est envoyé

Sur la boîte de réception

Saisir le code ID

Une nouvelle fenêtre s’ouvre

La clé est enregistrée

et un message de confirmation

Se connecter de nouveau à cockpit

Page de connexion auhelia

Validation par clé

Page authentification cockpit

Ajouter une autre clé yubikey
La seconde clé est enregistrée

et un message de confirmation

Passkeys KeepassXC

Si l’application KeepassXC et son extension firefox sont actifs il est possible de créer une passkey

Authelia

KeepassXC

OIDC certificat fournisseur et client

La configuration Authelia est définie dans le fichier configuration.yml. Ce fichier permet de définir les paramètres de configuration OIDC nécessaires, tels qu’un fournisseur et un client.

En consultant la documentation publique OIDC d’Authelia , nous pouvons obtenir un exemple de configuration. Cet exemple de configuration contient plusieurs paramètres nécessitant soit une valeur secrète, soit un certificat.

Ces éléments doivent être générés de manière sécurisée avant d’ajuster la configuration. Par conséquent, générons-les !

Création d’un certificat RSA

Authelia vous oblige à définir un certificat (clé privée) via la directive key et une chaîne de certificats (clé publique) via la directive certificate_chain.

Vous pouvez générer les deux via la commande suivante :

authelia crypto certificate rsa generate --common-name auth.rnmkcy.eu && cat public.crt && cat private.pem

⚠️ Veuillez ajuster le nom commun du certificat à votre FQDN d’Authelia

Création fournisseur OIDC

Une fois le certificat RSA et le secret client créés de manière sécurisée, nous pouvons commencer à ajuster le fichier de configuration d’Authelia. Nous ajouterons un fournisseur d’identité en insérant nos secrets et informations de certificat auto-générés.

Mettez ce qui suit à la fin de votre configuration Authelia :

identity_providers:
  oidc:
    hmac_secret: 'my-secure-hmac-secret-key-to-change'
    jwks:
      - key_id: 'authelia'
        algorithm: 'RS256'
        use: 'sig'
        certificate_chain: |
          -----BEGIN CERTIFICATE-----
          <PASTE-HERE-YOUR-PUBLIC-KEY-DATA> sur une ligne
          -----END CERTIFICATE-----
        key: |
          -----BEGIN PRIVATE KEY-----
          <PASTE-HERE-YOUR-PRIVATE-KEY-DATA> sur une ligne
          -----END PRIVATE KEY-----
    cors:
      endpoints:
        - authorization
        - token
        - revocation
        - introspection
        - userinfo
      allowed_origins:
        - https://auth.rnmkcy.eu #Enter Domain Name
      allowed_origins_from_client_redirect_uris: false

Vérifier la configuration en mode su

sudo authelia validate-config --config /etc/authelia/configuration.yml

Vous devez obtenir le message suivant, si tout est correct
Configuration parsed and loaded successfully without errors.

Maintenance

Erreur au démarrage

Dans le cas d’un redémarrage de la machine, une erreur se produit et le service authelia n’est pas lancé

systemctl status authelia

Une erreur s’est produite au démarrage

× authelia.service - Authelia authentication and authorization server
     Loaded: loaded (/usr/lib/systemd/system/authelia.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2026-01-14 21:34:38 CET; 10h ago
   Duration: 7.091s
 Invocation: c58e773f19df4fa4a895fb0b630b3cb7
       Docs: https://www.authelia.com
    Process: 1678 ExecStart=/usr/bin/authelia --config /etc/authelia/configuration.yml (code=exited, status=1/FAILURE)
   Main PID: 1678 (code=exited, status=1/FAILURE)
   Mem peak: 67.8M
        CPU: 104ms

Si on relance le service, tout est correct. Il faut lancer le service authelia après un délai

Créer un déclencheur de minuterie pour lancer le service 1 minute après le démarrage du système (le minuteur utilise le même nom de service)

cat <<EOF | sudo tee /usr/lib/systemd/system/authelia.timer
[Unit]
Description=Timer service authelia

[Timer]
OnBootSec=1min

[Install]
WantedBy=timers.target
EOF

Recharger la configuration

sudo systemctl daemon-reload

Désactiver le service au démarrage.

sudo systemctl disable authelia

Activer la minuterie

sudo systemctl enable authelia.timer --now

Redémarrez le conteneur.

uptime

07:55:26 up 10:21, 1 user, load average: 101,02, 96,73, 84,61

Le service sera désactivé par défaut.

systemctl status authelia

● authelia.service - Authelia authentication and authorization server
     Loaded: loaded (/usr/lib/systemd/system/authelia.service; disabled; preset: enabled)
     Active: active (running) since Thu 2026-01-15 07:35:46 CET; 21min ago
 Invocation: 7998c201f1294f5ab189879b6fa39c1d
       Docs: https://www.authelia.com
   Main PID: 6356 (authelia)
      Tasks: 10 (limit: 38031)
     Memory: 39.1M (peak: 41.5M)
        CPU: 332ms
     CGroup: /system.slice/authelia.service
             └─6356 /usr/bin/authelia --config /etc/authelia/configuration.yml

janv. 15 07:35:46 alder systemd[1]: Started authelia.service - Authelia authentication and authorization server.

Timer le déclenchera automatiquement.

sudo systemctl list-timers 

Liste des timers

NEXT                                  LEFT LAST                              PASSED UNIT                         ACTIVATES                     
-                                        - Thu 2026-01-15 08:07:44 CET      42s ago authelia.timer               authelia.service

Authelia secrets

Utilisez une approche sécurisée basée sur des fichiers et évitez d’incorporer des secrets directement dans les modèles dédiés au contrôle de version.

Créer un dossier secrets avec les droits utilisateur “authelia”

sudo -u authelia mkdir -p /etc/authelia/secrets
# Créer les fichiers contenant les différents mot de passe
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/reset_password_jwt_secret
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/ldap_password
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/session_secret
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/storage_encryption_key
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/mysql_password
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/notifier_smtp_password
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/gitea_client_secret
echo "xxxxxxxxxxxxxxxx" | sudo -u authelia tee /etc/authelia/secrets/stalwart_client_secret

modifier les droits

sudo chmod 600 /etc/authelia/secrets/*

Modifier le fichier de configuration /etc/authelia/configuration.yml Vérifier la configuration et redémarrer le service authelia si aucune erreur

sudo authelia validate-config --config /etc/authelia/configuration.yml
sudo systemctl restart authelia