Wat is een aangepaste authenticatiedomein en waarom meerdere domeinen belangrijk zijn

Als je ooit te snel een product hebt uitgebracht, zal dit verhaal bekend klinken.

Je app draait tevreden op example.com. Marketing voert campagnes, gebruikers schrijven zich in, alles oogt gepolijst. Dan klikt een nieuwe gebruiker op Inloggen.

In plaats van een vertrouwde URL zoals auth.example.com, springt de browser naar iets dat lijkt op een testomgeving: my-tenant-123.app.logto

Technisch gezien is er niets mis. De pagina is veilig. Het inloggen werkt nog steeds.
Maar de eerste reactie van de gebruiker is:

"Wacht, waar ben ik net heen gegaan?"

Dat ene moment van twijfel is waar gebruikers afhaken.

• Vanuit een conversie-perspectief zijn inloggen en registreren het nauwste deel van je funnel. Elk extra "Wat is dit domein?"-moment zorgt voor frictie.
• Vanuit beveiliging wordt gebruikers al jaren verteld "controleer de URL". Als het login-domein niet bij jouw merk past, lijkt het meer op phishing dan op productie.

Er is een reden dat bijna elk groot bedrijf een vorm gebruikt van:

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

Ze doen dit niet voor de lol. Ze doen het omdat het inlogdomein deel uitmaakt van de productervaring.

In deze post kijken we naar:

• Wat een aangepast authenticatiedomein eigenlijk is
• Wanneer één login-domein genoeg is — en wanneer je op meerdere moet plannen
• De meest voorkomende fouten met login-domeinen (en hoe je "redirect URI does not match"-problemen voorkomt)
• Hoe Logto's ondersteuning voor aangepaste domeinen je hierbij helpt zonder dat je een fulltime DNS-engineer hoeft te worden

Wat is een aangepast authenticatiedomein?#

Hou het simpel.

Elke Logto-tenant krijgt een standaarddomein: {{tenant-id}}.app.logto. Dus het moment dat gebruikers vroeger naar: https://my-tenant-123.app.logto/sign-in werden gestuurd.

Een aangepast authenticatiedomein vervangt die zichtbare URL door eentje die je bezit — bijvoorbeeld auth.example.com. Je houdt gebruikers nu op merk met: https://auth.example.com/sign-in.

Zelfde authenticatieservice onder de motorkap. Hele andere eerste indruk.

Waarom subdomeinen en geen hoofddomeinen?#

Bij Logto zijn aangepaste domeinen ontworpen om te werken als subdomeinen, zoals:

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

Dit is praktisch juist gewenst voor authenticatie:

• Hoofddomeinen zijn meestal gereserveerd voor je hoofdsite (example.com).
• De DNS "zone apex" kan geen CNAME gebruiken, en Logto's gehoste login vereist een CNAME naar domains.logto.app voor routering.
• Logto beheert certificaten via Cloudflare. Om TLS op een hoofddomein te laten eindigen, moeten we die hele zone controleren (inclusief bestaande A, MX, TXT enz.), wat niet haalbaar is voor multi-tenant SaaS.

Apex-flattening records (ALIAS/ANAME) wijzen alsnog naar IP's die wij niet bezitten, dus die kunnen wij niet ondersteunen met onze certificaten. Kortom, de gehoste login moet op een subdomein staan. Wijs dat subdomein aan Logto toe met een CNAME en wij regelen de verificatie, SSL en uptime — je hoofddomein blijft beschikbaar voor de rest van je site.

Waarom het niet "alleen een CNAME toevoegen en klaar" is#

Een veelgemaakte misvatting:

"Ik voeg gewoon een CNAME toe aan mijn DNS en ik ben klaar, toch?"

Helaas niet.

Het veranderen van het zichtbare login-domein is slechts een deel van het verhaal. Zodra je een aangepast authenticatiedomein introduceert, raak je:

• De inlog- en registratiepagina-URL
  Gebruikers bezoeken nu https://auth.example.com/... voor de gehoste pagina's.

• OIDC / OAuth redirect-URI's
  Je apps en connectoren moeten hetzelfde domein gebruiken in hun redirect/callback-URL's, anders krijg je redirect_uri_mismatch-fouten.

