O que é um domínio personalizado de autenticação e porque interessa ter múltiplos domínios
Descobre como os domínios personalizados de autenticação e múltiplos domínios melhoram a conversão, a segurança e a imagem da marca; e como o Logto te ajuda a geri-los sem dores de cabeça com DNS.
RanProduct & Design
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
Se alguma vez lançaste um produto demasiado depressa, esta história vai soar-te familiar.
A tua app vive alegremente em example.com. O marketing está a correr campanhas, os utilizadores estão a registar-se, tudo parece bem polido. Depois, um novo utilizador clica em Iniciar sessão.
Em vez de um URL familiar como auth.example.com, o browser salta para algo que parece um ambiente de testes: my-tenant-123.app.logto
Tecnicamente, nada está errado. A página é segura. O login continua a funcionar.
Mas a primeira reação do utilizador é:
“Espera, para onde é que eu acabei de ir?”
Esse segundo de dúvida é onde acontecem as desistências.
Do ponto de vista da conversão, o login e o registo são o ponto mais estreito do teu funil. Qualquer momento de “Que domínio é este?” cria fricção.
Do ponto de vista da segurança, os utilizadores foram avisados durante anos para “verificar o URL”. Se o domínio de login não corresponder à tua marca, parece mais phishing do que produção.
Há uma razão para quase todas as grandes empresas usarem variantes como:
login.empresa.com
auth.empresa.com
accounts.empresa.com
Não o fazem por diversão. Fazem-no porque o domínio de autenticação faz parte da experiência do produto.
Neste artigo, vamos ver:
O que é realmente um domínio personalizado de autenticação
Quando um domínio de login chega — e quando deves preparar-te para vários
Os erros mais comuns com domínios de login (e como evitar a confusão de “redirect URI does not match”)
Como o suporte de domínios personalizados do Logto te permite fazer tudo isto sem te tornares um engenheiro DNS a tempo inteiro
O que é um domínio personalizado de autenticação?#
Vamos simplificar.
Cada tenant Logto é lançado com um domínio por defeito: {{tenant-id}}.app.logto. Ou seja, o momento em que encaminhava os utilizadores para: https://my-tenant-123.app.logto/sign-in.
Um domínio personalizado de autenticação troca esse URL visível por um que te pertence—por exemplo, auth.example.com. Agora, manténs os utilizadores dentro da marca em: https://auth.example.com/sign-in.
O mesmo serviço de autenticação por baixo. Primeira impressão muito diferente.
No Logto, os domínios personalizados funcionam como subdomínios, como por exemplo:
auth.example.com
auth.us.example.com
Na prática, é isto que queres para autenticação:
Os domínios raiz costumam estar reservados para o teu site principal (example.com).
O "apex" da zona DNS não pode usar um CNAME, e o login hospedado do Logto requer um CNAME para domains.logto.app para o encaminhamento de tráfego.
O Logto gere certificados através da Cloudflare. Para terminar TLS num domínio raiz teríamos de controlar toda a zona (incluindo os teus A, MX, TXT, etc.), o que não é viável para SaaS multi-inquilino.
Os registos apex-flattening (ALIAS/ANAME) continuam a resolver para IPs que não controlamos, por isso não podem suportar os nossos certificados geridos. Resumindo, o login hospedado tem de viver num subdomínio. Aponta esse subdomínio para o Logto com um CNAME e nós tratamos da verificação, SSL e uptime—o teu domínio apex fica livre para servir o resto do teu site.
Porque não basta só "adicionar um CNAME" e já está#
Uma ideia errada muito comum:
“Adiciono um CNAME ao meu DNS e fico despachado, certo?”
Infelizmente, não.
Mudar o domínio de login visível é só uma parte da história. No momento em que introduces um domínio personalizado de autenticação, mexes também em:
O URL de login e registo
Os utilizadores agora visitam https://auth.example.com/... para as páginas hospedadas.
Redirecionamentos OIDC / OAuth (redirect URIs)
As tuas apps e conectores têm de usar o mesmo domínio nos seus URLs de redireção/callback, ou vais receber erros do género redirect_uri_mismatch.
Login social & SSO empresarial (IdPs)
Google, GitHub, Azure AD, Okta, etc., validam as redirect URIs ou ACS URLs incluindo o domínio.
Passkeys (WebAuthn)
Passkeys estão associadas ao domínio exato onde foram registadas. Se mudares o domínio, essas passkeys deixam de funcionar.
Configuração dos SDKs
Os SDKs Logto usam um endpoint que aponta para o domínio do teu tenant. Se o endpoint usa o domínio errado, a tua app e a camada de identidade ficam desencontradas.
Portanto há DNS? Claro que sim.
Mas se só pensares em “Adicionei um CNAME e já está”, quase de certeza que vais partir outra coisa qualquer.
Um modelo rápido: como o domínio de login percorre a stack#
Imagina um diagrama onde o browser do utilizador começa em:
Barra de endereço do browser
O utilizador clica em Iniciar sessão em https://example.com.
É redirecionado para https://auth.example.com/sign-in.
Servidor de autorização & documento de descoberta
A tua app usa o endpoint de configuração OpenID em: https://auth.example.com/oidc/.well-known/openid-configuration
Isto diz à app para onde enviar os pedidos de autenticação e onde esperar os tokens.
Redirect URIs (callbacks OIDC/OAuth)
Depois do login, o Logto redireciona de volta para a tua app em algo como: https://app.example.com/callback
O IdP e a tua aplicação precisam de concordar nos mesmos URLs.
Saltos de login social / SSO empresarial
A partir de auth.example.com, o utilizador pode saltar para Google, Microsoft Entra ID, Okta, etc.
Esses fornecedores também vêem e validam as redirect URIs que incluem o domínio personalizado.
Emails e magic links / links de redefinição de password
Os links nos emails devem apontar sempre para o teu domínio personalizado, para não confundir os utilizadores.
Em cada um destes passos, o domínio conta. Quando introduces um domínio personalizado de login, queres que ele percorra toda a cadeia de forma consistente.
Por isso, uma boa estratégia de domínios personalizados vale menos pelos truques DNS e mais por um design coerente da identidade.
Para muitas equipas, um único domínio personalizado como auth.example.com chega perfeitamente. Mas, à medida que o teu produto, geografia e base de clientes evoluem, rapidamente vais encontrar limitações se não antecipares o futuro.
Eis como equipas diferentes normalmente mapeiam domínios para a sua experiência de autenticação:
Cenário
Exemplos de domínios
Porquê que isso ajuda
Um login com imagem de marca
auth.example.com, account.example.com
Mantém o endereço "on-brand" enquanto o domínio por defeito {{tenant-id}}.app.logto fica disponível para teste.
O que o Logto te dá à partida, sem te tornares especialista DNS ou PKI:
Um tenant, vários domínios. Mapeia regiões, ambientes, clientes ou marcas para os seus próprios hosts de login sem duplicar tenants. Existem limites de plano, mas a promessa é esta: um backbone de identidade, múltiplos pontos de entrada.
O domínio por defeito continua ativo. Adicionar auth.example.com não desativa {{tenant-id}}.app.logto. Usa o domínio por defeito para ferramentas internas ou rollouts faseados, enquanto os utilizadores principais usam o domínio de marca.
Conectores ajustam-se automaticamente. Os SDKs apontam para o endpoint certo, e os conectores sociais ou SSO listam todos os redirect URI ou ACS URL válidos—sem malabarismos manuais de URL.
SSL automático. Depois de adicionares o CNAME, o Logto verifica o DNS, provisiona os certificados e mantém-nos renovados. Sem gestão de chaves, sem expirações surpresa.
Podes experimentar já múltiplos domínios personalizados:
Ir a Consola > Definições > Domínios. Adiciona um segundo domínio para uma nova região a lançar, ou para um cliente empresarial que quer login personalizado, etc.
Atualiza o endpoint nos SDKs onde necessário.
Acrescenta as redirect URI e ACS URL sensíveis ao domínio que o Logto te fornece nos conectores Sociais ou SSO aos teus fornecedores de identidade.
É uma forma fácil de limpares a tua experiência de login e testar o impacto na confiança e na conversão.
Vai a Consola > Definições > Domínios. Usa a alocação gratuita de domínios personalizados para definires auth.example.com como domínio de login público desde o início.
Guarda o domínio por defeito {{tenant-id}}.app.logto para uso interno ou testes.
Vais evitar completamente o problema do login “parece staging” e no futuro não precisas de reverter uma migração de domínios já em modo de crescimento.
Queres o guia passo-a-passo, incluindo DNS e resolução de problemas?
Consulta o guia completo na doc: Domínios personalizados para Logto Cloud.
