โดเมนแบบกำหนดเองสำหรับการยืนยันตัวตนคืออะไร และเหตุใดโดเมนหลายโดเมนจึงสำคัญ

ถ้าคุณเคยปล่อยผลิตภัณฑ์ออกไปแบบเร่งด่วน เรื่องนี้จะรู้สึกคุ้นเคยมาก

แอปของคุณใช้ชีวิตอย่างมีความสุขที่ example.com ฝ่ายการตลาดกำลังโปรโมทแคมเปญ ผู้ใช้กำลังสมัครใช้งาน ทุกอย่างดูดีหมด จากนั้นผู้ใช้ใหม่กด เข้าสู่ระบบ

แทนที่จะเป็น URL ที่คุ้นเคยอย่าง auth.example.com เบราว์เซอร์กลับกระโดดไปที่บางอย่างที่ดูเหมือนสภาพแวดล้อมทดสอบ: my-tenant-123.app.logto

ในทางเทคนิค ไม่มีอะไรผิด หน้าเว็บนั้นปลอดภัย การเข้าสู่ระบบยังคงใช้งานได้
แต่ปฏิกิริยาแรกของผู้ใช้คือ:

“เดี๋ยวนะ เมื่อกี้ฉันถูกพาไปที่ไหน?”

เพียงแค่เสี้ยววินาทีของความสงสัยนี้เองที่ทำให้เกิดการหลุดจากขั้นตอนเข้าสู่ระบบ

• จากมุมมองด้าน การแปลงผู้ใช้ จุดเข้าสู่ระบบและลงทะเบียนเป็นคอขวดที่สุดของกระบวนการ ใครๆ ก็จะลังเลถ้ามีอารมณ์แบบ “นี่โดเมนอะไร?” เข้ามา
• จากมุมมองด้าน ความปลอดภัย ผู้ใช้ถูกสอนให้ “ตรวจสอบ URL” มาหลายปี ถ้าโดเมนสำหรับเข้าสู่ระบบไม่ใช่แบรนด์ของคุณ มันก็ดูเหมือนการหลอกลวง (phishing) มากกว่าระบบจริงอีก

นี่คือเหตุผลที่เกือบทุกบริษัทใหญ่เลือกใช้โดเมนเช่น:

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

ไม่ได้ทำเพราะสนุก แต่เพราะโดเมนสำหรับเข้าสู่ระบบเป็นส่วนหนึ่งของประสบการณ์สินค้า

ในบทความนี้เราจะเจาะลึกว่า:

• โดเมนยืนยันตัวตนแบบกำหนดเอง จริง ๆ แล้วคืออะไร
• เมื่อไหร่ หนึ่ง โดเมนก็พอ — และเมื่อไหร่ควรเตรียมพร้อมรับมือ หลายโดเมน
• ข้อผิดพลาดที่พบบ่อยของโดเมนเข้าสู่ระบบ (รวมถึงวิธีหลีกเลี่ยง "redirect URI does not match" อาถรรพ์)
• Logto มีฟีเจอร์ custom domain ที่ช่วยให้คุณทำทุกอย่างนี้ได้ โดยไม่ต้องกลายเป็นวิศวกร DNS เต็มตัว อย่างไร

โดเมนสำหรับการยืนยันตัวตนแบบกำหนดเองคืออะไร?#

อธิบายง่ายๆ เลย

ทุก tenant ใน Logto จะมาพร้อมกับโดเมนเริ่มต้น: {{tenant-id}}.app.logto หมายความว่าทุกครั้งที่ผู้ใช้ถูกเปลี่ยนไปหน้า: https://my-tenant-123.app.logto/sign-in

การใช้โดเมนแบบกำหนดเองสำหรับการยืนยันตัวตนจะเปลี่ยน URL ที่ผู้ใช้เห็น ให้เป็นของคุณเอง — เช่น auth.example.com ทีนี้ผู้ใช้จะเห็นแบรนด์ของคุณตลอดเวลา: https://auth.example.com/sign-in

บริการยืนยันตัวตนเหมือนเดิมทุกอย่าง เปลี่ยนแค่อิมเพรสชั่นแรกของผู้ใช้ที่ดีขึ้นมาก

ทำไมถึงต้องใช้ subdomain ไม่ใช่ root domain?#

สำหรับ Logto แล้ว โดเมนแบบกำหนดเองจะออกแบบให้ใช้กับ ซับโดเมน เช่น:

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

ในทางปฏิบัติ นี่คือสิ่งที่คุณต้องการสำหรับ auth:

