Português (Brasil)
  • Domínios personalizados
  • Múltiplos domínios
  • Autenticação

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.

Ran
Ran
Product & 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.
Começar
Product screenshot

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.

Por que subdomínios, não domínios raiz?

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.

Por que não é “só adicionar o CNAME e pronto”

Um equívoco muito comum:

“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:

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

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

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

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

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

Único vs. múltiplos domínios personalizados

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árioExemplos de domíniosPor que ajuda
Um login com brandingauth.example.com, account.example.comMantém o endereço na marca enquanto o domínio padrão {{tenant-id}}.app.logto fica disponível para testes.
Experiências regionaisauth.us.example.com, auth.eu.example.com, auth.apac.example.comLocalize conteúdo, fluxos de consentimento e avisos de compliance por região, em um mesmo tenant.
Ambientes separadosauth.staging.example.com, auth.example.comIsole tráfego de QA e prévia sem clonar tenants ou conectores.
Branding por organizaçãoauth.customer-a.com, auth.customer-b.comOfereça pontos de entrada white-label para clientes enterprise mantendo usuários, orgs e SSO centralizados.
Linhas de produto/marcaauth.shop.example.com, auth.app.example.com, auth.studio.example.comDê a cada marca uma experiência de login integrada sem fragmentar sua stack de identidade.
Múltiplos TLDsauth.foo.com, auth.foo.co.uk, auth.foo.devSuporte sites por país ou domínios especiais sem precisar replicar config por região.
Focado em infraestruturaauth.edge.example.com, auth.api.example.comAlinhe com regras de CDN/edge mantendo o Logto como backend de identidade nesses hosts.

Como o Logto facilita domínios personalizados

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.

Para onde ir daqui

Se chegou até aqui, provavelmente você está em um de dois grupos.

Já usa Logto?

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.

Novo no Logto?

Se está começando agora:

  • Cadastre-se em Logto e crie um tenant.
  • 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.