Ce qu'est Logto — et ce qu'il n'est pas
Logto est une plateforme d'authentification livrée comme un SDK : vous l'intégrez au code de votre application en une quinzaine de lignes, et elle prend en charge tout le cycle de vie des comptes, sur votre propre serveur. C'est différent des deux autres outils d'authentification du catalogue ServOrbit :
- Authelia ajoute MFA et authentification unique *devant* des applications existantes, par délégation, sans toucher à leur code — il protège des applications qui n'ont pas d'écran de connexion du tout.
- Authentik est un fournisseur d'identité complet, pour centraliser l'authentification unique de vos outils auto-hébergés (Grafana, Gitea, Nextcloud).
- Logto remplace un service d'authentification hébergé : vous appelez son SDK depuis votre application React, Python ou Go, et il gère comptes, sessions, connecteurs sociaux et jetons.
Si vous construisez un produit où les utilisateurs créent un compte, Logto est l'outil adapté.
Prérequis
Avant de déployer Logto 1.19+, vérifiez les points suivants sur votre VPS ServOrbit :
- RAM : au moins 2 Go (4 Go recommandés si vous attendez plus de 5 000 utilisateurs actifs). Logto s'exécute sur Node.js 20 LTS et partage la même instance que PostgreSQL 17.
- CPU : 1 vCPU suffit pour un démarrage, mais 2 vCPU évitent les latences à la connexion sous charge.
- Disque : comptez au minimum 10 Go libres : PostgreSQL alloue des journaux WAL et les sessions actives s'accumulent rapidement avec la journalisation d'audit activée par défaut.
- Docker ≥ 24.0 et Docker Compose ≥ 2.20 — préinstallés sur toutes les offres VPS ServOrbit.
- PostgreSQL 17 minimum (inclus dans l'image officielle Logto) — les versions antérieures ne supportent pas les extensions requises.
- Un nom de domaine ou sous-domaine pointé vers votre VPS et résolu publiquement : Logto inscrit ce domaine dans chaque jeton OIDC qu'il émet. Il doit être défini avant le premier démarrage et ne peut plus être modifié sans réinitialiser toutes les données utilisateur.
Comment Logto fonctionne en production
Logto démarre deux conteneurs : db (PostgreSQL 17 pour les utilisateurs, les applications, les sessions et le journal d'audit) et logto (Node.js, qui sert le point d'accès OIDC sur le port 3001 et la console d'administration sur le port 3002). Le proxy inverse nginx de votre VPS transmet le trafic HTTPS de votre domaine vers le port 3001 — c'est le point d'accès auprès duquel vos applications s'authentifient. Le port 3002 n'est lié qu'à la boucle locale et n'est joignable que par un tunnel SSH, ce qui garde l'administration de votre base d'utilisateurs hors de l'internet public.
Ce que Logto apporte dès l'installation
- Des jetons conformes OIDC/OAuth 2.0 — des JWT signés que n'importe quelle bibliothèque standard (passport.js, python-jose, go-oidc) vérifie sans code spécifique.
- Des connecteurs de connexion sociale — activez Google, GitHub, Apple, Microsoft, Discord et une trentaine d'autres fournisseurs depuis la console, en un clic ; chacun demande une déclaration OAuth de quelques minutes côté fournisseur.
- L'authentification sans mot de passe — liens magiques par courriel ou codes à usage unique par SMS (Twilio, SendGrid, Mailgun), sans maintenir un service de notification séparé.
- La double authentification — TOTP (Google Authenticator, Authy), clés matérielles WebAuthn/FIDO2 et codes de secours, imposés par politique depuis la console.
- Le contrôle d'accès par rôles — définissez rôles et permissions dans la console, recevez-les comme revendications
scopedu JWT, et appliquez-les dans votre API en une ligne d'intergiciel. - Des SDK pour plus de 20 cadres — React, Next.js, Vue, Angular, React Native, Flutter, Python, FastAPI, Go, PHP, Laravel, .NET, Java, Spring Boot et d'autres.
Déploiement Docker Compose pas à pas
Créer le répertoire et le fichier Compose
Connectez-vous en SSH à votre VPS, puis créez le répertoire de travail :
mkdir -p /opt/logto && cd /opt/logtoCréez le fichier
docker-compose.ymlavec le contenu suivant. Remplacezauth.votre-domaine.compar votre propre domaine :version: '3.9' services: db: image: postgres:17-alpine restart: unless-stopped environment: POSTGRES_DB: logto POSTGRES_USER: logto POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - logto_db:/var/lib/postgresql/data logto: image: svhd/logto:latest restart: unless-stopped depends_on: - db ports: - '127.0.0.1:3001:3001' - '127.0.0.1:3002:3002' environment: DB_URL: postgresql://logto:${DB_PASSWORD}@db:5432/logto ENDPOINT: https://auth.votre-domaine.com ADMIN_ENDPOINT: https://auth.votre-domaine.com:3002 SECRET_VAULT_KEK: ${SECRET_VAULT_KEK} volumes: logto_db:Générer les secrets et créer le fichier .env
Générez un mot de passe de base de données et une clé AES-256 solides :
DB_PASSWORD=$(openssl rand -hex 32) SECRET_VAULT_KEK=$(openssl rand -hex 32) printf "DB_PASSWORD=%s\nSECRET_VAULT_KEK=%s\n" "$DB_PASSWORD" "$SECRET_VAULT_KEK" > .env chmod 600 .envVérifiez que
.envcontient bien deux lignes non vides avant de continuer.Configurer nginx en proxy inverse
Créez le vhost
/etc/nginx/sites-available/logto:server { listen 443 ssl; server_name auth.votre-domaine.com; ssl_certificate /etc/letsencrypt/live/auth.votre-domaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/auth.votre-domaine.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3001; 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 https; } }Activez le site et rechargez nginx :
ln -s /etc/nginx/sites-available/logto /etc/nginx/sites-enabled/ nginx -t && systemctl reload nginxDémarrer la pile et vérifier
Lancez les deux conteneurs :
docker compose up -dSuivez les logs pendant 60 secondes pour confirmer que PostgreSQL est prêt et que Logto a terminé ses migrations :
docker compose logs -f --tail=50Vous devez voir la ligne
App is running at https://auth.votre-domaine.com— c'est le signal que le service est opérationnel.Vérifier le document de découverte OIDC
Depuis votre poste local, vérifiez que le point d'accès OIDC répond :
curl -s https://auth.votre-domaine.com/.well-known/openid-configuration | python3 -m json.tool | head -10La réponse doit contenir
issuer,authorization_endpointetjwks_uri. Si la commande renvoie une erreur 502, Logto n'a pas encore terminé ses migrations — attendez 30 secondes et réessayez.Configurer les sauvegardes automatiques
Ajoutez une tâche cron pour exporter la base de données quotidiennement :
crontab -e # Ajouter la ligne suivante : 0 3 * * * docker exec $(docker compose -f /opt/logto/docker-compose.yml ps -q db) pg_dump -U logto logto | gzip > /var/backups/logto_$(date +\%Y\%m\%d).sql.gzPour des sauvegardes automatisées, dédupliquées et chiffrées vers S3 ou Backblaze B2, montez le volume
logto_dbdans une instance Backrest disponible dans le catalogue ServOrbit.
Se connecter la première fois
Ouvrir le tunnel SSH vers la console d'administration
La console d'administration écoute sur le port 3002, lié à la boucle locale pour des raisons de sécurité. Depuis votre poste, ouvrez un tunnel :
ssh -L 3002:127.0.0.1:3002 root@ip-de-votre-vpsGardez ce terminal ouvert pendant toute votre session d'administration.
Créer le compte administrateur
Ouvrez
http://localhost:3002dans votre navigateur. L'assistant de première connexion s'affiche — il n'existe aucun identifiant par défaut. Saisissez une adresse courriel et un mot de passe robuste, puis cliquez sur Create account. Ces identifiants seront les vôtres pour administrer Logto ; conservez-les dans un gestionnaire de mots de passe.Explorer le tableau de bord
Après la création du compte, vous accédez au tableau de bord Logto. Depuis ici vous pouvez : consulter le journal d'audit, gérer les utilisateurs, configurer les connecteurs sociaux et créer des Applications — c'est l'entité Logto qui représente un de vos projets.
Créer votre première Application
Dans la console : Applications → Create application. Choisissez le type correspondant à votre projet (Traditional Web, Single Page App, Native, ou Machine-to-machine). Donnez-lui un nom, puis renseignez l'Redirect URI — c'est l'URL vers laquelle Logto redirige après une connexion réussie (par exemple
https://mon-app.com/api/logto/sign-in-callbackpour une application Next.js). Logto génère alors unApp IDet unApp Secretque vous utiliserez dans votre SDK.
Intégrer Logto dans une application Next.js
Installez le SDK avec npm install @logto/next, puis créez un logto.ts qui exporte un new LogtoClient({ … }) configuré avec endpoint (l'URL de votre instance Logto), appId et appSecret (relevés dans la console Logto), baseUrl (l'URL de votre application), cookieSecret et cookieSecure.
Pour protéger une route, appelez getLogtoContext({ getAccessToken: true }) importé de @logto/next/server-component : il rend isAuthenticated et les claims de l'utilisateur. Si isAuthenticated est faux, redirigez vers /api/logto/sign-in ; sinon, servez la page en vous appuyant sur les revendications reçues.
C'est toute l'intégration : une quinzaine de lignes de configuration, un import, une garde.
Activer la connexion Google
Dans la console Google Cloud, créez un identifiant client OAuth 2.0 de type application web. Renseignez l'URI de redirection autorisée https://auth.votre-domaine.com/callback/google, puis copiez l'identifiant et le secret client.
Dans la console Logto → Connecteurs → Connecteurs sociaux → Google → Activer. Collez l'identifiant et le secret, puis enregistrez. Google apparaît dès lors comme une option de connexion sur votre page Logto, sans aucune modification de code dans votre application.
Logto, Authentik, Authelia, Keycloak — lequel choisir ?
Faites défiler le tableau
| Solution | Cas d'usage principal | RAM minimale | Complexité d'intégration SDK |
|---|---|---|---|
| **Logto** | Authentification pour un produit que vous développez (inscription, JWT, connecteurs sociaux) | 2 Go | Faible — SDK officiel en 15 lignes pour React, Next.js, Python, Go, Flutter et 15+ autres |
| **Authentik** | SSO centralisé pour vos outils auto-hébergés (Grafana, Gitea, Nextcloud, Proxmox) | 2 Go | Moyenne — configuration via des *Providers* dans la console, pas de SDK applicatif |
| **Authelia** | MFA et portail de connexion *devant* des applications existantes, sans modifier leur code | 256 Mo | Nulle — délégation d'authentification par en-tête nginx, aucune intégration SDK |
| **Keycloak** | SSO d'entreprise, fédération LDAP/AD, scénarios multi-tenant avancés | 4 Go minimum | Élevée — configuration OIDC manuelle, librairies client à configurer par framework |
Pour un produit SaaS en construction, Logto est le point de départ naturel. Keycloak convient aux organisations qui ont déjà un annuaire d'entreprise à intégrer. Authelia et Authentik répondent à des besoins d'infrastructure plutôt qu'applicatifs.
Dépannage fréquent
Voici les quatre problèmes les plus courants lors d'une première installation de Logto sur VPS, et comment les résoudre.
La console d'administration est inaccessible (port 3002)
Le port 3002 est intentionnellement lié à 127.0.0.1 — il n'est pas accessible directement depuis internet. Si http://localhost:3002 ne répond pas, vérifiez d'abord que votre tunnel SSH est bien ouvert (ssh -L 3002:127.0.0.1:3002 root@<IP>). Vérifiez ensuite que le conteneur Logto tourne : docker compose ps. Si le conteneur est à l'état Exit, consultez les logs : docker compose logs logto --tail=50.
L'endpoint OIDC renvoie une erreur 502 (OIDC discovery 502)
Logto exécute ses migrations de base de données au premier démarrage — cela prend entre 30 et 90 secondes selon le VPS. Si le document de découverte /.well-known/openid-configuration renvoie 502, c'est que nginx transmet les requêtes avant que Logto ne soit prêt. Attendez 90 secondes, puis réessayez. Si l'erreur persiste, vérifiez que PostgreSQL est sain : docker compose logs db --tail=20 — cherchez la ligne database system is ready to accept connections.
Redirect URI mismatch
Logto valide strictement l'URI de redirection : si l'URI envoyée par votre application ne correspond pas exactement à celle déclarée dans la console Logto (Application → Redirect URIs), la connexion échoue avec l'erreur redirect_uri_mismatch. Vérifiez que vous avez enregistré l'URL complète, y compris le schéma (https://), le chemin exact et l'absence de barre oblique finale si votre SDK n'en envoie pas. Les URIs de développement (http://localhost:3000/…) doivent être ajoutées séparément dans la console.
Fatal: cannot connect to db
Si les logs Logto affichent Fatal: cannot connect to db, PostgreSQL n'était pas encore prêt quand Logto a tenté de s'y connecter. La déclaration depends_on de Docker Compose garantit l'ordre de démarrage des conteneurs, mais pas que PostgreSQL accepte des connexions. Relancez simplement le conteneur Logto : docker compose restart logto. Il se reconnectera dès que PostgreSQL sera prêt.
Stratégie de sauvegarde
Logto conserve tout son état dans le volume PostgreSQL logto_db. Sauvegardez-le par une tâche planifiée pg_dump, ou montez le volume dans une instance Backrest (également au catalogue ServOrbit) pour des sauvegardes automatisées, dédupliquées et chiffrées vers S3, Backblaze B2 ou SFTP. Perdre le volume logto_db, c'est perdre tous les comptes utilisateur, la configuration des applications et le journal d'audit — sauvegardez-le avant toute migration de VPS.