TinyAuth
TinyAuth est une application qui permet de forcer une authentification avant d'accéder à un servoce : une page de connexion que Swag peut insérer devant n'importe quelle application avant de laisser passer une requête, en vérifiant si le visiteur est authentifié avant de le rediriger.
Nativement il gère une simple connexion locale identifiant/mot de passe, c'est ce que nous mettrons en place ici. Il peut aussi déléguer la connexion à un fournisseur OIDC externe comme Pocket ID, de sorte que quiconque visite une application protégée s'authentifie avec une passkey via Pocket ID puis est redirigé : installez Pocket ID ensuite et suivez son tutoriel pour relier les deux.
Installation
- /
- srv
- docker
- tinyauth
- compose.yaml
- .env
- data
- tinyauth
- docker
- srv
Créer le dossier de données
sudo mkdir -p /srv/docker/tinyauth/data
Générer un hash de mot de passe
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --interactive
.env.Déployer la stack
Ouvrez Dockge, cliquez sur compose, nommez la stack tinyauth, et ajoutez la configuration suivante :
---
services:
tinyauth:
image: ghcr.io/tinyauthapp/tinyauth:v5
container_name: tinyauth
restart: unless-stopped
env_file:
- .env
volumes:
- /srv/docker/tinyauth/data:/data
ports:
- 3000:3000
---
services:
tinyauth:
#...
labels:
- com.centurylinklabs.watchtower.enable=true
Renseigner vos variables d'environnement
Remplissez le fichier .env :
TINYAUTH_APPURL=https://tinyauth.mondomaine.fr
TINYAUTH_AUTH_USERS=
| Variable | Valeur | Exemple |
|---|---|---|
TINYAUTH_APPURL | L'URL publique par laquelle vous joindrez TinyAuth (voir l'exposition plus bas) | https://tinyauth.mondomaine.fr |
TINYAUTH_AUTH_USERS | Le hash généré ci-dessus | user:$$2a$$10$$UdLYoJ5lgPsC0RKq... |
Déployez la stack. L'interface locale est disponible sur http://ipdevotreserveur:3000.
Terminé !
Activer l'authentification à deux facteurs
TinyAuth peut exiger un code TOTP issu d'une application d'authentification (Google Authenticator, Aegis...) en plus du mot de passe local, utilisateur par utilisateur. C'est une propriété de l'entrée utilisateur elle-même, pas une option de l'interface web.
Générer un secret TOTP
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 totp generate --interactive
Saisissez la paire username:hash générée lors de l'installation. TinyAuth affiche un QR code à scanner avec votre application d'authentification, puis produit la chaîne de connexion mise à jour sous la forme username:hash:secret.
docker run comme docker exec ont besoin des options -it ici : la commande est interactive et affiche le QR code dans le terminal, ce qui nécessite un TTY (et une fenêtre assez large) pour s'afficher correctement.Mettre à jour votre variable d'environnement
Remplacez l'entrée de cet utilisateur dans TINYAUTH_AUTH_USERS par la nouvelle chaîne username:hash:secret, puis redéployez la stack.
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user verify --interactive
Terminé !
À partir de maintenant, cet utilisateur a besoin à la fois de son mot de passe et d'un code valide de son application d'authentification pour se connecter.
Exposer TinyAuth avec Swag
TinyAuth a besoin de son propre sous-domaine : c'est la page sur laquelle les utilisateurs arrivent avant d'être redirigés vers l'application qu'ils veulent réellement.
tinyauth.mondomaine.fr avec un CNAME pointant vers mondomaine.fr dans votre zone DNS. Et bien sûr, à moins d'utiliser Cloudflare Zero Trust, le port 443 de votre box doit être redirigé vers le port 443 de votre serveur dans les règles NAT.Ajouter le réseau de TinyAuth à SWAG
Allez dans Dockge et modifiez le fichier compose de SWAG en y ajoutant le réseau de TinyAuth :
---
services:
swag:
container_name: # ...
# ...
networks: # Rattache le conteneur au réseau personnalisé
# ...
- tinyauth # Nom du réseau déclaré
networks: # Définit le réseau personnalisé
# ...
tinyauth: # Nom du réseau déclaré
name: tinyauth_default # Nom réel du réseau externe
external: true # Le marque comme défini à l'extérieur
Redéployez la stack et attendez que SWAG soit pleinement opérationnel.
tinyauth_default. Vous pouvez vérifier la connexion en visitant le tableau de bord de SWAG sur http://ipdevotreserveur:81.Créer le fichier subdomain.conf
Dans les dossiers de Swag, créez le fichier tinyauth.subdomain.conf :
sudo nano /srv/docker/swag/config/nginx/proxy-confs/tinyauth.subdomain.conf
Collez la configuration suivante :
## Version 2023/12/19
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name tinyauth.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app tinyauth;
set $upstream_port 3000;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}
Appuyez sur Ctrl+O, puis Enter pour enregistrer, et Ctrl+X pour quitter.
Visiter votre nouveau sous-domaine
Attendez quelques minutes, puis ouvrez https://tinyauth.mondomaine.fr dans votre navigateur et connectez-vous avec l'identifiant et le mot de passe créés plus haut.
Terminé !
Protéger une application via le reverse proxy
Swag ne fournit pas de fichier d'inclusion tout prêt pour TinyAuth, nous ajouterons donc la vérification forward-auth directement dans le *.subdomain.conf de l'application. Nous prendrons Dockge en exemple.
Ouvrir le fichier subdomain.conf de l'application
sudo nano /srv/docker/swag/config/nginx/proxy-confs/dockge.subdomain.conf
Ajouter la vérification forward-auth
Ajoutez un bloc location /tinyauth interne, et référencez-le depuis le bloc location / de l'application avec auth_request :
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name dockge.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location /tinyauth {
internal;
proxy_pass http://tinyauth:3000/api/auth/nginx;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
}
location @tinyauth_login {
return 302 https://tinyauth.mondomaine.fr/login?redirect_uri=$scheme://$http_host$request_uri;
}
location / {
auth_request /tinyauth;
error_page 401 = @tinyauth_login;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app dockge;
set $upstream_port 5001;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}
location /tinyauth s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (tinyauth ici). Cela devrait déjà être en place depuis l'exposition de TinyAuth. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.Appuyez sur Ctrl+O, puis Enter pour enregistrer, et Ctrl+X pour quitter.
Terminé !
Et voilà ! Visiter https://dockge.mondomaine.fr redirige désormais d'abord vers TinyAuth. Répétez ce motif location /tinyauth / auth_request dans le *.subdomain.conf de n'importe quelle autre application pour la protéger de la même façon.
Laisser certains chemins publics
Il arrive qu'on veuille verrouiller l'essentiel d'une application derrière TinyAuth, mais laisser une poignée de chemins ouverts, par exemple une page de statut publique, ou les endpoints d'API sur lesquels une application mobile s'appuie. Contrairement à Authentik, TinyAuth n'a pas de réglage intégré de « chemins authentifiés » pour ça : c'est un simple problème nginx, et il se résout avec le système de correspondance de location de nginx.
Un bloc location en expression régulière est toujours prioritaire sur le bloc location / simple, quel que soit celui qui apparaît en premier dans le fichier. Tout chemin correspondant à une location en regex que vous définissez exécute donc son propre proxy_pass, sans jamais atteindre la ligne auth_request /tinyauth; du location /.
Par exemple, pour laisser ouverte la page de statut publique d'Uptime-Kuma et ses ressources tout en protégeant le reste :
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name stats.*;
include /config/nginx/ssl.conf;
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app uptime-kuma;
set $upstream_port 3001;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location /tinyauth {
internal;
proxy_pass http://tinyauth:3000/api/auth/nginx;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
}
location @tinyauth_login {
return 302 https://tinyauth.mondomaine.fr/login?redirect_uri=$scheme://$http_host$request_uri;
}
location / {
auth_request /tinyauth;
error_page 401 = @tinyauth_login;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app uptime-kuma;
set $upstream_port 3001;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}
Cloudflare Zero Trust
Utiliser les tunnels Cloudflare et Zero Trust pour exposer des services sans ouvrir de ports, configurer SWAG et gérer plusieurs tunnels.
Pocket ID
Installer Pocket ID, un fournisseur OIDC auto-hébergé et léger qui permet de se connecter à vos autres applications avec une passkey plutôt qu'un mot de passe.