Qu'est-ce qu'un domaine personnalisé d'authentification et pourquoi plusieurs domaines sont importants
Découvrez comment les domaines personnalisés d'authentification et l'utilisation de plusieurs domaines améliorent la conversion, la sécurité et l'image de marque ; et comment Logto vous aide à les gérer sans prise de tête avec le DNS.
RanProduct & Design
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Si tu as déjà lancé un produit un peu trop vite, cette histoire te paraîtra familière.
Ton application vit paisiblement sur example.com. Le marketing mène ses campagnes, les utilisateurs s'inscrivent, tout semble parfait. Puis un nouvel utilisateur clique sur Connexion.
Au lieu d'une URL familière comme auth.example.com, le navigateur saute vers quelque chose qui ressemble à un environnement de test : my-tenant-123.app.logto
Techniquement, tout va bien. La page est sécurisée. La connexion fonctionne encore.
Mais la première réaction de l'utilisateur est :
« Attends, où suis-je passé ? »
C'est à ce moment de doute d'une seconde que les abandons se produisent.
Du point de vue de la conversion, l'inscription et la connexion sont l'étape la plus étroite de ton tunnel. Tout instant de « C'est quoi ce domaine ? » crée une friction.
Du point de vue de la sécurité, les utilisateurs entendent depuis des années qu'il « faut vérifier l'URL ». Si le domaine de connexion ne correspond pas à ta marque, cela ressemble plus à du phishing qu'à de la production.
Ce n'est pas pour rien que presque toutes les grandes entreprises utilisent une version de :
login.company.com
auth.company.com
accounts.company.com
Elles ne font pas ça pour le plaisir. Elles le font parce que le domaine de connexion fait partie intégrante de l'expérience produit.
Dans cet article, nous verrons :
Ce qu'est réellement un domaine personnalisé d'authentification
Quand un seul domaine de connexion suffit — et quand il vaut mieux prévoir plusieurs
Les erreurs les plus fréquentes avec les domaines de connexion (et comment éviter l'enfer du « redirect URI does not match »)
Comment la gestion des domaines personnalisés par Logto vous permet d'assurer tout ça sans devenir ingénieur DNS à temps plein
Chaque tenant Logto dispose d'un domaine par défaut : {{tenant-id}}.app.logto. Ce qui envoie donc les utilisateurs vers : https://my-tenant-123.app.logto/sign-in.
Un domaine personnalisé d'authentification remplace cette URL visible par celle qui t'appartient — par exemple auth.example.com. Cela garde tes utilisateurs dans l'univers de ta marque à : https://auth.example.com/sign-in.
Même service d'authentification sous le capot. Première impression totalement différente.
Pourquoi des sous-domaines, pas des domaines racines ?#
Avec Logto, les domaines personnalisés sont conçus pour fonctionner comme sous-domaines, tels que :
auth.example.com
auth.us.example.com
Concrètement, c'est ce que tu veux pour l'auth :
Les domaines racines sont généralement réservés à ton site principal (example.com).
L'apex DNS ne peut pas utiliser de CNAME, et la page de connexion hébergée de Logto nécessite justement un CNAME vers domains.logto.app pour router le trafic.
Logto gère les certificats via Cloudflare. Pour terminer TLS sur un domaine racine, il faudrait contrôler toute la zone (y compris tes A, MX, TXT, etc.), ce qui est irréaliste pour une solution SaaS multi-tenant.
Les enregistrements apex-flattening (ALIAS/ANAME) se résolvent tout de même sur des IPs qui ne nous appartiennent pas, impossible donc de les couvrir par nos certificats managés. En résumé, la page de connexion hébergée doit être sur un sous-domaine. Pointez ce sous-domaine vers Logto avec un CNAME et nous nous occupons de la vérification, du SSL, et de la disponibilité — votre domaine apex reste libre pour servir le reste de votre site.
Pourquoi ce n'est pas « il suffit d'ajouter un CNAME et c'est tout »#
Une idée répandue mais fausse :
« Il me suffit d'ajouter un CNAME dans mon DNS et c'est bon, non ? »
Malheureusement, non.
Changer le domaine visible de connexion n'est qu'une partie de l'histoire. Dès que tu ajoutes un domaine d'auth personnalisé, tu impactes :
L'URL de la page de connexion et d'inscription
Les utilisateurs accèdent désormais à https://auth.example.com/... pour les pages hébergées.
Les redirect URIs OIDC / OAuth
Tes applications et connecteurs doivent utiliser le même domaine dans leurs URL de redirection/callback, sinon tu auras des erreurs redirect_uri_mismatch.
Logins sociaux & SSO d'entreprise
Google, GitHub, Azure AD, Okta, etc., vérifient les redirect URIs ou les ACS URLs, domaine compris.
Passkeys (WebAuthn)
Les passkeys sont attachées au domaine exact où elles ont été créées. Change de domaine et elles ne fonctionneront plus.
La configuration du SDK
Tes SDK Logto utilisent un endpoint pointant vers le domaine de ton tenant. Si cet endpoint est incorrect, ton appli et la couche identité ne sont plus synchronisées.
Donc, le DNS joue-t-il un rôle ? Oui, absolument.
Mais si tu te limites à penser « j'ai ajouté un CNAME donc j'ai fini », tu casseras presque à coup sûr autre chose.
Un modèle mental rapide : comment le domaine de connexion circule dans la stack#
Imagine un schéma où le navigateur de l'utilisateur part de :
La barre d'adresse du navigateur
L'utilisateur clique sur Connexion sur https://example.com.
Il est redirigé vers https://auth.example.com/sign-in.
Serveur d'autorisation & discovery document
Ton appli utilise le endpoint OpenID configuration à : https://auth.example.com/oidc/.well-known/openid-configuration
Cela indique à l'appli où envoyer les requêtes d'auth et où récupérer les tokens.
Redirect URIs (callBacks OIDC/OAuth)
Après connexion, Logto redirige vers ton appli, par exemple : https://app.example.com/callback
L'IdP et ton application doivent être tous deux alignés sur ces URLs.
Sauts login social / SSO d'entreprise
Depuis auth.example.com, l'utilisateur va peut-être sauter chez Google, Microsoft Entra ID, Okta, etc.
Ces fournisseurs vérifient également les redirect URIs comportant ton domaine d'auth personnalisé.
Emails, liens magiques, liens de réinitialisation de mot de passe
Les liens contenus dans les emails doivent pointer de façon cohérente vers ton domaine personnalisé pour ne pas troubler l'utilisateur.
À chacune de ces étapes, le domaine compte. En mettant en place un domaine d'auth sur mesure, tu veux qu'il circule à travers toute ta chaîne de manière cohérente.
C'est pourquoi une stratégie de domaine d'auth bien pensée ne repose pas sur des astuces DNS mais sur une conception identitaire cohérente.
Pour beaucoup d'équipes, un seul domaine comme auth.example.com suffit. Mais au fur et à mesure que ton produit, ta géographie, et ta base clients évoluent, tu atteindras vite des limitations si tu n'anticipes pas.
Voici comment différentes équipes associent typiquement les domaines à leur expérience d'authentification :
Cas de figure
Exemples de domaines
Intérêt
Connexion unique avec marque
auth.example.com, account.example.com
L'adresse reste aux couleurs de la marque tandis que le domaine par défaut {{tenant-id}}.app.logto reste dispo pour les tests.
Donner à chaque marque une expérience de connexion cohérente sans fragmenter ta stack d'identité.
Plusieurs TLD
auth.foo.com, auth.foo.co.uk, auth.foo.dev
Prendre en charge sites pays ou domaines spéciaux sans répliquer la config pour chaque région.
Routing infrastructure
auth.edge.example.com, auth.api.example.com
S'aligner sur les règles CDN ou edge routing tandis que Logto reste le backend identité commun.
Comment Logto simplifie les domaines personnalisés#
Logto te fournit tout ça, sans que tu deviennes un expert DNS ou PKI :
Un tenant, plusieurs domaines. Assigne régions, environnements, clients ou marques à leurs propres hôtes de connexion sans devoir cloner les tenants. Des limites selon le plan peuvent s'appliquer, mais la promesse reste : une seule colonne vertébrale identité, de nombreux points d'entrée.
Le domaine par défaut reste accessible. Ajouter auth.example.com ne désactive pas {{tenant-id}}.app.logto. Utilise le domaine par défaut pour les outils internes ou des déploiements progressifs pendant que tes utilisateurs naviguent sur le domaine de marque.
Connecteurs auto-adaptatifs. Les SDK pointent vers le bon endpoint, tandis que les connecteurs sociaux et SSO listent chaque redirect URI ou ACS URL valide pour chaque domaine — zéro gestion manuelle d'URL à jongler.
SSL automatisé. Une fois le CNAME ajouté, Logto vérifie le DNS, provisionne les certificats et les renouvelle en continu. Pas de gestion de clés, pas de surprises à l'expiration.
Tu peux tester sans attendre la gestion multi-domaines :
Va dans Console > Paramètres > Domaines. Ajoute un second domaine personnalisé pour une nouvelle région à lancer ou un client entreprise qui veut son propre login de marque, etc.
Mets à jour le champ endpoint du SDK si besoin.
Ajoute les redirect URIs et ACS URLs spécifiques selon chaque domaine fournis par Logto dans tes fournisseurs d'identité sociaux ou SSO.
C'est un moyen simple d'améliorer ton expérience de connexion et d'analyser l'impact sur la confiance et la conversion utilisateur.
Va dans Console > Paramètres > Domaines. Utilise l'allocation gratuite de domaines personnalisés pour déclarer dès le premier jour auth.example.com comme domaine de connexion public.
Garde le domaine par défaut {{tenant-id}}.app.logto sous la main pour tes usages internes ou tests.
Tu éviteras totalement le problème de l'URL de connexion « on dirait la préproduction » et tu n'auras pas à gérer plus tard une migration de domaine délicate quand ta croissance aura commencé.
Tu veux le tutoriel détaillé, les enregistrements DNS à créer, ou de l'aide sur le dépannage ?
Retrouve le guide complet dans notre documentation : Domaines personnalisés pour Logto Cloud.