• Social logins & enterprise SSO (IdP's)
  Google, GitHub, Azure AD, Okta, enz., valideren allemaal redirect-URI's of ACS-URL's inclusief het domein.

• Passkeys (WebAuthn)
  Passkeys zijn gekoppeld aan het exacte domein waarop ze zijn geregistreerd. Wijzig je dat domein, werken die passkeys niet meer.

• SDK-configuratie
  Je Logto-SDK's gebruiken een endpoint die naar het domein van je tenant wijst. Als het endpoint het verkeerde domein gebruikt, raken je app en identity-laag uit de pas.

Dus, is er DNS bij betrokken? Absoluut.
Maar als je alleen denkt in termen van "ik heb een CNAME toegevoegd dus ik ben klaar", breek je vrijwel zeker iets anders.

Een snel mentaal model: hoe het login-domein door de stack stroomt#

Stel je een diagram voor waarin de browser van de gebruiker begint bij:

1. Adresbalk van de browser

   • Gebruiker klikt op Inloggen op https://example.com.
   • Wordt doorgestuurd naar https://auth.example.com/sign-in.

2. Authorization server & discovery document

   • Je app gebruikt het OpenID-configuratie-endpoint op:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • Dit vertelt je app waar authenticatieaanvragen heen moeten en waar tokens verwacht worden.

3. Redirect-URI's (OIDC/OAuth callbacks)

   • Nadat de gebruiker is ingelogd, stuurt Logto terug naar bijvoorbeeld:
     https://app.example.com/callback
   • Zowel IdP als je applicatie moeten het eens zijn over die URL's.

4. Social login / enterprise SSO-hops

   • Vanuit auth.example.com kan de gebruiker ook springen naar Google, Microsoft Entra ID, Okta, etc.
   • Die providers zien en valideren ook redirect-URI's met je aangepaste authenticatiedomein.

5. E-mails en magic links / wachtwoord reset links

   • Links in e-mails moeten consistent wijzen naar jouw custom domein om verwarring te voorkomen.

Bij elke stap is het domein belangrijk. Wanneer je een aangepast login-domein introduceert, wil je dat dit domein door de hele keten heen consistent aanwezig is.

Daarom draait een goed doordachte domeinstrategie minder om DNS-trucs en meer om samenhangend identity design.

Één vs. meerdere aangepaste domeinen#

Voor veel teams is één aangepaste domein zoals auth.example.com prima. Maar naarmate je product, geografie of klantenbestand groeit, loop je snel tegen beperkingen aan als je niet vooruit plant.

Zo koppelen verschillende teams domeinen aan hun authenticatie:

Hoe Logto aangepaste domeinen makkelijk maakt#

Dit krijg je standaard bij Logto, zonder dat je DNS- of certificaatexpert hoeft te zijn.

• Eén tenant, veel domeinen. Koppel regio's, omgevingen, klanten of merken aan hun eigen login-host zonder tenants te klonen. Afhankelijk van je abonnement zijn er limieten, maar het belangrijkste: één identity backbone, veel ingangen.
• Standaard blijft actief. Het toevoegen van auth.example.com zet {{tenant-id}}.app.logto niet uit. Gebruik het standaarddomein voor interne tools of gefaseerde uitrol terwijl productiegebruikers het branded domein krijgen.
• Connectors passen zich aan. SDK’s wijzen naar het juiste endpoint, en social/enterprise SSO-connectors tonen alle geldige redirect- of ACS-URL’s per domein — geen handmatig URL-gedoe.
• SSL op de automatische piloot. Na het toevoegen van de CNAME controleert Logto de DNS, regelt certificaten en houdt ze actueel. Geen sleutelbeheer of verrassende verlopen.

Wat nu?#

Als je tot hier hebt gelezen, hoor je waarschijnlijk tot één van deze twee groepen.

Gebruik je Logto al?#

Je kunt meteen aan de slag met meerdere aangepaste domeinen:

• Ga naar Console > Instellingen > Domeinen. Voeg een tweede aangepast domein toe voor een nieuwe regio die je gaat lanceren of voor een grote klant die een branded login wil, etc.
• Werk het SDK endpoint bij waar nodig.
• Voeg de domein-afhankelijke redirect-URI’s en ACS-URL’s van Logto toe aan je Social of SSO-connectors bij je identity providers.

Het is een eenvoudige manier om je loginervaring te verbeteren en het effect op gebruikersvertrouwen en conversie te testen.

Nieuw bij Logto?#

Als je net begint:

• Registreer je voor Logto en maak een tenant aan.
• Ga naar Console > Instellingen > Domeinen. Gebruik de gratis toewijzing van aangepaste domeinen om auth.example.com direct als publieke login te gebruiken.
• Houd het standaard {{tenant-id}}.app.logto-domein bij de hand voor intern gebruik of testen.

Je voorkomt het "dit lijkt op een staging URL"-probleem en hoeft later niet aan een rommelige domeinovergang te beginnen als je al in groeimodus bent.

Wil je alle stappen, inclusief DNS-records en troubleshooting?
Bekijk de volledige handleiding in onze documentatie: Aangepaste domeinen voor Logto Cloud.