O que é um domínio personalizado de autenticação e porque interessa ter múltiplos domínios

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.

Porque subdomínios e não domínios raiz?#

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:

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

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

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

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

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

Um ou vários domínios personalizados#

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:

Como o Logto facilita domínios personalizados#

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.

Próximos passos#

Se leste até aqui, provavelmente estás num destes dois cenários.

Já usas Logto?#

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.

Novo no Logto?#

Se estás a começar agora:

• Regista-te no Logto e cria um tenant.
• 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.