Was ist ein benutzerdefinierter Authentifizierungs-Domain und warum spielen mehrere Domains eine Rolle?

Wenn du jemals ein Produkt etwas zu schnell veröffentlicht hast, kommt dir diese Geschichte sicher bekannt vor.

Deine App lebt glücklich auf example.com. Das Marketing schaltet Kampagnen, Nutzer melden sich an, alles wirkt ausgereift. Dann klickt ein neuer Nutzer auf Anmelden.

Statt einer vertrauten URL wie auth.example.com springt der Browser zu etwas, das wie eine Testumgebung aussieht: my-tenant-123.app.logto

Technisch ist alles in Ordnung. Die Seite ist sicher. Der Login funktioniert weiterhin.
Doch die erste Reaktion des Nutzers ist:

„Moment mal, wo bin ich da gerade gelandet?“

Diese eine Sekunde des Zweifelns ist der Moment, in dem Absprünge passieren.

• Aus Conversion-Sicht sind Anmeldung und Registrierung der engste Teil deines Funnels. Jeder zusätzliche „Was ist das für eine Domain?“-Moment sorgt für Reibung.
• Aus Sicherheits-Sicht hört man seit Jahren: „Überprüfe die URL“. Wenn die Login-Domain nicht zu deiner Marke passt, wirkt sie eher wie Phishing als wie Produktion.

Es gibt einen Grund, warum praktisch jedes große Unternehmen Folgendes nutzt:

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

Sie tun das nicht aus Spaß. Sie tun es, weil die Login-Domain Teil des Produkterlebnisses ist.

In diesem Beitrag sehen wir uns an:

• Was ist eigentlich ein benutzerdefinierter Authentifizierungs-Domain?
• Wann reicht eine Login-Domain — und wann solltest du mehrere einplanen?
• Die häufigsten Fehler mit Login-Domains (und wie man die „redirect URI stimmt nicht überein“-Hölle vermeidet)
• Wie Logtos Unterstützung für benutzerdefinierte Domains dir dabei hilft, all dies zu tun — ohne ein Fulltime-DNS-Engineer werden zu müssen

Was ist ein benutzerdefinierter Authentifizierungs-Domain?#

Lass es uns einfach halten.

Jeder Logto-Tenant wird mit einer Standarddomain geliefert: {{tenant-id}}.app.logto. Also sah der Moment bisher so aus: https://my-tenant-123.app.logto/sign-in.

Eine benutzerdefinierte Authentifizierungsdomain tauscht diese sichtbare URL gegen eine aus, die dir gehört – zum Beispiel auth.example.com. Damit bleiben die Nutzer unter deiner Marke bei: https://auth.example.com/sign-in.

Gleicher Authentifizierungsdienst im Hintergrund. Aber ein ganz anderer erster Eindruck.

Warum Subdomains und keine Root Domains?#

Mit Logto sind benutzerdefinierte Domains als Subdomains ausgelegt, etwa:

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

Praktisch ist das ohnehin meist die beste Wahl für Authentifizierung:

• Root-Domains sind üblicherweise für deine Hauptseite reserviert (example.com).
• Der DNS-„Zone Apex“ kann kein CNAME verwenden, und Logtos gehostetes Login erfordert ein CNAME zu domains.logto.app für das Routing des Traffics.
• Logto verwaltet Zertifikate via Cloudflare. Um TLS auf einer Root-Domain zu beenden, müssten wir die gesamte Zone kontrollieren (inklusive deiner bestehenden A, MX, TXT usw.), was für ein Multi-Tenant-SaaS nicht praktikabel ist.

Apex-Flattening-Records (ALIAS/ANAME) verweisen weiterhin auf IPs, die uns nicht gehören, daher können sie unsere verwalteten Zertifikate nicht unterstützen. Kurz gesagt: das gehostete Login muss auf einer Subdomain laufen. Zeige diese Subdomain mit einem CNAME auf Logto und wir übernehmen Verifizierung, SSL und Verfügbarkeit – deine Apex-Domain bleibt frei für den Rest deiner Website.

Warum es nicht „nur ein CNAME und fertig“ ist#

Ein sehr verbreitetes Missverständnis:

„Ich setze einfach ein CNAME in meinem DNS und bin fertig, oder?“

Leider nein.

Die sichtbare Login-Domain zu ändern, ist nur ein Teil der Geschichte. Sobald du eine benutzerdefinierte Auth-Domain einführst, betrifft das:

• Die URL der Anmelde- und Registrierungsseite
  Nutzer besuchen jetzt https://auth.example.com/... für die gehosteten Seiten.

• OIDC / OAuth Redirect URIs
  Deine Apps und Konnektoren müssen die gleiche Domain in ihren Redirect-/Callback-URLs verwenden, sonst gibt es Fehler wie redirect_uri_mismatch.

• Soziale Logins & Enterprise SSO (IdPs)
  Google, GitHub, Azure AD, Okta usw. prüfen Redirect-URIs bzw. ACS-URLs inklusive der Domain.

• Passkeys (WebAuthn)
  Passkeys sind exakt an die Domain gebunden, auf der sie registriert wurden. Ändert sich die Domain, funktionieren diese Passkeys nicht mehr.

• SDK-Konfiguration
  Deine Logto-SDKs verwenden einen endpoint, der auf die Domain deines Tenants zeigt. Wird der falsche Domain genutzt, driften App und Identity-Layer auseinander.

