繁體中文(香港)
  • 自訂網域
  • 多網域
  • 認證

什麼是認證自訂網域,以及為什麼多個網域很重要

了解認證自訂網域及多網域如何提升轉換率、安全性與品牌形象;以及 Logto 如何讓你輕鬆管理它們,無需為 DNS 操心。

Ran
Ran
Product & Design

Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
Get started
Product screenshot

如果你曾因為趕著推出產品而略過了一些細節,這個故事你一定感同身受。

你的應用程式安穩地掛在 example.com 下。行銷團隊開跑推廣,使用者註冊帳號,一切看起來都很完美。然後有新用戶點了 登入

結果瀏覽器沒有導向大家熟悉的網址,例如 auth.example.com ,而是跳去了看起來像測試環境的 my-tenant-123.app.logto

技術上沒問題,網頁依然安全,登入也正常運作。 但用戶第一反應會是:

「等下,我現在去哪了?」

這一秒鐘的疑惑,決定了流失率。

  • 轉換 的角度來說,登入和註冊是你轉換漏斗中最狹窄的環節。任何「這是哪個網域?」的片刻猶豫都增加摩擦。
  • 安全性 的角度來說,這些年用戶一直被教育 「檢查網址列」。如果登入網域跟品牌不符,整體 看起來 更像釣魚網站,而不是正式產品。

這也是為什麼幾乎每間大公司都會這樣設計:

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

他們可不是跟風,這是因為登入網域就是產品體驗的一部份。

這篇文章會跟你聊:

  • 到底什麼是 認證自訂網域
  • 什麼時候用 一個 登入網域就夠 —— 又何時該考慮 多個
  • 設定登入網域時常見的錯誤(以及如何避免「redirect URI does not match」煉獄)
  • Logto 如何讓你輕鬆搞定網域,不用變成專職 DNS 工程師

什麼是認證自訂網域?

簡單說明一下。

每個 Logto tenant 都會配一個預設網域:{{tenant-id}}.app.logto。所以原本用戶進入的是這種網址:https://my-tenant-123.app.logto/sign-in

設定認證自訂網域,就是把明顯可見的網址換成你自己的 —— 比方 auth.example.com。登錄頁就變成:https://auth.example.com/sign-in,保持全程在你品牌形象下。

底層還是同一組認證服務,外觀與第一印象完全不同。

為什麼用子網域,不是根網域?

在 Logto 裡,自訂網域設計就是要用 子網域,像這樣:

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

實務上,這樣設定認證才是正常需求:

  • 根網域通常保留給官網(example.com)。
  • DNS "zone apex" 不支援 CNAME,而 Logto 的雲端登入需要透過 CNAME 指向 domains.logto.app 才能正確流量導向。
  • Logto 透過 Cloudflare 管證書。想對根網域終結 TLS,就必須控制整個區域(包含你原本設定的 AMXTXT 等記錄),這對 SaaS 這種多租戶方案來說根本不可行。

頂層平坦(Apex-flattening,像 ALIAS/ANAME)雖然可以指到我們外部的 IP,但還是不能用來自動管理證書。簡單說,託管登入頁一定要掛在子網域下。你只要用 CNAME 把該子網域指去 Logto,剩下的驗證、SSL、服務可用率全部我們幫你搞定 —— 你的主網域能繼續服務其他用途。

為什麼不是「加個 CNAME 就結束」?

一個很常見的誤會:

「我只要加個 CNAME 就完成了,對吧?」

其實沒那麼單純。

你能看到的登入網域,僅僅是故事的開頭。一旦導入自訂認證網域,你馬上會影響到:

  • 登入及註冊頁網址
    用戶現在造訪的是 https://auth.example.com/... 這些託管頁面。

  • OIDC / OAuth redirect URIs
    你的 App 及所有連接器,都必須用這個自訂網域當作 redirect/callback URL,不然就會遇到 redirect_uri_mismatch 這類錯誤。

  • 社群登入及企業 SSO(IdPs)
    Google、GitHub、Azure AD、Okta 等等,都會嚴格檢查 redirect URI 或 ACS URL,各種網域要完全吻合。

  • Passkey(WebAuthn) Passkey(通行密鑰)嚴格綁定註冊時的網域。網域換了,先前的 passkey 就不能用了。

  • SDK 配置
    你的 Logto SDK 端點要正確指向 tenant 網域。如果用到錯網域,應用與身份層就有可能不同步。

所以 DNS 當然是有涉及, 但只停留在「加了 CNAME 就完成」的思維,九成機會會搞壞其他功能。

快速腦內模型:登入網域如何貫串全流程

