Cos'è un dominio personalizzato per l'autenticazione e perché sono importanti più domini
Scopri come i domini personalizzati per l'autenticazione e i domini multipli migliorano la conversione, la sicurezza e il branding; e come Logto ti aiuta a gestirli senza mal di testa legati al DNS.
RanProduct & Design
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
Se hai mai lanciato un prodotto un po' troppo in fretta, questa storia ti suonerà familiare.
La tua app vive felice su example.com. Il marketing sta facendo campagne, gli utenti si registrano, tutto sembra perfetto. Poi un nuovo utente clicca su Accedi.
Invece di un URL familiare come auth.example.com, il browser si sposta su qualcosa che sembra un ambiente di test: my-tenant-123.app.logto
Tecnicamente, non c'è niente che non vada. La pagina è sicura. Il login funziona comunque.
Ma la prima reazione dell’utente è:
“Aspetta, dove sono finito?”
Quel secondo di dubbio è il punto in cui avvengono gli abbandoni.
Dal punto di vista della conversione, login e registrazione sono il collo di bottiglia del tuo funnel. Qualsiasi momento extra di “Cos’è questo dominio?” crea attrito.
Dal punto di vista della sicurezza, agli utenti viene detto da anni “controlla l'URL”. Se il dominio del login non corrisponde al tuo brand, sembra più phishing che produzione.
C’è un motivo per cui quasi tutte le grandi aziende usano qualcosa come:
login.company.com
auth.company.com
accounts.company.com
Non lo fanno per divertimento. Lo fanno perché il dominio di accesso fa parte dell’esperienza del prodotto.
In questo articolo vedremo:
Cos'è realmente un dominio personalizzato per l'autenticazione
Quando un dominio di login è sufficiente — e quando dovresti pianificare per più domini
Gli errori più comuni con i domini di login (e come evitare l’inferno del “redirect URI non corrisponde”)
Come il supporto ai domini personalizzati di Logto ti aiuta a fare tutto ciò senza diventare un ingegnere DNS a tempo pieno
Cos'è un dominio personalizzato per l'autenticazione?#
Teniamolo semplice.
Ogni tenant Logto viene fornito con un dominio predefinito: {{tenant-id}}.app.logto. Quindi il momento che prima portava gli utenti a: https://my-tenant-123.app.logto/sign-in.
Un dominio personalizzato per l'autenticazione sostituisce quell’URL visibile con uno che possiedi — tipo auth.example.com. Ora mantiene gli utenti sul tuo brand: https://auth.example.com/sign-in.
Stesso servizio di autenticazione sotto il cofano. Impressione iniziale molto diversa.
Con Logto, i domini personalizzati sono progettati per funzionare come sottodomini, tipo:
auth.example.com
auth.us.example.com
Praticamente, è quello che vuoi comunque per l'autenticazione:
I domini root sono solitamente riservati per il sito principale (example.com).
L'“apice della zona” DNS non può usare un CNAME, e il login ospitato di Logto richiede un CNAME verso domains.logto.app per l’instradamento del traffico.
Logto gestisce i certificati tramite Cloudflare. Per terminare TLS su un dominio root dovremmo controllare tutta quella zona (inclusi i tuoi A, MX, TXT, ecc.), il che non è realizzabile per un SaaS multi-tenant.
I record apex-flattening (ALIAS/ANAME) risolvono comunque su IP che non possediamo, quindi non possono supportare i nostri certificati gestiti. In breve, il login ospitato deve vivere su un sottodominio. Punta quel sottodominio a Logto con un CNAME e ci occuperemo di verifica, SSL e uptime—il tuo dominio apex resta libero per servire il resto del sito.
Perché non è “basta aggiungere un CNAME ed è fatta”#
Un malinteso molto comune:
“Aggiungerò un CNAME al mio DNS e ho finito, giusto?”
Sfortunatamente, no.
Cambiare il dominio visibile del login è solo una parte della storia. Nel momento in cui introduci un dominio auth personalizzato, stai toccando:
URL della pagina di login e registrazione
Gli utenti ora visitano https://auth.example.com/... per le pagine ospitate.
OIDC / OAuth redirect URIs
Le tue app e i connettori devono usare lo stesso dominio nei redirect/callback URIs, altrimenti riceverai errori tipo redirect_uri_mismatch.
Social login & SSO aziendale (IdP)
Google, GitHub, Azure AD, Okta, ecc., validano tutti i redirect URIs o gli ACS URLs che includono il dominio.
Passkey (WebAuthn)
Le passkey sono legate al dominio esatto in cui sono state registrate. Cambia il dominio, e quelle passkey non funzioneranno più.
Configurazione SDK
I tuoi SDK Logto usano un endpoint che punta al dominio del tenant. Se l’endpoint usa il dominio sbagliato, la tua app e il livello identità saranno fuori sync.
Quindi, c’è il DNS coinvolto? Assolutamente sì.
Ma se pensi solo in termini di “Ho aggiunto un CNAME quindi ho finito”, quasi sicuramente romperai qualcos'altro.
Un rapido modello mentale: come il dominio di login scorre attraverso lo stack#
Immagina un diagramma dove il browser dell’utente parte da:
Barra degli indirizzi del browser
L’utente clicca su Accedi su https://example.com.
Viene reindirizzato su https://auth.example.com/sign-in.
Server di autorizzazione & discovery document
La tua app usa l’endpoint di configurazione OpenID a: https://auth.example.com/oidc/.well-known/openid-configuration
Questo dice alla tua app dove inviare le richieste di autenticazione e dove aspettarsi i token.
Redirect URIs (callback OIDC/OAuth)
Dopo che l’utente ha effettuato il login, Logto reindirizza di nuovo la tua app su qualcosa tipo: https://app.example.com/callback
L’IdP e la tua applicazione devono concordare questi URL.
Salti social login / SSO aziendale
Da auth.example.com, l’utente potrebbe saltare a Google, Microsoft Entra ID, Okta, ecc.
Anche quei provider convalidano e vedono i redirect URI che includono il tuo dominio auth personalizzato.
Email e magic link / link per il reset della password
I link nelle email dovrebbero puntare sempre coerentemente al tuo dominio personalizzato per non confondere gli utenti.
A ciascuno di questi passaggi, il dominio conta. Quando introduci un dominio di login personalizzato, vuoi che quel dominio scorra attraverso tutta la catena in modo coerente.
Ecco perché una strategia di dominio personalizzato ben studiata riguarda meno i trucchi DNS e più un design dell’identità coerente.
Per molti team, un solo dominio personalizzato tipo auth.example.com va benissimo. Ma man mano che il tuo prodotto, la geografia e la base clienti crescono, incontrerai rapidamente dei limiti se non pianifichi in anticipo.
Ecco come vari team normalmente mappano domini alle loro esperienze di autenticazione:
Scenario
Esempi di domini
Perché è utile
Un solo login brandizzato
auth.example.com, account.example.com
Mantiene la barra degli indirizzi coerente con il brand mentre il dominio predefinito {{tenant-id}}.app.logto resta disponibile per i test.
Dai a ogni brand un’esperienza di login coerente senza frammentare lo stack identità.
Più TLD
auth.foo.com, auth.foo.co.uk, auth.foo.dev
Supporta siti nazionali o domini speciali senza replicare la configurazione per ogni regione.
Dato dall'infrastruttura
auth.edge.example.com, auth.api.example.com
Allineati alle regole di routing CDN oppure edge, mentre Logto resta il backend identity dietro quegli host.
Come Logto rende facile usare domini personalizzati#
Ecco cosa ti offre Logto out of the box, senza trasformarti in un esperto DNS o PKI.
Un tenant, molti domini. Mappa regioni, ambienti, clienti o brand ai loro domini di login senza dover clonare i tenant. Ci sono limiti al piano, ma la promessa è: un backbone identità, tanti punti di accesso.
Il predefinito resta attivo. Aggiungere auth.example.com non disabilità {{tenant-id}}.app.logto. Usa il default per strumenti interni o rollout graduali mentre gli utenti in produzione usano il dominio brandizzato.
I connettori si adattano automaticamente. Gli SDK puntano all’endpoint giusto, mentre i connettori social e SSO elencano ogni redirect URI valido per ogni dominio—niente giochi manuali con gli URL.
SSL completamente automatico. Dopo che hai aggiunto il CNAME, Logto verifica il DNS, fornisce i certificati e si occupa dei rinnovi. Nessuna gestione chiavi, nessuna scadenza a sorpresa.
Puoi iniziare subito a sperimentare più domini personalizzati:
Vai su Console > Impostazioni > Domini. Aggiungi un secondo dominio personalizzato per una nuova regione che stai lanciando, o per un importante cliente enterprise che vuole il suo login brandizzato, ecc.
Aggiorna l’endpoint dell’SDK dove serve.
Aggiungi ai tuoi identity provider gli URI di redirect e ACS sensibili al dominio che Logto fornisce nei connettori Social o SSO.
È un modo facile per migliorare il login e testare l’impatto sulla fiducia e conversione degli utenti.
Vai su Console > Impostazioni > Domini. Usa il pacchetto gratuito di domini personalizzati per impostare auth.example.com come dominio pubblico di login già dal primo giorno.
Tieni a portata di mano il dominio predefinito {{tenant-id}}.app.logto per usi interni o test.
Eviterai totalmente il problema del login “sembra in staging” e in futuro non dovrai far migrare i domini nel bel mezzo della crescita.
Vuoi i dettagli passo dopo passo, inclusi i record DNS e i problemi più comuni?
Guarda la guida completa nei nostri docs: Domini personalizzati per Logto Cloud.