Gibt es also DNS-Aufwand? Auf jeden Fall.
Wer aber nur denkt „Ich habe ein CNAME gesetzt, also bin ich fertig“, wird fast zwangsläufig an anderer Stelle etwas kaputt machen.

Ein schnelles mentales Modell: wie die Login-Domain durch den Stack fließt#

Stell dir ein Diagramm vor, in dem der Browser des Nutzers startet bei:

1. Adresse im Browser

   • Nutzer klickt auf Anmelden auf https://example.com.
   • Es erfolgt ein Redirect zu https://auth.example.com/sign-in.

2. Authorization Server & Discovery Document

   • Deine App nutzt das OpenID-Konfigurations-Endpunkt unter:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • Das teilt deiner App mit, wohin Authentifizierungsanfragen gesendet und wo Tokens erwartet werden.

3. Redirect-URIs (OIDC/OAuth Callback-URLs)

   • Nach dem Login leitet Logto zurück auf z. B.:
     https://app.example.com/callback
   • IdP und deine Anwendung müssen sich auf diese URLs einigen.

4. Soziales Login / Enterprise-SSO-Hops

   • Von auth.example.com springt der Nutzer ggf. zu Google, Microsoft Entra ID, Okta usw.
   • Diese Provider validieren die Redirect-URIs, inklusive deiner benutzerdefinierten Auth-Domain.

5. E-Mails und Magic Links / Passwort-Reset-Links

   • Links in E-Mails sollten konsistent auf deine benutzerdefinierte Domain zeigen, um Nutzer nicht zu verwirren.

In jedem dieser Schritte spielt die Domain eine Rolle. Wenn du eine benutzerdefinierte Login-Domain einführst, sollte diese Domain konsistent durch die gesamte Kette fließen.

Deshalb ist eine durchdachte Strategie für benutzerdefinierte Domains weniger eine Frage von DNS-Tricks, sondern vielmehr von kohärentem Identity-Design.

Eine oder mehrere benutzerdefinierte Domains#

Für viele Teams reicht eine einzige benutzerdefinierte Domain wie auth.example.com vollkommen aus. Doch sobald dein Produkt, die Geografie oder die Kundenbasis wachsen, stößt du schnell an Grenzen, wenn du nicht vorausdenkst.

So koppeln verschiedene Teams typischerweise Domains an ihre Authentifizierungserfahrung:

Wie Logto benutzerdefinierte Domains einfach macht#

Das bekommst du mit Logto direkt von Haus aus — ohne zum DNS- oder PKI-Profi werden zu müssen:

• Ein Tenant, viele Domains. Ordne Regionen, Umgebungen, Kunden oder Marken ihren eigenen Login-Hosts zu, ohne Tenants klonen zu müssen. Planlimits gelten, aber das Kernversprechen bleibt: Ein Identitäts-Backbone, viele Einstiegspunkte.
• Standard bleibt aktiv. Durch das Hinzufügen von auth.example.com wird {{tenant-id}}.app.logto nicht deaktiviert. Verwende die Standarddomain für interne Tools oder schrittweise Rollouts, während Produktivnutzer die Marken-Domain nutzen.
• Connectoren passen sich automatisch an. SDKs zeigen auf den richtigen endpoint, und Social- bzw. Enterprise-SSO-Connectoren listen für jede Domain jede gültige Redirect-URI oder ACS-URL auf – kein manuelles URL-Management.
• SSL vollautomatisch. Nachdem du das CNAME gesetzt hast, übernimmt Logto die DNS-Prüfung, Zertifikatsbereitstellung und -erneuerung. Kein Schlüsselmanagement, keine Überraschungsabläufe.

Was du als nächstes tun kannst#

Wenn du bis hier gelesen hast, gehörst du wahrscheinlich zu einer dieser zwei Gruppen.

Du nutzt Logto bereits?#

Du kannst sofort mit mehreren benutzerdefinierten Domains experimentieren:

• Gehe zu Konsole > Einstellungen > Domains. Füge eine weitere benutzerdefinierte Domain für eine neue Region oder einen wichtigen Unternehmenskunden hinzu, der eigenes Branding wünscht.
• Passe ggf. den SDK-endpoint an.
• Ergänze die von Logto bereitgestellten weiterleitungsfähigen Redirect-URIs und ACS-URLs in den Social- oder SSO-Connectors bei deinen Identity-Providern.

Ein einfacher Weg, das Login-Erlebnis aufzuräumen und Vertrauen sowie Conversion zu testen.

Neu bei Logto?#

Wenn du gerade erst startest:

• Registriere dich bei Logto und erstelle einen Tenant.
• Gehe zu Konsole > Einstellungen > Domains. Nutze die kostenlose Domain-Zuteilung, um auth.example.com ab Tag eins als öffentliche Login-Domain zu setzen.
• Behalte die Standarddomain {{tenant-id}}.app.logto für interne Zwecke oder zum Testen griffbereit.

So umgehst du von Anfang an das „Das sieht wie Staging aus“-Login-URL-Problem, und dein zukünftiges Ich muss keine komplexe Domain-Migration rückabwickeln, wenn du bereits im Wachstum bist.

Willst du die Schritt-für-Schritt-Anleitung mit DNS-Records und Troubleshooting?
Schau dir den vollständigen Guide in unseren Docs an: Benutzerdefinierte Domains für Logto Cloud.