Leer hoe aangepaste authenticatiedomeinen en meerdere domeinen conversie, beveiliging en branding verbeteren; en hoe Logto je helpt ze te beheren zonder DNS-hoofdpijn.
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.
Er is een reden dat bijna elk groot bedrijf een vorm gebruikt van:
login.company.comauth.company.comaccounts.company.comZe doen dit niet voor de lol. Ze doen het omdat het inlogdomein deel uitmaakt van de productervaring.
In deze post kijken we naar:
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.
Bij Logto zijn aangepaste domeinen ontworpen om te werken als subdomeinen, zoals:
auth.example.comauth.us.example.comDit is praktisch juist gewenst voor authenticatie:
example.com).domains.logto.app voor routering.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.
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.
Stel je een diagram voor waarin de browser van de gebruiker begint bij:
Adresbalk van de browser
https://example.com.https://auth.example.com/sign-in.Authorization server & discovery document
https://auth.example.com/oidc/.well-known/openid-configurationRedirect-URI's (OIDC/OAuth callbacks)
https://app.example.com/callbackSocial login / enterprise SSO-hops
auth.example.com kan de gebruiker ook springen naar Google, Microsoft Entra ID, Okta, etc.E-mails en magic links / wachtwoord reset links
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.
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:
| Scenario | Voorbeeld domeinen | Waarom het helpt |
|---|---|---|
| Eén branded login | auth.example.com, account.example.com | Houdt de adresbalk on-brand terwijl het standaard {{tenant-id}}.app.logto domein beschikbaar blijft om te testen. |
| Regionale ervaringen | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | Binnen één tenant content, toestemmingen en compliance-berichten localiseren naar geografie. |
| Omgevingsscheiding | auth.staging.example.com, auth.example.com | QA- en preview-verkeer isoleren zonder elke tenant of connector te klonen. |
| Per-organisatie branding | auth.customer-a.com, auth.customer-b.com | Witte labels aanbieden voor enterprise klanten, terwijl je gebruikers, organisaties en SSO centraal beheert. |
| Merk- of productlijnen | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | Elke brand een samenhangende loginervaring bieden zonder je identiteitsstack te versnipperen. |
| Meerdere TLD's | auth.foo.com, auth.foo.co.uk, auth.foo.dev | Landensites of speciale domeinen ondersteunen zonder de configuratie steeds opnieuw op te voeren. |
| Infrastructuur-gedreven | auth.edge.example.com, auth.api.example.com | Op één lijn met CDN- of edge-routingregels terwijl Logto identiteitsbackend blijft voor die hosts. |
Dit krijg je standaard bij Logto, zonder dat je DNS- of certificaatexpert hoeft te zijn.
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.endpoint, en social/enterprise SSO-connectors tonen alle geldige redirect- of ACS-URL’s per domein — geen handmatig URL-gedoe.Als je tot hier hebt gelezen, hoor je waarschijnlijk tot één van deze twee groepen.
Je kunt meteen aan de slag met meerdere aangepaste domeinen:
endpoint bij waar nodig.Het is een eenvoudige manier om je loginervaring te verbeteren en het effect op gebruikersvertrouwen en conversie te testen.
Als je net begint:
auth.example.com direct als publieke login te gebruiken.{{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.