เรียนรู้ว่าโดเมนแบบกำหนดเองสำหรับการยืนยันตัวตนและการใช้หลายโดเมนช่วยเพิ่มอัตราแปลง ความปลอดภัย และภาพลักษณ์แบรนด์ได้อย่างไร; และ Logto ช่วยให้คุณจัดการทุกอย่างได้โดยไม่ต้องปวดหัวกับ DNS
ถ้าคุณเคยปล่อยผลิตภัณฑ์ออกไปแบบเร่งด่วน เรื่องนี้จะรู้สึกคุ้นเคยมาก
แอปของคุณใช้ชีวิตอย่างมีความสุขที่ example.com ฝ่ายการตลาดกำลังโปรโมทแคมเปญ ผู้ใช้กำลังสมัครใช้งาน ทุกอย่างดูดีหมด จากนั้นผู้ใช้ใหม่กด เข้าสู่ระบบ
แทนที่จะเป็น URL ที่คุ้นเคยอย่าง auth.example.com เบราว์เซอร์กลับกระโดดไปที่บางอย่างที่ดูเหมือนสภาพแวดล้อมทดสอบ: my-tenant-123.app.logto
ในทางเทคนิค ไม่มีอะไรผิด หน้าเว็บนั้นปลอดภัย การเข้าสู่ระบบยังคงใช้งานได้
แต่ปฏิกิริยาแรกของผู้ใช้คือ:
“เดี๋ยวนะ เมื่อกี้ฉันถูกพาไปที่ไหน?”
เพียงแค่เสี้ยววินาทีของความสงสัยนี้เองที่ทำให้เกิดการหลุดจากขั้นตอนเข้าสู่ระบบ
นี่คือเหตุผลที่เกือบทุกบริษัทใหญ่เลือกใช้โดเมนเช่น:
login.company.comauth.company.comaccounts.company.comไม่ได้ทำเพราะสนุก แต่เพราะโดเมนสำหรับเข้าสู่ระบบเป็นส่วนหนึ่งของประสบการณ์สินค้า
ในบทความนี้เราจะเจาะลึกว่า:
อธิบายง่ายๆ เลย
ทุก tenant ใน Logto จะมาพร้อมกับโดเมนเริ่มต้น: {{tenant-id}}.app.logto หมายความว่าทุกครั้งที่ผู้ใช้ถูกเปลี่ยนไปหน้า: https://my-tenant-123.app.logto/sign-in
การใช้โดเมนแบบกำหนดเองสำหรับการยืนยันตัวตนจะเปลี่ยน URL ที่ผู้ใช้เห็น ให้เป็นของคุณเอง — เช่น auth.example.com ทีนี้ผู้ใช้จะเห็นแบรนด์ของคุณตลอดเวลา: https://auth.example.com/sign-in
บริการยืนยันตัวตนเหมือนเดิมทุกอย่าง เปลี่ยนแค่อิมเพรสชั่นแรกของผู้ใช้ที่ดีขึ้นมาก
สำหรับ Logto แล้ว โดเมนแบบกำหนดเองจะออกแบบให้ใช้กับ ซับโดเมน เช่น:
auth.example.comauth.us.example.comในทางปฏิบัติ นี่คือสิ่งที่คุณต้องการสำหรับ auth:
example.com).domains.logto.app เพื่อจัดการทราฟฟิกA, MX, TXT ฯลฯ) ซึ่งเป็นไปไม่ได้สำหรับ SaaS แบบ multi-tenantApex-flattening record (ALIAS/ANAME) ก็จะ resolve ไปที่ IP ที่เราไม่ได้เป็นเจ้าของ เลยไม่นำไปใช้กับ certificate ที่เราดูแลได้ สรุปคือ service sign-in ที่ Logto โฮสต์ไว้ต้องอยู่บนซับโดเมน ให้ CNAME ของซับโดเมนนั้นชี้มายัง Logto แล้วเราจัดการยืนยัน SSL และ uptime ให้ ส่วน root domain ก็ยังใช้โฮสต์ส่วนอื่นๆ ได้ตามปกติ
ความเข้าใจผิดที่พบบ่อยมาก:
“ก็แค่เพิ่ม 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 แล้วจบ” คุณเกือบจะแน่นอนว่าทำพังอย่างอื่นไปแล้ว
ลองจินตนาการถึงไดอะแกรม ที่เบราว์เซอร์ของผู้ใช้เริ่มจาก:
แถบที่อยู่ในเบราว์เซอร์
https://example.comhttps://auth.example.com/sign-inAuthorization server และ discovery document
https://auth.example.com/oidc/.well-known/openid-configurationRedirect URIs (OIDC/OAuth callbacks)
https://app.example.com/callbackSocial login / enterprise SSO hops
auth.example.com ผู้ใช้อาจจะถูกส่งต่อไปที่ Google, Microsoft Entra ID, Okta ฯลฯอีเมลและลิงก์ magic link / รีเซ็ตรหัสผ่าน
ทุกขั้นตอน โดเมนมีผลเสมอ ดังนั้นเมื่อคุณใช้ custom login domain ควรแน่ใจว่าใช้โดเมนนั้นสม่ำเสมอต่อเนื่องผ่านทั้ง chain
นี่จึงเป็นเหตุผลว่ากลยุทธ์ custom domain ที่ดีไม่ใช่เรื่องกลเม็ด DNS แต่เป็นเรื่อง identity design ที่สอดคล้องกันทั้งระบบ
สำหรับหลายทีม โดเมนเดียวเช่น auth.example.com อาจเพียงพอแล้ว แต่เมื่อตัวสินค้า พื้นที่ทางภูมิศาสตร์ ฐานลูกค้าเปลี่ยนแปลงไป คุณจะพบข้อจำกัดถ้าไม่วางแผนล่วงหน้า
นี่คือตัวอย่างว่าทีมแต่ละประเภทมักเชื่อมโยงโดเมนกับประสบการณ์ยืนยันตัวตนอย่างไร:
| สถานการณ์ | ตัวอย่างโดเมน | ทำไมมันถึงช่วยได้ |
|---|---|---|
| เข้าสู่ระบบแบบมีแบรนด์เดียว | auth.example.com, account.example.com | รักษา address bar ให้ตรงแบรนด์ ส่วนโดเมนเริ่มต้น {{tenant-id}}.app.logto ไว้ใช้สำหรับทดสอบต่อได้ |
| ประสบการณ์แบบแต่ละภูมิภาค | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | ปรับแต่งเนื้อหา กระบวนการยินยอม และการแสดง compliance ตามภูมิศาสตร์ได้ใน tenant เดียว |
| สิ่งแวดล้อมแบบ staging | auth.staging.example.com, auth.example.com | แยก traffic QA กับ preview ออกจาก production ได้ โดยไม่ต้องโคลน tenant หรือ connector ทั้งหมด |
| white label ต่อองค์กร | auth.customer-a.com, auth.customer-b.com | ให้ลูกค้าองค์กรเข้าใช้งานแบรนด์ตัวเอง พร้อมจัดการผู้ใช้ องค์กร และ SSO แบบรวมศูนย์ |
| แต่ละแบรนด์หรือสายผลิตภัณฑ์ | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | สร้างประสบการณ์ login สำหรับแต่ละแบรนด์แบบครบถ้วน โดยไม่ทำให้ระบบ identity ป่วน |
| หลาย TLD | auth.foo.com, auth.foo.co.uk, auth.foo.dev | รองรับ country site หรือโดเมนเฉพาะวัตถุประสงค์ โดยไม่ต้อง replicate การตั้งค่าไปแต่ละภูมิภาค |
| ขับเคลื่อนด้วย infrastructure | auth.edge.example.com, auth.api.example.com | สอดรับกับกฎ CDN หรือ edge routing โดยมี Logto เป็น identity backend หลัง host เหล่านั้น |
นี่คือสิ่งที่ Logto ให้คุณฟรีๆ ไม่ต้องเป็นผู้เชี่ยวชาญ DNS หรือ PKI ก่อน
auth.example.com ไม่กระทบ {{tenant-id}}.app.logto จะใช้ตัวเริ่มต้นสำหรับเครื่องมือภายในหรือทดสอบก่อนปล่อย production ก็ได้ถ้าอ่านมาถึงตรงนี้ คุณน่าจะอยู่ในสองกลุ่มนี้
คุณสามารถทดลองใช้ custom domain หลายโดเมนได้ทันที:
endpoint ตามความเหมาะสมนี่คือวิธีง่ายๆ ที่จะปรับประสบการณ์ login และทดสอบว่ามีผลต่อความเชื่อมั่นผู้ใช้อย่างไร
หากคุณเพิ่งเริ่มต้น:
auth.example.com เป็นหน้า login สาธารณะตั้งแต่วันแรก{{tenant-id}}.app.logto ไว้สำหรับใช้ภายในหรือทดสอบคุณจะหลีกเลี่ยงปัญหา “URL นี้ดูเหมือน staging” และไม่ต้องปวดหัวเปลี่ยนโดเมนทีหลังในตอนที่กำลังโต
อยากได้รายละเอียดการติดตั้งอย่างละเอียดยิบทั้ง DNS และปัญหาที่พบบ่อย?
ดูคู่มือเต็มๆ ได้ในเอกสารของเรา: Custom domains สำหรับ Logto Cloud