O que é um domínio personalizado de autenticação e por que vários domínios importam
Saiba como domínios personalizados de autenticação e múltiplos domínios melhoram conversão, segurança e branding; e como o Logto ajuda você a gerenciá-los sem dores de cabeça com DNS.
RanProduct & Design
Pare de perder semanas com autenticação de usuários
Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.
Se você já lançou um produto rápido demais, essa história vai soar familiar.
Seu app vive feliz em example.com. O marketing está rodando campanhas, usuários estão se cadastrando, tudo parece refinado. Então um novo usuário clica em Entrar.
Em vez de uma URL familiar como auth.example.com, o navegador pula para algo que parece um ambiente de testes: my-tenant-123.app.logto
Tecnicamente, não há nada de errado. A página é segura. O login ainda funciona.
Mas a primeira reação do usuário é:
“Espera, onde eu acabei de entrar?”
Esse segundo de dúvida é onde acontecem as desistências.
Do ponto de vista de conversão, o login e cadastro são a parte mais estreita do seu funil. Qualquer momento extra de "Que domínio é esse?" cria atrito.
Do ponto de vista de segurança, os usuários são instruídos há anos a "checar a URL". Se o domínio de login não bate com sua marca, parece mais phishing do que produção.
Existe um motivo para quase todas as empresas grandes usarem algo como:
login.company.com
auth.company.com
accounts.company.com
Não é só por diversão. É porque o domínio de login faz parte da experiência do produto.
Neste artigo, veremos:
O que é de fato um domínio personalizado de autenticação
Quando um domínio de login é suficiente — e quando você deve planejar para vários
Os erros mais comuns com domínios de login (e como evitar o inferno do “redirect URI does not match”)
Como o suporte a domínios personalizados do Logto te ajuda a fazer tudo isso sem precisar virar um engenheiro de DNS em tempo integral
O que é um domínio personalizado de autenticação?#
Vamos simplificar.
Todo tenant Logto vem com um domínio padrão: {{tenant-id}}.app.logto. Ou seja, aquele momento que mandava usuários para: https://my-tenant-123.app.logto/sign-in.
Um domínio personalizado de autenticação troca essa URL visível por uma que você controla—algo como auth.example.com. Agora mantém os usuários dentro da marca em: https://auth.example.com/sign-in.
O mesmo serviço de autenticação por trás dos panos. Mas uma primeira impressão bem diferente.
No Logto, domínios personalizados funcionam como subdomínios, como:
auth.example.com
auth.us.example.com
Na prática, é exatamente isso que você quer para auth:
Domínios raiz geralmente ficam para seu site principal (example.com).
O “zone apex” do DNS não pode usar CNAME, e o login hospedado do Logto precisa de um CNAME para domains.logto.app para direcionamento de tráfego.
O Logto gerencia certificados via Cloudflare. Para encerrar TLS num domínio raiz teríamos que controlar toda a zona (incluindo seus registros A, MX, TXT, etc.), o que não é viável para um SaaS multi-tenant.
Registros apex-flattening (ALIAS/ANAME) ainda resolvem para IPs que não controlamos, então não podem ser usados em nossos certificados gerenciados. Ou seja, o login hospedado precisa estar num subdomínio. Aponte esse subdomínio para o Logto via CNAME e nós cuidamos da verificação, SSL e uptime—seu domínio raiz fica livre para servir o resto do seu site.
“Vou só colocar um CNAME no meu DNS e terminei, certo?”
Infelizmente, não.
Mudar o domínio visível do login é só parte da história. Ao adicionar um domínio personalizado de autenticação, você está mexendo em:
URL da página de login e cadastro
Usuários agora visitam https://auth.example.com/... para as páginas hospedadas.
URIs de redirecionamento OIDC / OAuth
Seus apps e conectores precisam usar o mesmo domínio nas URLs de redirecionamento/callback, senão você verá erros do tipo redirect_uri_mismatch.
Logins sociais & SSO empresarial (IdPs)
Google, GitHub, Azure AD, Okta, etc., todos validam as URIs de redirecionamento ou URLs ACS incluindo o domínio.
Passkeys (WebAuthn)
Passkeys estão vinculados ao domínio exato de registro. Troque o domínio e aqueles passkeys não funcionarão mais.
Configuração do SDK
Seus SDKs Logto usam um endpoint que aponta para o domínio do seu tenant. Se o endpoint usar o domínio errado, seu app e camada de identidade saem de sincronia.
Então, existe DNS envolvido? Com certeza.
Mas se você só pensar “adicionei um CNAME e acabou”, quase certo que vai quebrar outra coisa.
Um modelo mental rápido: como o domínio de login flui pela stack#
Imagine um diagrama onde o navegador do usuário começa em:
Barra de endereço do navegador
O usuário clica em Entrar em https://example.com.
Ele é redirecionado para https://auth.example.com/sign-in.
Servidor de autorização & documento de descoberta
Seu app utiliza o endpoint de configuração OpenID em: https://auth.example.com/oidc/.well-known/openid-configuration
Isso indica onde enviar as requisições de autenticação e esperar os tokens.
URIs de redirecionamento (OIDC/OAuth callbacks)
Após o login, o Logto redireciona de volta para seu app em algo como: https://app.example.com/callback
O IdP e seu app precisam concordar nessas URLs.
Saltos de login social / SSO empresarial
De auth.example.com, o usuário pode ir para Google, Microsoft Entra ID, Okta, etc.
Esses provedores também validam URIs de redirecionamento que incluem seu domínio personalizado de auth.
E-mails e links mágicos / links de reset de senha
Links em e-mails devem apontar de forma consistente para o domínio personalizado para não confundir usuários.
Em cada um desses passos, o domínio importa. Ao adicionar um domínio personalizado de login, você quer que ele flua por toda a cadeia de maneira consistente.
Por isso, uma boa estratégia de domínios personalizados é menos sobre “truques” de DNS e mais sobre um design de identidade coerente.
Para muitas equipes, um único domínio personalizado como auth.example.com é suficiente. Mas conforme seu produto, geografia e base de clientes evoluem, logo aparecem limitações se não houver planejamento.
Veja como times diferentes geralmente mapeiam domínios para suas experiências de autenticação:
Cenário
Exemplos de domínios
Por que ajuda
Um login com branding
auth.example.com, account.example.com
Mantém o endereço na marca enquanto o domínio padrão {{tenant-id}}.app.logto fica disponível para testes.
Veja o que o Logto oferece, sem precisar virar especialista em DNS ou PKI:
Um tenant, vários domínios. Mapeie regiões, ambientes, clientes ou marcas para seus próprios hosts de login sem clonar tenants. Existem limites do plano, mas a promessa é: um backbone de identidade, várias portas de entrada.
O padrão continua ativo. Adicionar auth.example.com não elimina {{tenant-id}}.app.logto. Use o padrão para ferramentas internas ou rollouts graduais, enquanto usuários finais usam o domínio de marca.
Conectores se adaptam. SDKs apontam para o endpoint correto, enquanto conectores sociais e SSO listam todas URIs de redirecionamento ou ACS válidas para cada domínio — sem precisar trocar URLs manualmente.
SSL automático. Depois de adicionar o CNAME, o Logto verifica o DNS, provisiona certificados e mantém tudo renovado. Sem gestão de chaves, sem expirações surpresa.
Você pode testar múltiplos domínios personalizados imediatamente:
Acesse Console > Configurações > Domínios. Adicione um segundo domínio personalizado para uma nova região que vai lançar, ou para um cliente corporativo que quer login próprio, etc.
Atualize o endpoint do SDK onde necessário.
Adicione as URIs de redirecionamento e URLs ACS específicas do domínio que o Logto fornece nos conectores Social ou SSO aos seus provedores de identidade.
É um jeito fácil de melhorar a experiência de login e testar o efeito na confiança/conversão dos usuários.
Vá em Console > Configurações > Domínios. Use a cota grátis de domínios personalizados para configurar auth.example.com como domínio público de login desde o dia um.
Mantenha o domínio padrão {{tenant-id}}.app.logto disponível para uso interno ou testes.
Assim, você evita o problema de login "isso parece staging" e não precisa corrigir migração de domínio no futuro, quando o produto já está crescendo.
Quer detalhes do passo a passo de setup, incluindo registros DNS e troubleshooting?
Confira o guia completo na nossa documentação: Domínios personalizados para Logto Cloud.
