¿Qué es un dominio personalizado de autenticación y por qué importa tener múltiples dominios?
Descubre cómo los dominios personalizados de autenticación y múltiples dominios mejoran la conversión, la seguridad y la identidad de marca; y cómo Logto te ayuda a gestionarlos sin problemas de DNS.
RanProduct & Design
Deja de perder semanas en la autenticación de usuarios
Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.
Si alguna vez lanzaste un producto demasiado rápido, esta historia te resultará familiar.
Tu aplicación vive felizmente en example.com. Marketing está ejecutando campañas, los usuarios se están registrando, todo parece impecable. Luego, un nuevo usuario hace clic en Iniciar sesión.
En vez de una URL familiar como auth.example.com, el navegador salta a algo que parece un entorno de pruebas: my-tenant-123.app.logto
Técnicamente, no hay nada mal. La página es segura. El inicio de sesión aún funciona.
Pero la primera reacción del usuario es:
“¿Espera, a dónde acabo de ir?”
Ese segundo de duda es cuando ocurren los abandonos.
Desde el punto de vista de la conversión, el inicio de sesión y el registro son la parte más estrecha del embudo. Cualquier momento extra de “¿Qué es este dominio?” añade fricción.
Desde el punto de vista de la seguridad, los usuarios llevan años escuchando “revisa la URL”. Si el dominio de inicio de sesión no coincide con tu marca, parece más phishing que producción.
Por eso, casi todas las grandes empresas utilizan una versión de:
login.company.com
auth.company.com
accounts.company.com
No lo hacen por diversión. Lo hacen porque el dominio de inicio de sesión es parte de la experiencia del producto.
En este artículo veremos:
Qué es realmente un dominio personalizado de autenticación
Cuándo un dominio de inicio de sesión es suficiente — y cuándo deberías planificar para múltiples
Los errores más comunes con los dominios de inicio de sesión (y cómo evitar el infierno de “redirect URI does not match”)
Cómo el soporte de dominios personalizados de Logto te ayuda a hacer todo esto sin convertirte en ingeniero de DNS a tiempo completo
¿Qué es un dominio personalizado de autenticación?#
Vamos a simplificarlo.
Cada tenant de Logto viene con un dominio por defecto: {{tenant-id}}.app.logto. Así que el momento que solía enviar a los usuarios a: https://my-tenant-123.app.logto/sign-in.
Un dominio personalizado de autenticación cambia esa URL visible por una que es tuya—por ejemplo, auth.example.com. Ahora mantienes a los usuarios dentro de tu marca en: https://auth.example.com/sign-in.
El mismo servicio de autenticación por detrás. Una primera impresión muy diferente.
Con Logto, los dominios personalizados están diseñados para funcionar como subdominios, tales como:
auth.example.com
auth.us.example.com
En la práctica, esto es lo que deseas para autenticación de todos modos:
Los dominios raíz suelen estar reservados para tu sitio principal (example.com).
El “zone apex” de DNS no puede usar un CNAME, y el inicio de sesión alojado de Logto requiere un CNAME a domains.logto.app para el enrutamiento del tráfico.
Logto administra certificados a través de Cloudflare. Para terminar TLS en un dominio raíz necesitaríamos controlar toda esa zona (incluidos tus registros A, MX, TXT, etc.), lo cual no es viable para un SaaS multi-tenant.
Los registros apex-flattening (ALIAS/ANAME) siguen resolviendo a IPs que no nos pertenecen, así que no pueden respaldar nuestros certificados gestionados. En resumen, el inicio de sesión alojado debe vivir en un subdominio. Apunta ese subdominio a Logto con un CNAME y nosotros nos encargamos de la verificación, SSL y tiempo en línea — tu dominio apex queda libre para servir el resto de tu sitio.
“Simplemente agrego un CNAME en mi DNS y ya terminé, ¿verdad?”
Desafortunadamente, no.
Cambiar el dominio de inicio de sesión visible es sólo una parte de la historia. En cuanto introduces un dominio personalizado para autenticación, estás tocando:
La URL de las páginas de inicio de sesión y registro
Ahora los usuarios visitan https://auth.example.com/... para las páginas alojadas.
OIDC / OAuth redirect URIs
Tus aplicaciones y conectores deben usar el mismo dominio en sus URLs de redirección/callback, o tendrás errores del tipo redirect_uri_mismatch.
Inicios de sesión sociales y SSO de empresa (IdPs)
Google, GitHub, Azure AD, Okta, etc., todos validan redirect URIs o ACS URLs incluyendo el dominio.
Passkeys (WebAuthn)
Los passkeys están atados exactamente al dominio en el que fueron registrados. Cambia el dominio, y esos passkeys dejarán de funcionar.
Configuración de SDK
Tus SDK de Logto usan un endpoint que apunta al dominio de tu tenant. Si el endpoint usa un dominio incorrecto, tu app y la capa de identidad perderán sincronía.
¿Hay DNS implicado? Absolutamente.
Pero si solo piensas en “añadí un CNAME así que ya terminé”, casi seguro romperás otra cosa.
Un modelo mental rápido: cómo fluye el dominio de inicio de sesión a través del stack#
Imagina un diagrama donde el navegador del usuario empieza en:
Barra de direcciones del navegador
El usuario hace clic en Iniciar sesión en https://example.com.
Se le redirige a https://auth.example.com/sign-in.
Servidor de autorización y discovery document
Tu app usa el endpoint de configuración OpenID en: https://auth.example.com/oidc/.well-known/openid-configuration
Esto le indica a tu app donde enviar las solicitudes de autenticación y dónde esperar los tokens.
Redirect URIs (callbacks OIDC/OAuth)
Después de iniciar sesión, Logto redirige de vuelta a tu app en algo como: https://app.example.com/callback
El IdP y tu aplicación deben estar de acuerdo en esas URLs.
Saltos de login social / SSO de empresa
Desde auth.example.com, el usuario podría saltar a Google, Microsoft Entra ID, Okta, etc.
Esos proveedores también ven y validan redirect URIs incluyendo tu dominio personalizado de autenticación.
Emails y enlaces mágicos / enlaces para restablecer la contraseña
Los enlaces en correos deben apuntar de forma coherente a tu dominio personalizado para no confundir a los usuarios.
En cada uno de estos pasos, el dominio importa. Cuando introduces un dominio de inicio de sesión personalizado, quieres que ese dominio fluya a través de toda la cadena de manera consistente.
Por eso, una buena estrategia de dominios personalizados tiene menos que ver con trucos de DNS y más con un diseño de identidad coherente.
Para muchos equipos, un solo dominio personalizado como auth.example.com está perfectamente bien. Pero a medida que tu producto, geografía y base de clientes crece, rápidamente encontrarás limitaciones si no planificas con antelación.
Así es como distintos equipos suelen mapear los dominios a sus experiencias de autenticación:
Escenario
Dominios de ejemplo
Por qué ayuda
Un login de marca
auth.example.com, account.example.com
Mantiene la barra de direcciones con tu marca mientras el dominio por defecto {{tenant-id}}.app.logto queda disponible para pruebas.
Da a cada marca una experiencia de login coherente sin fragmentar tu stack de identidad.
Múltiples TLD
auth.foo.com, auth.foo.co.uk, auth.foo.dev
Da soporte a sitios por país o dominios especiales sin replicar configuración por región.
Impulsado por infraestructura
auth.edge.example.com, auth.api.example.com
Alinea con reglas de CDN o edge routing mientras Logto sigue como backend de identidad detrás de esos hosts.
Cómo Logto facilita el uso de dominios personalizados#
Esto es lo que Logto te ofrece out of the box, sin convertirte en especialista DNS ni PKI.
Un tenant, muchos dominios. Puedes mapear regiones, entornos, clientes o marcas a sus propios hosts de inicio de sesión sin clonar tenants. Los límites de tu plan aplican, pero la promesa básica se mantiene: un solo backend de identidad, muchas puertas de entrada.
El dominio por defecto sigue activo. Añadir auth.example.com no elimina {{tenant-id}}.app.logto. Usa el dominio por defecto para herramientas internas o despliegues graduales mientras los usuarios finales usan el dominio de marca.
Los conectores se ajustan automáticamente. Los SDK apuntan al endpoint correcto, y los conectores sociales o SSO de empresa listan todos los redirect URI o ACS URL válidos por dominio—nada de hacer malabares manualmente con los URLs.
SSL automático. Tras agregar el CNAME, Logto verifica DNS, provee certificados y los mantiene renovados. Sin gestión de claves ni expiraciones inesperadas.
Puedes empezar a probar múltiples dominios personalizados ahora mismo:
Ve a Consola > Configuración > Dominios. Añade un segundo dominio personalizado para una nueva región próxima a lanzar, o para ese cliente empresarial que desea su propio login de marca, etc.
Actualiza el endpoint del SDK donde corresponda.
Agrega los redirect URIs y ACS URLs para dominio que Logto proporciona en los conectores de Social o SSO en tus proveedores de identidad.
Es una forma fácil de mejorar tu experiencia de inicio de sesión y probar el impacto en confianza y conversión de usuarios.
Ve a Consola > Configuración > Dominios. Usa la asignación gratuita de dominios personalizados para configurar auth.example.com como tu dominio público de inicio de sesión desde el primer día.
Mantén a mano el dominio por defecto {{tenant-id}}.app.logto para uso interno o pruebas.
Así evitarás por completo el problema del “esto parece staging” en la URL de inicio de sesión y tu yo del futuro no tendrá que deshacer una migración de dominios en plena etapa de crecimiento.
¿Quieres la guía paso a paso, incluyendo los registros DNS y solución de problemas?
Consulta la guía completa en nuestra documentación: Dominios personalizados para Logto Cloud.
