什麼是身份驗證自訂網域，以及為什麼多個網域很重要

如果你曾經為了趕上進度而快速發佈過產品，這故事肯定讓你感同身受。

你的應用程式安穩地運行在 example.com。行銷團隊跑各種活動，用戶不斷註冊，一切看起來都很完美。某天有個新用戶點了 登入。

接著，瀏覽器不是導向熟悉的網址如 auth.example.com，而是跳到類似測試環境的 my-tenant-123.app.logto

技術上沒問題，頁面很安全，登入也正常。
但用戶第一反應會是：

「等一下，我剛剛被導到哪了？」

就是短短一秒的疑惑，往往用戶就流失了。

• 從 轉換率 角度看，登入和註冊是轉換漏斗最窄的環節。只要多了一個「這網域是什麼？」的瞬間，就會增加摩擦。
• 從 安全性 角度來說，用戶長年被教育「要檢查網址」。如果登入網域與你的品牌不符，_看起來_就更像釣魚網站而非產品正式環境。

所以你會看到幾乎所有大公司都會用類似：

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

這可不是亂搞，因為登入網域就是產品體驗的一部分。

這篇文章會帶你了解：

• 什麼是 身份驗證自訂網域？
• 什麼情境下一個登入網域就夠？又什麼時候你應該規劃多個登入網域？
• 登入網域最常見的錯誤（如何避免「redirect URI 不符」的地獄）
• Logto 的自訂網域怎麼讓你免當 DNS 工程師也能優雅解決這一切

什麼是身份驗證自訂網域？#

我們簡單說明。

每個 Logto 租戶都會自帶一組預設的網域：{{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，等於我們要能接管你整個 DNS 區（包括現有的 A、MX、TXT 等記錄），這對多租戶 SaaS 根本不可行。

即使是 apex-flattening 記錄（ALIAS/ANAME），解析出來的還是我們無法控制的 IP，也無法配合我們管理的憑證。簡單說，託管登入頁必須設在子網域。把子網域用 CNAME 指到 Logto，之後我們就能幫你搞定驗證、SSL 憑證與線上率，而你的主網域還是保有其他用途。

為什麼不是「加個 CNAME 就搞定」？#

一個很常見的誤解：

「我 DNS 加個 CNAME 就好了吧？」

很遺憾，並不是。

改登入網域只是故事的一部分。你一旦加上自訂身份驗證網域，就會同時牽動到：

• 登入與註冊頁面 URL
  用戶現在是從 https://auth.example.com/... 存取託管頁面。

• OIDC/OAuth redirect URI
  應用程式與連接器必須在 redirect/callback 也使用同一網域，否則就會遇到 redirect_uri_mismatch 這類錯誤。

• 社交登入 & 企業 SSO（身分提供者）
  不論 Google、GitHub、Azure AD 或 Okta，都會檢查 redirect URI 或 ACS URL 包含的網域。

• Passkey（WebAuthn）
  Passkey 綁定在註冊時的網域。只要網域變了，這些 passkey 就馬上失效。

• SDK 設定
  你的 Logto SDK 會用一個 endpoint 指向租戶網域。如果 endpoint 網域不對，你的應用程式和身份層就會不同步。

所以，有沒有涉及 DNS？當然有。
但如果你只想著「加 CNAME 就好」的話，其他東西鐵定會壞掉。

快速建立概念：登入網域如何在整個系統裡流動#

想像下面這張圖，你的用戶瀏覽器從：

1. 瀏覽器網址列

   • 用戶在 https://example.com 點了 登入。
   • 之後被導向 https://auth.example.com/sign-in。

2. 授權伺服器與 discovery document

   • 應用程式從 OpenID 設定端點拿到：
     https://auth.example.com/oidc/.well-known/openid-configuration
   • 這告訴你的應用程式要去哪裡發送驗證請求、接收 token。

3. Redirect URI（OIDC/OAuth 回呼）

   • 用戶登入後 Logto redirect 回你的應用程式，例如：
     https://app.example.com/callback
   • 身分提供者和你的應用程式都必須同意這組網址。

4. 社交登入／企業 SSO 跳轉

   • 用戶從 auth.example.com 可能跳去 Google、Microsoft Entra ID、Okta 等等。
   • 這些平台也會檢查 redirect URI 是否帶有你自訂身份驗證網域。

5. Email 與魔法連結／重設密碼連結

   • 信件中的連結也要一律指向你的自訂網域，這樣用戶才不會困惑。

每一個步驟，都是「網域」的關鍵。一旦你導入自訂登入網域，就應該讓這個網域貫穿整個驗證與回呼流程。

所以說，一個完善的自訂網域策略其實不是玩 DNS 小技巧，而是打造一致的身份架構。

單一還是多個自訂網域？#

多數團隊用一組像 auth.example.com 的自訂網域就綽綽有餘了。但隨著你的產品、地區或客戶類型增加，不提前規劃就很容易卡關。

各種團隊常見的身份驗證網域規劃如下：

Logto 如何讓自訂網域變簡單？#

Logto 讓你直接用，不必成為 DNS 或 PKI 高手也能秒懂：

• 一個租戶，支援多網域。 不用複製租戶，也能把不同地區、環境、客戶或品牌對應到各自登入主機。開放的數量視方案而定，但主軸仍是一條身份主幹，多個對外入口。
• 預設網域還能用。 新增 auth.example.com 並不會關掉 {{tenant-id}}.app.logto。預設網域可繼續給內部工具或灰度上線使用，正是生產流量才導去品牌網域。
• 連接器自動調整。 SDK 會切到正確的 endpoint，社交與 SSO 連接器也會自動齊備每個網域可用的 redirect URI 或 ACS URL，完全不用手動搬網址。
• SSL 全自動。 你加完 CNAME 後，Logto 會自動驗證 DNS、申請 SSL 憑證並自動續期。完全不用煩惱金鑰、期效問題。

接下來怎麼做？#

看到這裡，大概你屬於下列其中一種：

已經在用 Logto？#

你可以立即開始玩多個自訂網域：

• 到 控制台 > 設定 > 網域。新增第二組自訂網域給即將上線的新地區，或是企業大客戶需求品牌專屬登入等情境。
• 記得在需用到的地方更新 SDK endpoint。
• 把社交或 SSO 連接器中，Logto 自動加上的 redirect URI 及 ACS URL 拿去填入身分提供者。

這樣就能馬上優化登入體驗，測試用戶信任感、轉換率提升。

還沒用過 Logto？#

剛上手時可以：

• 先 註冊 Logto 並建立一個租戶。
• 到 控制台 > 設定 > 網域。用免費自訂網域額度直接設好首個品牌登入域（如 auth.example.com）。
• 預設 {{tenant-id}}.app.logto 留作測試或內部用途更方便。

這樣你就不會遇到「看起來像測試環境」的登入網址，也不用等到成長期再費力調整麻煩的網域遷移。

想看逐步設定細節與 DNS 記錄、排錯方法？
直接讀我們的完整教學：Custom domains for Logto Cloud。