Czym jest niestandardowa domena uwierzytelniania i dlaczego wiele domen ma znaczenie
Dowiedz się, jak niestandardowe domeny uwierzytelniania oraz wiele domen poprawiają konwersję, bezpieczeństwo i spójność marki oraz jak Logto pomaga nimi zarządzać bez problemów z DNS.
RanProduct & Design
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Jeśli kiedykolwiek wypuściłeś produkt trochę za szybko, ta historia będzie ci znajoma.
Twoja aplikacja żyje szczęśliwie pod adresem example.com. Marketing prowadzi kampanie, użytkownicy się rejestrują, wszystko wygląda dopracowanie. Wtedy nowy użytkownik klika Zaloguj się.
Zamiast znanego adresu jak auth.example.com, przeglądarka przeskakuje do czegoś, co wygląda jak środowisko testowe: my-tenant-123.app.logto
Technicznie rzecz biorąc, nic złego się nie dzieje. Strona jest bezpieczna. Logowanie nadal działa.
Ale pierwsza reakcja użytkownika to:
„Zaraz, gdzie właściwie trafiłem?”
Ta sekunda niepewności to moment, w którym tracisz użytkowników.
Z punktu widzenia konwersji logowanie i rejestracja to najwęższy punkt twojego lejka. Każda dodatkowa chwila zastanowienia „Co to za domena?” zwiększa tarcie.
Z punktu widzenia bezpieczeństwa użytkownicy od lat słyszą „sprawdzaj adres URL”. Jeśli domena logowania nie pasuje do marki, wygląda to bardziej jak phishing niż środowisko produkcyjne.
Jest powód, dla którego prawie każda duża firma używa jakiejś wersji:
login.company.com
auth.company.com
accounts.company.com
Nie robią tego dla zabawy. Robią to, bo domena logowania jest częścią doświadczenia produktu.
W tym artykule przyjrzymy się:
Czym niestandardowa domena uwierzytelniania tak naprawdę jest
Kiedy jedna domena logowania wystarczy — a kiedy warto zaplanować wiele
Najczęstsze błędy przy domenach logowania (i jak uniknąć piekła „redirect URI does not match”)
Jak obsługa niestandardowych domen w Logto pozwoli ci to wszystko zrobić bez zostawania pełnoetatowym inżynierem DNS
Czym jest niestandardowa domena uwierzytelniania?#
Prosto.
Każdy tenant Logto ma domyślną domenę: {{tenant-id}}.app.logto. To znaczy, że dotychczas użytkownicy byli kierowani na: https://my-tenant-123.app.logto/sign-in.
Niestandardowa domena uwierzytelniania zamienia ten widoczny adres URL na domenę, którą posiadasz — na przykład auth.example.com. Dzięki temu użytkownicy zostają „w twojej marce” pod adresem: https://auth.example.com/sign-in.
Ten sam serwis uwierzytelniania pod spodem. Zupełnie inne pierwsze wrażenie.
W Logto niestandardowe domeny mają działać jako subdomeny, np.:
auth.example.com
auth.us.example.com
W praktyce to właśnie jest pożądane dla autoryzacji:
Domeny główne są zwykle zarezerwowane dla twojej głównej strony (example.com).
„Apex” strefy DNS nie może mieć rekordu CNAME, a hostowany login Logto wymaga CNAME do domains.logto.app dla trasowania ruchu.
Logto zarządza certyfikatami przez Cloudflare. Aby zakończyć TLS na domenie głównej, musielibyśmy kontrolować całą strefę (łącznie z istniejącymi rekordami A, MX, TXT, itp.), co nie jest możliwe dla multi-tenantowego SaaS.
Rekordy apex-flattening (ALIAS/ANAME) nadal rozwiązują się do IP, których nie posiadamy, więc nie mogą obsłużyć naszych zarządzanych certyfikatów. Krótko mówiąc, hostowany login musi działać na subdomenie. Wskaż tę subdomenę na Logto poprzez CNAME, a my zajmiemy się weryfikacją, SSL i dostępnością — twoja domena główna pozostaje wolna dla reszty strony.
Zmiana widocznej domeny logowania to tylko fragment całości. Gdy wprowadzasz niestandardową domenę uwierzytelniania, dotykasz:
Adresów logowania i rejestracji
Użytkownicy odwiedzają teraz https://auth.example.com/... dla hostowanych stron.
OIDC / OAuth redirect URI
Twoje aplikacje i konektory muszą używać tej samej domeny w redirect/callback URL, inaczej otrzymasz błędy typu redirect_uri_mismatch.
Logowania społecznościowe i SSO (IdP)
Google, GitHub, Azure AD, Okta itp. weryfikują redirect URI lub ACS z twoją domeną.
Passkeys (WebAuthn)
Passkeys są powiązane z konkretną domeną, pod którą zostały zarejestrowane. Zmienisz domenę — przestają działać.
Konfiguracja SDK
Twoje SDK Logto używają endpoint, który wskazuje na domenę tenanta. Jeśli endpoint używa złej domeny, aplikacja i warstwa tożsamości się rozjeżdżają.
Czy więc jest DNS w grze? Zdecydowanie.
Ale jeśli myślisz tylko „dodałem CNAME, więc skończone”, prawie na pewno popsujesz coś innego.
Szybka mapa mentalna: jak domena logowania przepływa przez całość#
Wyobraź sobie diagram, w którym przeglądarka użytkownika startuje od:
Pasek adresu przeglądarki
Użytkownik klika Zaloguj się na https://example.com.
Jest przekierowany na https://auth.example.com/sign-in.
Serwer autoryzacyjny i discovery document
Twoja aplikacja używa OpenID config endpoint:
https://auth.example.com/oidc/.well-known/openid-configuration
To mówi twojej aplikacji, gdzie wysyłać żądania uwierzytelniania i skąd oczekiwać tokenów.
Redirect URI (OIDC/OAuth callbacki)
Po zalogowaniu Logto przekieruje z powrotem do aplikacji, np.:
https://app.example.com/callback
IdP i twoja aplikacja muszą uzgodnić te adresy.
Logowania społecznościowe / enterprise SSO
Z auth.example.com użytkownik może przeskoczyć do Google, Microsoft Entra ID, Okta itd.
Te systemy również sprawdzają i walidują redirect URI z twoją domeną auth.
E-maile i magic links / linki resetu hasła
Linki w mailach powinny konsekwentnie wskazywać na twoją niestandardową domenę, by nie dezorientować użytkowników.
Na każdym z tych kroków domena ma znaczenie. Wprowadzasz własną domenę logowania — chcesz, by przewijała się przez cały łańcuch logicznie i spójnie.
Dlatego dobrze przemyślana strategia niestandardowych domen to mniej sztuczki DNS, więcej spójnej architektury tożsamości.
Dla wielu zespołów pojedyncza domena jak auth.example.com wystarczy. Ale wraz z rozwojem produktu, geografii i bazy klientów szybko napotkasz ograniczenia, jeśli tego nie przewidzisz wcześniej.
Oto jak różne zespoły mapują domeny do swoich doświadczeń uwierzytelniania:
Scenariusz
Przykładowe domeny
Dlaczego to pomaga
Jedno logowanie marki
auth.example.com, account.example.com
Brandujesz pasek adresu, zostawiając domyślne {{tenant-id}}.app.logto do testów.
Oto co dostajesz z Logto bez zostawania ekspertem DNS czy PKI:
Jeden tenant, wiele domen. Mapuj regiony, środowiska, klientów czy brandy do własnych hostów logowania bez klonowania tenantów. Obowiązują limity planu, lecz kluczowa zasada: jeden stack tożsamości, wiele punktów wejścia.
Domyślna domena zawsze działa. Dodanie auth.example.com nie wyłącza {{tenant-id}}.app.logto. Domyślna domena przydaje się do narzędzi wewnętrznych lub spokojnego wdrażania nowych rozwiązań, gdy produkcja już korzysta z brandowanej domeny.
Connectory same się dostosowują. SDK wskazują właściwe endpoint, a konektory SSO i społecznościowe wylistują każde poprawne URI redirect/ACS na domenę — koniec z ręcznym przerzucaniem adresów.
SSL w pełni automatyczny. Po dodaniu CNAME, Logto zweryfikuje DNS, wygeneruje certyfikaty i będzie je odnawiać. Bez zarządzania kluczami, bez niespodzianek z przeterminowanymi certyfikatami.
Wejdź na Konsolę > Ustawienia > Domeny. Skorzystaj z darmowej puli niestandardowych domen i ustaw auth.example.com jako publiczny login od pierwszego dnia.
Zachowaj domyślną domenę {{tenant-id}}.app.logto na użytek wewnętrzny lub do testów.
Unikniesz od razu problemu logowania typu „to wygląda jak staging” i oszczędzisz sobie późniejszej migracji domen, gdy firma już się rozwinie.
Chcesz instrukcje krok po kroku ze szczegółami rekordów DNS i tipami rozwiązywania problemów?
Zajrzyj do pełnego poradnika w dokumentacji: Niestandardowe domeny dla Logto Cloud.
