ما هو نطاق المصادقة المخصص ولماذا تهم النطاقات المتعددة

إذا كنت قد أطلقت منتجًا بسرعة كبيرة من قبل، ستجد هذه القصة مألوفة.

تعيش تطبيقك بسعادة على example.com. يدير التسويق الحملات، المستخدمون يسجلون الدخول، كل شيء يبدو متقنًا. ثم ينقر مستخدم جديد على تسجيل الدخول.

بدلاً من عنوان URL المألوف مثل auth.example.com، ينتقل المتصفح إلى شيء يبدو وكأنه بيئة اختبار: my-tenant-123.app.logto

من الناحية التقنية، لا يوجد خطأ. الصفحة آمنة. لا يزال تسجيل الدخول يعمل.
لكن ردة فعل المستخدم الأولى هي:

"انتظر، إلى أين انتقلت للتو؟"

تلك الثانية الواحدة من الشك هي اللحظة التي تحدث فيها حالات الانسحاب.

• من وجهة نظر التحويل، تسجيل الدخول والتسجيل هما أضيق نقطة في قمعك، وأي لحظة زائدة من "ما هو هذا النطاق؟" تخلق احتكاكًا.
• من منظور الأمان، تم إخبار المستخدمين لسنوات "تحقق من عنوان الرابط (URL)". إذا لم يتطابق نطاق تسجيل الدخول مع علامتك التجارية، فإنه يبدو أكثر شُبهة تصيد من الإنتاج الفعلي.

لهذا السبب تستخدم كل شركة كبيرة تقريبًا صيغة من أشكال:

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

هم لا يفعلون ذلك من باب التسلية، بل لأن نطاق تسجيل الدخول جزء من تجربة المنتج.

في هذا المقال، سنتناول:

• ما هو نطاق المصادقة المخصص حقًا
• متى يكون نطاق تسجيل دخول واحد كافيًا — ومتى يجب أن تخطط لوجود متعدد
• أكثر الأخطاء شيوعًا مع نطاقات تسجيل الدخول (وكيف تتجنب جحيم “عنوان إعادة التوجيه غير متطابق”)
• كيف تدعم Logto النطاقات المخصصة وتساعدك على فعل كل هذا بدون أن تصبح مهندس DNS بدوام كامل

ما هو نطاق المصادقة المخصص؟#

لنُبقي الأمر بسيطًا.

كل مستأجر 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.com
• auth.us.example.com

عمليًا، هذا هو المناسب للمصادقة أصلًا:

• النطاقات الجذرية عادة محجوزة لموقعك الرئيسي (example.com).
• "ذروة المنطقة" في DNS لا يمكنها استخدام سجل CNAME، ويتطلب تسجيل الدخول المستضاف من Logto سجل CNAME موجه إلى domains.logto.app لتوجيه الترافيك.
• يدير Logto الشهادات من خلال Cloudflare. لإنهاء TLS على نطاق جذري سنحتاج للتحكم في تلك المنطقة بالكامل (بما في ذلك سجلات A، وMX، وTXT، وغيرها)، وهذا غير ممكن مع SaaS متعدد المستأجرين.

سجلات "تسطيح الذروة" (ALIAS/ANAME) لا تزال تُحل لعناوين IP لا نملكها، إذًا لا يمكنها دعم شهاداتنا المدارة. باختصار، تسجيل الدخول المستضاف يجب أن يكون في نطاق فرعي. وجه ذلك النطاق الفرعي إلى Logto بواسطة CNAME وسنقوم بمهمة التحقق، والـ SSL، وضمان الاستمرارية — ويبقى نطاقك الجذري حرًا لخدمة بقية موقعك.

لماذا ليست مسألة "إضافة CNAME وانتهينا"#

مفهوم خاطئ شائع جدًا:

"سأضيف 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 إذا انتهيت"، فستكسر غالبًا جانبًا آخر.

نموذج ذهني سريع: كيف يتدفق نطاق تسجيل الدخول عبر الواجهة التقنية#

تخيل رسمًا بيانيًا يبدأ فيه متصفح المستخدم بـ:

1. شريط عناوين المتصفح

   • ينقر المستخدم على تسجيل الدخول في https://example.com.
   • يتم إعادة توجيهه إلى https://auth.example.com/sign-in.

2. خادم التفويض ووثيقة الاكتشاف

   • يستخدم تطبيقك نقطة النهاية الخاصة بتكوين OpenID عند:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • هذا يخبر تطبيقك إلى أين يرسل طلبات المصادقة وأين يتوقع الرموز (tokens).

3. عناوين إعادة التوجيه (استدعاءات OIDC/OAuth)

   • بعد تسجيل الدخول، يعيد Logto التوجيه إلى تطبيقك إلى مكان مثل:
     https://app.example.com/callback
   • يجب أن يتفق موفر الهوية وتطبيقك على تلك الروابط.