• โดเมนหลักมักจะไว้สำหรับเว็บหลัก (example.com).
• DNS "zone apex" ไม่สามารถใช้ CNAME ได้ และหน้า sign-in ที่ Logto โฮสต์ไว้ ต้องการ CNAME ชี้ไปที่ domains.logto.app เพื่อจัดการทราฟฟิก
• Logto จัดการ certificate ผ่าน Cloudflare ถ้าเราต้องทำ TLS บน root domain เราต้องควบคุม zone ทั้งหมด (รวมทั้ง A, MX, TXT ฯลฯ) ซึ่งเป็นไปไม่ได้สำหรับ SaaS แบบ multi-tenant

Apex-flattening record (ALIAS/ANAME) ก็จะ resolve ไปที่ IP ที่เราไม่ได้เป็นเจ้าของ เลยไม่นำไปใช้กับ certificate ที่เราดูแลได้ สรุปคือ service sign-in ที่ Logto โฮสต์ไว้ต้องอยู่บนซับโดเมน ให้ CNAME ของซับโดเมนนั้นชี้มายัง Logto แล้วเราจัดการยืนยัน SSL และ uptime ให้ ส่วน root domain ก็ยังใช้โฮสต์ส่วนอื่นๆ ได้ตามปกติ

ทำไมมันไม่ใช่แค่ “เพิ่ม CNAME ก็จบ”#

ความเข้าใจผิดที่พบบ่อยมาก:

“ก็แค่เพิ่ม CNAME ใน DNS แล้วจบใช่มั้ย?”

น่าเสียดายที่ไม่ใช่

การเปลี่ยนโดเมนเข้าสู่ระบบที่ผู้ใช้เห็นเป็นแค่หนึ่งส่วนเท่านั้น เมื่อคุณใช้โดเมนยืนยันตัวตนแบบกำหนดเอง จะเกี่ยวข้องกับ:

• URL หน้า sign-in และหน้าลงทะเบียน
  ผู้ใช้จะเข้าที่ https://auth.example.com/... สำหรับหน้าเหล่านี้

• OIDC / OAuth redirect URIs
  แอปและคอนเน็กเตอร์ของคุณต้องใช้โดเมนเดียวกันใน redirect/callback URL ไม่งั้นจะขึ้นข้อผิดพลาดแบบ redirect_uri_mismatch

• Social logins & enterprise SSO (IdP)
  Google, GitHub, Azure AD, Okta ฯลฯ ล้วนตรวจสอบ redirect URI หรือ ACS URL โดยรวมโดเมนไปด้วย

• Passkeys (WebAuthn)
  Passkey ผูกกับโดเมนแบบเป๊ะๆ ถ้าเปลี่ยนโดเมน passkey ที่เคยสมัครไว้จะใช้ไม่ได้อีก

• SDK configuration
  SDK ของ Logto ใช้ endpoint ที่ชี้ไปยังโดเมนของ tenant ถ้า endpoint ไม่ตรงกัน ชั้น identity กับแอปจะ sync กันไม่ได้

DNS มีส่วนแน่ๆ
แต่ถ้าคิดแค่ว่า “ฉันเพิ่ม CNAME แล้วจบ” คุณเกือบจะแน่นอนว่าทำพังอย่างอื่นไปแล้ว

โมเดลคิดคร่าวๆ: โดเมนล็อกอินไหลผ่าน stack อย่างไร#

ลองจินตนาการถึงไดอะแกรม ที่เบราว์เซอร์ของผู้ใช้เริ่มจาก:

1. แถบที่อยู่ในเบราว์เซอร์

   • ผู้ใช้คลิก Sign in ที่ https://example.com
   • ระบบ redirect ไปที่ https://auth.example.com/sign-in

2. Authorization server และ discovery document

   • แอปของคุณใช้ OpenID configuration endpoint ที่:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • Endpoint นี้จะบอกแอปของคุณว่าให้ยิงคำขอ auth และรับ token ที่ไหน

3. Redirect URIs (OIDC/OAuth callbacks)

   • หลังจาก sign in เสร็จ Logto จะ redirect กลับไปแอปของคุณที่:
     https://app.example.com/callback
   • ทั้ง IdP และแอปของคุณต้องเห็นพ้องตรงกันใน URL เหล่านี้

4. Social login / enterprise SSO hops

   • จาก auth.example.com ผู้ใช้อาจจะถูกส่งต่อไปที่ Google, Microsoft Entra ID, Okta ฯลฯ
   • ผู้ให้บริการเหล่านั้นก็จะเห็นและ validate redirect URI ที่รวม custom auth domain ของคุณเช่นกัน

