Svenska
  • Anpassade domäner
  • Flera domäner
  • Autentisering

Vad är autentiseringens anpassade domän och varför flera domäner är viktiga

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.

Ran
Ran
Product & Design

Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Kom igång
Product screenshot

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.

  • Ur ett konverteringsperspektiv är inloggningen den smalaste delen av din funnel. Varje extra ”Vad är detta för domän?”-moment skapar friktion.
  • Ur ett säkerhetsperspektiv har användare fått höra ”kolla på adressen” i åratal. Om inloggningsdomänen inte matchar ditt varumärke ser det mer ut som nätfiske än produktion.

Det är därför nästan alla större företag använder någon form av:

  • login.company.com
  • auth.company.com
  • accounts.company.com

De 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å:

  • Vad en anpassad autentiseringsdomän egentligen är
  • När en inloggningsdomän räcker — och när du bör planera för flera
  • De vanligaste misstagen med inloggningsdomäner (och hur du undviker ”redirect URI does not match”-misären)
  • Hur Logtos stöd för anpassade domäner hjälper dig göra allt detta utan att bli en heltids-DNS-tekniker

Vad är en anpassad autentiseringsdomän?

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.

Varför subdomäner, inte rotdomäner?

Med Logto är anpassade domäner tänkta att fungera som subdomäner, såsom:

  • auth.example.com
  • auth.us.example.com

I praktiken är detta vad du vill ha för autentisering ändå:

  • Rotdomäner är vanligtvis reserverade för din huvudsida (example.com).
  • DNS ”zone apex” kan inte använda en CNAME, och Logtos hostade inloggning kräver en CNAME till domains.logto.app för trafikrouting.
  • Logto hanterar certifikat via Cloudflare. För att terminera TLS på en rotdomän måste vi kontrollera hela zonen (inklusive dina befintliga 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.

Varför det inte är ”bara lägga till en CNAME och klart”

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.

En snabb mental modell: hur inloggningsdomänen flödar genom stacken

Föreställ dig ett diagram där användarens webbläsare börjar på:

  1. Webbläsarens adressfält

    • Användaren klickar Logga in på https://example.com.
    • De omdirigeras till https://auth.example.com/sign-in.

  2. Auktoriseringsserver & upptäcktsdokument

    • Din app använder OpenID-konfigurationsendpoint på:
      https://auth.example.com/oidc/.well-known/openid-configuration
    • Detta talar om för din app var den ska skicka autentiseringsbegäran och hämta tokens.

  3. Redirect URIs (OIDC/OAuth callbacks)

    • Efter att användaren loggat in skickar Logto tillbaka till din app på något som:
      https://app.example.com/callback
    • Både IdP och din applikation måste vara överens om dessa URL:er.

  4. Sociala inloggningar / företags-SSO

    • Från auth.example.com kan användaren hoppa till Google, Microsoft Entra ID, Okta osv.
    • Dessa leverantörer ser också och validerar redirect URIs som inkluderar din anpassade autentiseringsdomän.

  5. E-post och magiska länkar / länkar för att återställa lösenord

    • Länkar i e-post bör alltid peka på din anpassade domän för att undvika förvirring hos användarna.

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.

En eller flera anpassade domäner

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:

ScenarioExempeldomänerVarför det hjälper
En varumärkes-anpassad inloggningauth.example.com, account.example.comHåller adressfältet varumärkesanpassat medan standarddomänen {{tenant-id}}.app.logto finns kvar för testning.
Regionala upplevelserauth.us.example.com, auth.eu.example.com, auth.apac.example.comLokalisera innehåll, samtyckesflöden och efterlevnadsnotiser per geografi inom en och samma tenant.
Miljöuppdelningauth.staging.example.com, auth.example.comIsolera QA- och förhandsvisningstrafik utan att klona varje tenant eller anslutning.
Varje organisation eget varumärkeauth.customer-a.com, auth.customer-b.comGe vitmärkta inloggningspunkter för företagskunder samtidigt som användare, organisationer och SSO hanteras centralt.
Varumärkes- eller produktlinjerauth.shop.example.com, auth.app.example.com, auth.studio.example.comGe varje varumärke en sammanhängande inloggningsupplevelse utan att fragmentera din identitetsstack.
Flera TLD:erauth.foo.com, auth.foo.co.uk, auth.foo.devStöd landspecifika sidor eller specialiserade domäner utan att duplicera konfiguration regionvis.
Infrastrukturdrevetauth.edge.example.com, auth.api.example.comAnpassa till CDN- eller edge-routingregler medan Logto fortsätter som identitetsbackend bakom dessa hosts.

Hur Logto gör anpassade domäner enkelt

Detta får du med Logto direkt ur lådan, utan att behöva bli DNS- eller PKI-expert.

  • En tenant, många domäner. Kartlägg regioner, miljöer, kunder eller varumärken till egna inloggningsvärdar utan att klona tenants. Planbegränsningar gäller, men grundlöftet kvarstår: en identitetsryggrad, många ingångar.
  • Standarddomän fortsätter leva. Att lägga till 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.
  • Anslutningar justeras automatiskt. SDK:er pekar till rätt 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.
  • SSL på autopilot. Efter att du lagt till CNAME verifierar Logto DNS, utfärdar certifikat och håller dem förnyade. Ingen nyckelhantering, inga oväntade utgångar.

Vad händer nu?

Om du läst så här långt är du troligen i ett av två läger.

Redan Logto-användare?

Du kan börja experimentera med flera anpassade domäner direkt:

  • Gå till Console > Inställningar > Domäner. Lägg till en andra anpassad domän för en ny region du snart lanserar, eller för en viktig företagskund som vill ha egen varumärkeslogin, osv.
  • Uppdatera SDK-endpoint där det behövs.
  • Lägg till de domänspecifika redirect URIs och ACS-URL:er som Logto ger i Social- eller SSO-anslutningar hos dina identitetsleverantörer.

Det är ett enkelt sätt att snygga till din inloggningsupplevelse och testa effekten på användarförtroende och konvertering.

Ny på Logto?

Om du precis är i startgroparna:

  • Registrera dig på Logto och skapa en tenant.
  • Gå till Console > Inställningar > Domäner. Använd den fria tilldelningen av anpassade domäner för att sätta upp auth.example.com som publik inloggningsdomän från dag ett.
  • Ha kvar standarddomänen {{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.