4. تسجيل الدخول الاجتماعي / خطوات SSO المؤسساتي

   • من auth.example.com، قد ينتقل المستخدم إلى Google أو Microsoft Entra ID أو Okta ...الخ.
   • هؤلاء الموفرون ينظرون أيضًا ويتحققون من عناوين إعادة التوجيه التي تتضمن نطاقك المخصص للمصادقة.

5. الروابط في البريد الإلكتروني وروابط السحر/إعادة تعيين كلمة المرور

   • يجب أن تشير الروابط في الرسائل الإلكترونية باستمرار إلى نطاقك المخصص لتجنب إرباك المستخدمين.

في كل خطوة من هذه الخطوات، النطاق مهم. عندما تقدم نطاق تسجيل دخول مخصص، تريده أن يتدفق عبر السلسلة بالكامل بطريقة متماسكة.

لهذا السبب، الاستراتيجية المدروسة للنطاقات المخصصة لا تدور حول حيل DNS بل حول تصميم هوية متسق.

نطاق مخصص واحد مقابل متعدد#

بالنسبة للكثير من الفرق، يكفي نطاق مخصص واحد مثل auth.example.com. لكن مع توسع منتجك وجغرافيتك وقاعدة عملائك، ستواجه حدودًا بسرعة إذا لم تُخطط مسبقًا.

إليك كيف ترسم الفرق المختلفة عادة النطاقات على تجاربها في المصادقة:

كيف يجعل Logto إعداد النطاقات المخصصة سهلاً#

إليك ما يوفره لك Logto مباشرة، دون الحاجة لأن تصبح مختص DNS أو PKI.

• مستأجر واحد، العديد من النطاقات. اربط المناطق أو البيئات أو العملاء أو العلامات التجارية باستضافاتهم الخاصة لتسجيل الدخول دون استنساخ المستأجرين. تنطبق حدود الخطة، لكن الوعد الأساسي يبقى: أساس هوية واحد، نقاط دخول عديدة.
• يبقى الافتراضي فعالًا. إضافة auth.example.com لا تلغي {{tenant-id}}.app.logto. استخدم الافتراضي للأدوات الداخلية أو للتدرج في النشر، بينما يزور مستخدمي الإنتاج النطاق ذي العلامة التجارية.
• تتكيف الموصلات تلقائيًا. تشير إضافات SDK إلى endpoint الصحيح، بينما تعرض توصيلات الدخول الاجتماعي والمؤسساتي كل عنوان إعادة توجيه أو عنوان ACS صالح لكل نطاق—لا حاجة للتلاعب يدويًا بالروابط.
• SSL تلقائي بالكامل. بعد إضافة CNAME، يتحقق Logto من DNS، يزود الشهادات ويبقيها محدثة. لا إدارة للمفاتيح، ولا انتهاء صلاحية مفاجئ.

إلى أين تذهب من هنا#

إذا كنت قد قرأت حتى هنا، فأنت على الأرجح في أحد معسكرين.

تستخدم Logto فعلًا؟#

يمكنك البدء بتجربة النطاقات المخصصة المتعددة فورًا:

• اذهب إلى لوحة التحكم > الإعدادات > النطاقات. أضف نطاقًا مخصصًا ثانيًا لمنطقة جديدة ستطلقها، أو عميل رئيسي يريد تسجيل دخول بعلامته الخاصة، أو غير ذلك.
• حدث متغير endpoint في حزمة SDK عند الحاجة.
• أضف عناوين إعادة التوجيه وACS الخاصة بالنطاق والتي توفرها Logto في وصلات Social أو SSO إلى مزودي الهوية لديك.

إنها طريقة سهلة لتحسين تجربة تسجيل الدخول واختبار الأثر على ثقة المستخدمين ومعدل التحويل.

جديد على Logto؟#

إذا كنت تبدأ للتو:

• سجل للحصول على حساب في Logto وأنشئ مستأجرًا.
• اذهب إلى لوحة التحكم > الإعدادات > النطاقات. استخدم الحصة المجانية من النطاقات المخصصة لإعداد auth.example.com كنطاق تسجيل دخول علني من اليوم الأول.
• حافظ على النطاق الافتراضي {{tenant-id}}.app.logto متاحًا للاستخدام الداخلي أو الاختبار.

بهذا ستتجنب تمامًا مشكلة عنوان تسجيل الدخول الذي يبدو أنه بيئة اختبار، ولن تحتاج لاحقًا إلى تفكيك هجرة نطاقات معقدة بعد دخولك مرحلة النمو.

تريد التفاصيل خطوة بخطوة، بما في ذلك سجلات DNS وحل المشاكل؟
اطلع على الدليل الكامل في وثائقنا: النطاقات المخصصة لـ Logto Cloud.