Lär dig hur anpassade autentiseringsdomäner och flera domäner förbättrar konvertering, säkerhet och varumärke; samt hur Logto hjälper dig hantera dem utan DNS-bekymmer.
Om du någonsin har släppt en produkt lite för snabbt kommer denna historia kännas bekant.
Din app lever glatt på example.com. Marknadsföring kör kampanjer, användare registrerar sig, allt ser proffsigt ut. Sedan klickar en ny användare på Logga in.
Istället för en välbekant adress som auth.example.com hoppar webbläsaren till något som ser ut som en testmiljö: my-tenant-123.app.logto
Tekniskt sett är inget fel. Sidan är säker. Inloggningen fungerar fortfarande.
Men användarens första reaktion är:
”Vänta, vart hamnade jag?”
Detta ögonblick av tvekan är när avhopp sker.
Det är därför nästan alla större företag använder någon form av:
login.company.comauth.company.comaccounts.company.comDe gör inte detta för skojs skull. De gör det för att inloggningsdomänen är en del av produktupplevelsen.
I detta inlägg kommer vi att titta på:
Vi håller det enkelt.
Varje Logto-tenant levereras med en standarddomän: {{tenant-id}}.app.logto. Så den stund som brukade skicka användare till: https://my-tenant-123.app.logto/sign-in.
En anpassad autentiseringsdomän byter den synliga webbadressen till en du äger — till exempel auth.example.com. Nu håller sig användarna till din stil på: https://auth.example.com/sign-in.
Samma autentiseringstjänst i bakgrunden. Ett helt annat första intryck.
Med Logto är anpassade domäner tänkta att fungera som subdomäner, såsom:
auth.example.comauth.us.example.comI praktiken är detta vad du vill ha för autentisering ändå:
example.com).domains.logto.app för trafikrouting.A, MX, TXT etc.), vilket inte är möjligt för en multi-tenant SaaS.Apex-flattening-poster (ALIAS/ANAME) pekar fortfarande mot IP-adresser vi inte äger, så de kan inte hantera våra hanterade certifikat. Kort sagt måste den hostade inloggningen leva på en subdomän. Peka subdomänen till Logto med en CNAME så hanterar vi verifiering, SSL och drifttid — din rotdomän förblir fri att serva resten av din webbplats.
En mycket vanlig missuppfattning:
”Jag lägger bara till en CNAME i min DNS och är klar, eller hur?”
Tyvärr inte.
Att byta den synliga inloggningsdomänen är bara en del av historien. När du introducerar en anpassad autentiseringsdomän påverkar du:
Webbadressen för inloggnings- och registreringssidan
Användare besöker nu https://auth.example.com/... för hostade sidor.
OIDC / OAuth redirect URIs
Dina appar och anslutningar måste använda samma domän i sina redirect/callback-URL:er, annars får du redirect_uri_mismatch-fel.
Sociala inloggningar & företags-SSO (IdPs)
Google, GitHub, Azure AD, Okta osv. validerar redirect URIs eller ACS-URL:er inklusive domännamnet.
Passkeys (WebAuthn)
Passkeys är bundna till exakt den domän där de registrerades. Byter du domän fungerar dessa passkeys inte längre.
SDK-konfiguration
Dina Logto-SDK:er använder en endpoint som pekar till din tenants domän. Om endpointen använder fel domän kommer din app och identitetslagret att hamna i osynk.
Är DNS inblandad? Absolut.
Men om du bara tänker ”Jag har lagt till en CNAME så är jag klar”, så kommer du nästan säkert att förstöra något annat.
Föreställ dig ett diagram där användarens webbläsare börjar på:
Webbläsarens adressfält
https://example.com.https://auth.example.com/sign-in.Auktoriseringsserver & upptäcktsdokument
https://auth.example.com/oidc/.well-known/openid-configurationRedirect URIs (OIDC/OAuth callbacks)
https://app.example.com/callbackSociala inloggningar / företags-SSO
auth.example.com kan användaren hoppa till Google, Microsoft Entra ID, Okta osv.E-post och magiska länkar / länkar för att återställa lösenord
I varje steg spelar domänen roll. När du introducerar en anpassad inloggningsdomän vill du att den domänen ska flöda genom hela kedjan på ett konsekvent sätt.
Det är därför en genomtänkt strategi för anpassade domäner handlar mindre om DNS-trick och mer om koherent identitetsdesign.
För många team räcker en enda anpassad domän som auth.example.com alldeles utmärkt. Men i takt med att din produkt, geografi och kundbas växer kommer du snabbt att stöta på begränsningar om du inte planerar i förväg.
Så här brukar olika team matcha domäner mot sina autentiseringsupplevelser:
| Scenario | Exempeldomäner | Varför det hjälper |
|---|---|---|
| En varumärkes-anpassad inloggning | auth.example.com, account.example.com | Håller adressfältet varumärkesanpassat medan standarddomänen {{tenant-id}}.app.logto finns kvar för testning. |
| Regionala upplevelser | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | Lokalisera innehåll, samtyckesflöden och efterlevnadsnotiser per geografi inom en och samma tenant. |
| Miljöuppdelning | auth.staging.example.com, auth.example.com | Isolera QA- och förhandsvisningstrafik utan att klona varje tenant eller anslutning. |
| Varje organisation eget varumärke | auth.customer-a.com, auth.customer-b.com | Ge vitmärkta inloggningspunkter för företagskunder samtidigt som användare, organisationer och SSO hanteras centralt. |
| Varumärkes- eller produktlinjer | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | Ge varje varumärke en sammanhängande inloggningsupplevelse utan att fragmentera din identitetsstack. |
| Flera TLD:er | auth.foo.com, auth.foo.co.uk, auth.foo.dev | Stöd landspecifika sidor eller specialiserade domäner utan att duplicera konfiguration regionvis. |
| Infrastrukturdrevet | auth.edge.example.com, auth.api.example.com | Anpassa till CDN- eller edge-routingregler medan Logto fortsätter som identitetsbackend bakom dessa hosts. |
Detta får du med Logto direkt ur lådan, utan att behöva bli DNS- eller PKI-expert.
auth.example.com avaktiverar inte {{tenant-id}}.app.logto. Använd standarden för interna verktyg eller stegvisa utrullningar medan produktionsanvändare når varumärkesdomänen.endpoint, medan sociala och företags-SSO-anslutningar listar alla giltiga redirect URIs eller ACS-URL:er för varje domän — inget manuellt URL-pusslande.Om du läst så här långt är du troligen i ett av två läger.
Du kan börja experimentera med flera anpassade domäner direkt:
endpoint där det behövs.Det är ett enkelt sätt att snygga till din inloggningsupplevelse och testa effekten på användarförtroende och konvertering.
Om du precis är i startgroparna:
auth.example.com som publik inloggningsdomän från dag ett.{{tenant-id}}.app.logto för interna ändamål eller test.Du slipper helt problemet ”det här ser ut som staging”-inloggnings-URL, och framtida du slipper trassla med domänmigration när du redan är i tillväxtläge.
Vill du ha steg-för-steg-anvisningar, inklusive DNS-poster och felsökning?
Se hela guiden i vår dokumentation: Anpassade domäner för Logto Cloud.