Skip to main content

ADR-003 — Authentification single-user via variables d'environnement

Date : 2026-04-16 · Statut : Accepté · Décideurs : Clement Molotkoff

Contexte​

Patrimo est un intranet strictement personnel : un seul utilisateur (l'auteur) accède à l'application. Le domaine est servi en on-premise via Coolify.

La question : où stocker les credentials, et comment gérer la session ?

Options considérées​

Option A — Table User en base​

Pour

  • Solution standard, extensible multi-users
  • Intégration native NextAuth via @auth/prisma-adapter

Contre

  • Migration Prisma pour ajouter User
  • Mécanisme d'initialisation du premier user (seed, commande admin…)
  • Surface applicative à maintenir (création, modification, suppression de compte)
  • Overkill pour 1 seul utilisateur

Option B — Variables d'environnement (retenu)​

Pour

  • ADMIN_EMAIL + ADMIN_PASSWORD → credentials en env
  • Aucune table en base, aucun modèle Prisma supplémentaire
  • Changement de mot de passe = mise à jour de l'env + redémarrage container
  • Simplicité maximale sans compromis de sécurité (JWT signé avec AUTH_SECRET)

Contre

  • Difficilement évolutif vers multi-users (migration requise)
  • Pas de « mot de passe oublié » (accepté : l'utilisateur a toujours accès à l'env Coolify)

Décision​

Credentials via variables d'environnement avec NextAuth v5 Credentials provider.

Stratégie de session : JWT (pas de table Session en base), maxAge 30 jours.

Implémentation : src/lib/auth.ts.

Procédure de changement de mot de passe​

# 1. Mettre à jour ADMIN_PASSWORD dans Coolify (ou .env en local)
# 2. Redémarrer le container de l'app
docker compose up -d app

Variables d'environnement​

VariableObligatoireDescription
AUTH_SECRETouiClé de signature JWT (openssl rand -base64 32)
AUTH_URLnonURL de base NextAuth (défaut : http://localhost:4000)
ADMIN_EMAILouiEmail de l'unique utilisateur
ADMIN_PASSWORDouiMot de passe en clair (comparaison directe en mémoire)

Conséquences​

Positives

  • Schéma Prisma allégé
  • Déploiement simplifié sur Coolify (env → app, pas de seed conditionnelle)
  • Attaques brute-force mitigées : l'app n'est pas exposée publiquement (domaine privé, Coolify)

Risques acceptés

  • Si Nordigen V2 impose plusieurs utilisateurs ou rôles → migration vers table User + NextAuth Adapter
  • Pas de rotation automatique des credentials (mitigation : accès Coolify protégé)

Révision​

Cette décision serait à remettre en question si :

  • Un second utilisateur doit accéder à l'application
  • Des rôles différenciés (admin / read-only) deviennent nécessaires
  • L'application devient exposée publiquement (auth plus robuste requise : 2FA, magic link, OIDC)