تعرّف كيف أن نطاقات المصادقة المخصصة والنطاقات المتعددة تحسّن معدل التحويل والأمان وتعزز علامتك التجارية؛ وكيف يساعدك Logto على إدارتها دون متاعب إعدادات DNS.
إذا كنت قد أطلقت منتجًا بسرعة كبيرة من قبل، ستجد هذه القصة مألوفة.
تعيش تطبيقك بسعادة على example.com. يدير التسويق الحملات، المستخدمون يسجلون الدخول، كل شيء يبدو متقنًا. ثم ينقر مستخدم جديد على تسجيل الدخول.
بدلاً من عنوان URL المألوف مثل auth.example.com، ينتقل المتصفح إلى شيء يبدو وكأنه بيئة اختبار: my-tenant-123.app.logto
من الناحية التقنية، لا يوجد خطأ. الصفحة آمنة. لا يزال تسجيل الدخول يعمل.
لكن ردة فعل المستخدم الأولى هي:
"انتظر، إلى أين انتقلت للتو؟"
تلك الثانية الواحدة من الشك هي اللحظة التي تحدث فيها حالات الانسحاب.
لهذا السبب تستخدم كل شركة كبيرة تقريبًا صيغة من أشكال:
login.company.comauth.company.comaccounts.company.comهم لا يفعلون ذلك من باب التسلية، بل لأن نطاق تسجيل الدخول جزء من تجربة المنتج.
في هذا المقال، سنتناول:
لنُبقي الأمر بسيطًا.
كل مستأجر 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عمليًا، هذا هو المناسب للمصادقة أصلًا:
example.com).domains.logto.app لتوجيه الترافيك.A، وMX، وTXT، وغيرها)، وهذا غير ممكن مع SaaS متعدد المستأجرين.سجلات "تسطيح الذروة" (ALIAS/ANAME) لا تزال تُحل لعناوين IP لا نملكها، إذًا لا يمكنها دعم شهاداتنا المدارة. باختصار، تسجيل الدخول المستضاف يجب أن يكون في نطاق فرعي. وجه ذلك النطاق الفرعي إلى Logto بواسطة CNAME وسنقوم بمهمة التحقق، والـ SSL، وضمان الاستمرارية — ويبقى نطاقك الجذري حرًا لخدمة بقية موقعك.
مفهوم خاطئ شائع جدًا:
"سأضيف CNAME إلى DNS وانتهى الأمر، صحيح؟"
للأسف، لا.
تغيير نطاق تسجيل الدخول الظاهر هو جزء واحد فقط من القصة. عندما تقدم نطاق مصادقة مخصص، فإنك تؤثر على:
رابط صفحة تسجيل الدخول والتسجيل
حيث يزور المستخدمون الآن https://auth.example.com/... للصفحات المستضافة.
عناوين إعادة التوجيه OIDC / OAuth
يجب أن تستخدم تطبيقاتك ووصلاتك نفس النطاق في عناوين إعادة التوجيه أو الاسترجاع، وإلا ستحصل على أخطاء مثل redirect_uri_mismatch.
تسجيلات الدخول الاجتماعية وSSO المؤسساتي (IdPs)
Google و GitHub و Azure AD و Okta...الخ، يتحقق كلٌ منهم من عناوين إعادة التوجيه أو ACS التي تحتوي على النطاق.
مفاتيح المرور (WebAuthn)
ترتبط مفاتيح المرور بالنطاق الذي تم تسجيلها فيه بالضبط. إذا تغير النطاق، سوف تتعطل تلك المفاتيح.
تهيئة الـ SDK
تستخدم حزم Logto SDK متغير endpoint يشير إلى نطاق المستأجر. إذا استخدمت نقطة نهاية خاطئة، سينفصل تطبيقك عن طبقة الهوية.
إذًا، هل هناك إعدادات DNS؟ قطعًا.
لكن إذا فكرت فقط وفق مبدأ "أضفت CNAME إذا انتهيت"، فستكسر غالبًا جانبًا آخر.
تخيل رسمًا بيانيًا يبدأ فيه متصفح المستخدم بـ:
شريط عناوين المتصفح
https://example.com.https://auth.example.com/sign-in.خادم التفويض ووثيقة الاكتشاف
https://auth.example.com/oidc/.well-known/openid-configurationعناوين إعادة التوجيه (استدعاءات OIDC/OAuth)
https://app.example.com/callbackتسجيل الدخول الاجتماعي / خطوات SSO المؤسساتي
auth.example.com، قد ينتقل المستخدم إلى Google أو Microsoft Entra ID أو Okta ...الخ.الروابط في البريد الإلكتروني وروابط السحر/إعادة تعيين كلمة المرور
في كل خطوة من هذه الخطوات، النطاق مهم. عندما تقدم نطاق تسجيل دخول مخصص، تريده أن يتدفق عبر السلسلة بالكامل بطريقة متماسكة.
لهذا السبب، الاستراتيجية المدروسة للنطاقات المخصصة لا تدور حول حيل DNS بل حول تصميم هوية متسق.
بالنسبة للكثير من الفرق، يكفي نطاق مخصص واحد مثل auth.example.com. لكن مع توسع منتجك وجغرافيتك وقاعدة عملائك، ستواجه حدودًا بسرعة إذا لم تُخطط مسبقًا.
إليك كيف ترسم الفرق المختلفة عادة النطاقات على تجاربها في المصادقة:
| السيناريو | أمثلة للنطاقات | كيف يفيدك |
|---|---|---|
| تسجيل دخول موحد بعلامة تجارية واحدة | auth.example.com، account.example.com | يحافظ على شريط العنوان مع علامتك التجارية، بينما يبقى النطاق الافتراضي {{tenant-id}}.app.logto متاحًا للاختبار. |
| تجارب حسب المنطقة | auth.us.example.com، auth.eu.example.com، auth.apac.example.com | تتيح لك تخصيص المحتوى وتدفقات الموافقة والإشعارات حسب المنطقة داخل مستأجر واحد. |
| حواجز بيئية | auth.staging.example.com، auth.example.com | عزل حركة المرور الخاصة بالاختبار والجودة دون نسخ كل مستأجر أو موصل. |
| علامة لكل مؤسسة | auth.customer-a.com، auth.customer-b.com | تقدم نقاط دخول بهوية بيضاء للعلامة التجارية لعملاء الشركات مع إدارة المستخدمين والمؤسسات وSSO مركزيًا. |
| خط علامة تجارية أو منتج | auth.shop.example.com، auth.app.example.com، auth.studio.example.com | منح كل علامة تجربة دخول موحدة دون تجزئة هوية النظام. |
| نطاقات TLD متعددة | auth.foo.com، auth.foo.co.uk، auth.foo.dev | دعم مواقع البلدان أو النطاقات الخاصة دون تكرار الإعداد منطقة بمنطقة. |
| بدافع البنية التحتية | auth.edge.example.com، auth.api.example.com | التوافق مع سياسات CDN أو نقاط الحافة، بينما يبقى Logto هوية الخلفية خلف تلك المضيفات. |
إليك ما يوفره لك Logto مباشرة، دون الحاجة لأن تصبح مختص DNS أو PKI.
auth.example.com لا تلغي {{tenant-id}}.app.logto. استخدم الافتراضي للأدوات الداخلية أو للتدرج في النشر، بينما يزور مستخدمي الإنتاج النطاق ذي العلامة التجارية.endpoint الصحيح، بينما تعرض توصيلات الدخول الاجتماعي والمؤسساتي كل عنوان إعادة توجيه أو عنوان ACS صالح لكل نطاق—لا حاجة للتلاعب يدويًا بالروابط.إذا كنت قد قرأت حتى هنا، فأنت على الأرجح في أحد معسكرين.
يمكنك البدء بتجربة النطاقات المخصصة المتعددة فورًا:
endpoint في حزمة SDK عند الحاجة.إنها طريقة سهلة لتحسين تجربة تسجيل الدخول واختبار الأثر على ثقة المستخدمين ومعدل التحويل.
إذا كنت تبدأ للتو:
auth.example.com كنطاق تسجيل دخول علني من اليوم الأول.{{tenant-id}}.app.logto متاحًا للاستخدام الداخلي أو الاختبار.بهذا ستتجنب تمامًا مشكلة عنوان تسجيل الدخول الذي يبدو أنه بيئة اختبار، ولن تحتاج لاحقًا إلى تفكيك هجرة نطاقات معقدة بعد دخولك مرحلة النمو.
تريد التفاصيل خطوة بخطوة، بما في ذلك سجلات DNS وحل المشاكل؟
اطلع على الدليل الكامل في وثائقنا: النطاقات المخصصة لـ Logto Cloud.