5. อีเมลและลิงก์ magic link / รีเซ็ตรหัสผ่าน

   • ลิงก์ในอีเมลควรพาไปโดเมนที่ตรงกันตลอด เพื่อไม่ให้ผู้ใช้สับสน

ทุกขั้นตอน โดเมนมีผลเสมอ ดังนั้นเมื่อคุณใช้ custom login domain ควรแน่ใจว่าใช้โดเมนนั้นสม่ำเสมอต่อเนื่องผ่านทั้ง chain

นี่จึงเป็นเหตุผลว่ากลยุทธ์ custom domain ที่ดีไม่ใช่เรื่องกลเม็ด DNS แต่เป็นเรื่อง identity design ที่สอดคล้องกันทั้งระบบ

โดเมนเดียว หรือหลายโดเมนดี?#

สำหรับหลายทีม โดเมนเดียวเช่น auth.example.com อาจเพียงพอแล้ว แต่เมื่อตัวสินค้า พื้นที่ทางภูมิศาสตร์ ฐานลูกค้าเปลี่ยนแปลงไป คุณจะพบข้อจำกัดถ้าไม่วางแผนล่วงหน้า

นี่คือตัวอย่างว่าทีมแต่ละประเภทมักเชื่อมโยงโดเมนกับประสบการณ์ยืนยันตัวตนอย่างไร:

Logto ทำให้ custom domain ง่ายอย่างไร#

นี่คือสิ่งที่ Logto ให้คุณฟรีๆ ไม่ต้องเป็นผู้เชี่ยวชาญ DNS หรือ PKI ก่อน

• หนึ่ง tenant หลายโดเมน จัดแม็พ region, environment, customer หรือ brand ให้มี login host ของตัวเอง โดยไม่ต้องโคลน tenant แผนแต่ละแบบมีขีดจำกัด แต่สัญญาณหลักคือ โครงสร้าง identity เดียว มีหลายจุดเข้าได้
• โดเมนเริ่มต้นยังใช้งานได้ การเพิ่ม auth.example.com ไม่กระทบ {{tenant-id}}.app.logto จะใช้ตัวเริ่มต้นสำหรับเครื่องมือภายในหรือทดสอบก่อนปล่อย production ก็ได้
• Connector ปรับอัตโนมัติ SDK ชี้ endpoint ที่ถูกต้อง Connector สำคัญทั้งหมดใส่ redirect URI หรือ ACS URL ทุกโดเมนให้เลย — ไม่ต้องสลับ URL เอง
• SSL อัตโนมัติ แค่เพิ่ม CNAME แล้ว Logto จะยืนยัน DNS, ออก certificate และดูแลการต่ออายุหมด ไม่ต้องบริหารคีย์ ไม่ต้องกลัวหมดอายุไม่รู้ตัว

แล้วต่อไปล่ะ?#

ถ้าอ่านมาถึงตรงนี้ คุณน่าจะอยู่ในสองกลุ่มนี้

ใช้ Logto อยู่แล้ว?#

คุณสามารถทดลองใช้ custom domain หลายโดเมนได้ทันที:

• ไปที่ Console > Settings > Domains เพิ่มโดเมนใหม่ เช่นสำหรับภูมิภาคใหม่หรือลูกค้าองค์กรที่ต้องการแบรนด์ตัวเอง
• อัปเดต SDK endpoint ตามความเหมาะสม
• ใช้ redirect URI และ ACS URL ที่ Logto ให้ใน Social หรือ SSO connector กับ identity provider ของคุณ

นี่คือวิธีง่ายๆ ที่จะปรับประสบการณ์ login และทดสอบว่ามีผลต่อความเชื่อมั่นผู้ใช้อย่างไร

เพิ่งเริ่มใช้ Logto?#

หากคุณเพิ่งเริ่มต้น:

• สมัครสมาชิก Logto และสร้าง tenant ของคุณเอง
• ไปที่ Console > Settings > Domains ใช้สิทธิ์ custom domain ฟรี ตั้ง auth.example.com เป็นหน้า login สาธารณะตั้งแต่วันแรก
• เก็บ {{tenant-id}}.app.logto ไว้สำหรับใช้ภายในหรือทดสอบ

คุณจะหลีกเลี่ยงปัญหา “URL นี้ดูเหมือน staging” และไม่ต้องปวดหัวเปลี่ยนโดเมนทีหลังในตอนที่กำลังโต

อยากได้รายละเอียดการติดตั้งอย่างละเอียดยิบทั้ง DNS และปัญหาที่พบบ่อย?
ดูคู่มือเต็มๆ ได้ในเอกสารของเรา: Custom domains สำหรับ Logto Cloud