Cos'è un dominio personalizzato per l'autenticazione e perché sono importanti più domini

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.

Perché sottodomini e non domini root?#

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:

1. Barra degli indirizzi del browser

   • L’utente clicca su Accedi su https://example.com.
   • Viene reindirizzato su https://auth.example.com/sign-in.

2. 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.

3. 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.

4. 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.

5. 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.

Dominio personalizzato singolo vs multiplo#

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:

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.

Dove andare da qui#

Se sei arrivato fin qui, probabilmente rientri in uno di questi due casi.

Usi già Logto?#

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.

Nuovo su Logto?#

Se stai incominciando ora:

• Registrati su Logto e crea un tenant.
• 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.