想像一個流程圖,使用者瀏覽器從這裡開始:

  1. 瀏覽器網址列

    • 用戶在 https://example.com 按下 登入
    • 跳去 https://auth.example.com/sign-in
  2. 認證伺服器與 Discovery 文件

    • 你的 App 透過 OpenID 設定端點:
      https://auth.example.com/oidc/.well-known/openid-configuration
    • 這裡告訴 App 要送哪裡、預期 Token 從哪領回來。
  3. Redirect URI(OIDC/OAuth 回呼)

    • 用戶成功登入後,Logto 轉回你的 App,例如
      https://app.example.com/callback
    • IdP 跟你的程式都必須認可這批網址。
  4. 社群登入 / 企業 SSO 跳轉

    • 用戶從 auth.example.com 跳去 Google、Microsoft Entra ID、Okta 等。
    • 這些登入方都會驗證包含自訂網域的 redirect URI。
  5. 郵件及魔術連結 / 密碼重設連結

    • 郵件裡的連結都要一致指向自訂網域,才不會讓用戶困惑。

這幾步驟,每一環「網域」都很關鍵。導入自訂登入網域時,你想讓它貫穿全流程且保持一致。

所以一套成熟的網域策略,重點不是玩 DNS 技巧,而是要有一套一致的身分識別設計架構。

一個 vs. 多個自訂網域

對多數團隊來說,一個像 auth.example.com 這種通用網域完全沒問題。但隨著產品規模、地區、客群成長,如果沒預先設計「多網域」彈性很快就會撞牆。

下面是不同團隊常見的身分驗證網域對應方式:

情境範例網域幫助說明
品牌統一登入auth.example.comaccount.example.com用戶看到的網址始終品牌一致,預設 {{tenant-id}}.app.logto 網域保留給內部測試。
各地區專屬體驗auth.us.example.comauth.eu.example.comauth.apac.example.com一個 tenant 裡可依地區區分本地化內容、合規條款及同意流程。
環境隔離auth.staging.example.comauth.example.com測試或預覽流量可明確隔絕,無須複製 tenant 或連接器。
客製化企業品牌入口auth.customer-a.comauth.customer-b.com大客戶可以專屬登入,仍集中控管所有用戶、組織、SSO,不需後台分割。
產品品牌 / 產品線auth.shop.example.comauth.app.example.comauth.studio.example.com各子品牌各自有一致登入體驗,身份架構不分散。
多 TLD(國碼等)auth.foo.comauth.foo.co.ukauth.foo.dev各國版或特殊用途網域一併支援,設定一次無須層層複製。
基礎設施導向auth.edge.example.comauth.api.example.com可配合 CDN/Edge 路由,有多登入入口,Logto 還是一條身分主線作 backend。

Logto 如何簡化自訂網域

Logto out-of-the-box 給你的,讓你免當 DNS 或 PKI 專家:

  • 一個 tenant,多個網域。 可以依地區、環境、客戶、品牌分配獨立登入入口,無需複製 tenant(會有方案上限,但原則是一條身份主線,多入口)。
  • 預設網域不會消失。 加入了 auth.example.com 也不會移除 {{tenant-id}}.app.logto,預設網域還能做內部測試或灰度發佈,正式用戶走品牌專屬網址。
  • 連接器自動配置調整。 SDK 會指向對應的 endpoint,社群/SSO 連接器則自動配置每個有效的 redirect URI、ACS URL,無須人工拚網址。
  • SSL 全自動。 你加好 CNAME,Logto 會驗證 DNS、簽證書、持續自動續期。不用管金鑰存放、不怕證書過期出包。

下一步怎麼走

看到這裡,大概只剩這兩種狀況:

已經在用 Logto?

你隨時可以直接嘗試多個自訂網域:

  • 前往 主控台 > 設定 > 網域。新增一組自訂網域,無論是新地區上線還是大客戶獨立品牌登入都能馬上實現。
  • 按需求調整 SDK 的 endpoint 設定。
  • 把 Logto 在社群/SSO 連接器中提供的多網域 redirect URI 及 ACS URL,貼到你的各認證服務。

這是優化用戶體驗、觀察信任度及轉換影響的最快方式。

還沒開始用 Logto?

如果你現在正打算剛起步:

  • 立即註冊 Logto 並建立一個 tenant。
  • 進到 主控台 > 設定 > 網域。用免費配額直接把 auth.example.com 設成對外的登入主網域。
  • 保留預設 {{tenant-id}}.app.logto 網域,可以做內部測試或開發用途。

這樣完全不會有「這網址好像 staging」的突兀體驗,等你成長更快的時候也不用費心解 domain 遷移。

需要全套設定教學,包括 DNS 紀錄、排除障礙、一步步操作? 請看我們文件的詳細指南:自訂網域(Logto Cloud)