Polski
  • Niestandardowe domeny
  • Wiele domen
  • Uwierzytelnianie

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.

Ran
Ran
Product & 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.
Rozpocznij
Product screenshot

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.

Dlaczego subdomeny, a nie domeny główne?

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.

Dlaczego to nie „dodaję CNAME i gotowe”

Częsty mit:

„Dodam CNAME do DNS i po sprawie, prawda?”

Niestety, nie.

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:

  1. Pasek adresu przeglądarki

    • Użytkownik klika Zaloguj się na https://example.com.
    • Jest przekierowany na https://auth.example.com/sign-in.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Jedna a wiele niestandardowych domen

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:

ScenariuszPrzykładowe domenyDlaczego to pomaga
Jedno logowanie markiauth.example.com, account.example.comBrandujesz pasek adresu, zostawiając domyślne {{tenant-id}}.app.logto do testów.
Doświadczenia regionalneauth.us.example.com, auth.eu.example.com, auth.apac.example.comLokalizujesz treść, flowy zgód i komunikaty compliance dla regionu, w ramach jednego tenanta.
Środowiska testoweauth.staging.example.com, auth.example.comOddzielasz ruch QA i preview bez klonowania każdego tenanta czy konektora.
Branding per klientauth.customer-a.com, auth.customer-b.comOferujesz białe etykiety dużym klientom, zarządzając użytkownikami, organizacjami i SSO centralnie.
Linie produktów / spółekauth.shop.example.com, auth.app.example.com, auth.studio.example.comKażda marka ma spójne logowanie bez rozbijania stosu tożsamości.
Wiele TLDauth.foo.com, auth.foo.co.uk, auth.foo.devObsługujesz krajowe lub specjalne domeny bez powielania konfiguracji regionami.
Infrastruktura / routingauth.edge.example.com, auth.api.example.comSpójność z routingiem CDN/edge, podczas gdy tożsamość u Logto siedzi za tymi hostami.

Jak Logto ułatwia obsługę niestandardowych domen

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.

Co dalej?

Jeśli doczytałeś aż tu, prawdopodobnie jesteś w jednej z dwóch sytuacji.

Już korzystasz z Logto?

Możesz od razu zacząć testować wiele niestandardowych domen:

  • Wejdź na Konsolę > Ustawienia > Domeny. Dodaj drugą domenę np. dla nowego regionu albo dużego klienta chcącego własne logowanie po marce.
  • Zaktualizuj odpowiednio endpoint w SDK.
  • Dodaj widoczne przy domenie redirect URI i ACS, które podaje Logto w konektorach SSO/społecznościowych do swoich providerów tożsamości.

To łatwy sposób na lepsze doświadczenie logowania i test wpływu na zaufanie i konwersję użytkowników.

Dopiero zaczynasz przygodę z Logto?

Jeśli właśnie startujesz:

  • Zarejestruj się w Logto i utwórz tenanta.
  • 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.