تسجيل تطبيق من صفحة واحدة في Azure Active Directory B2C

هام

اعتبارا من 1 مايو 2025، لن يكون Azure AD B2C متوفرا للشراء للعملاء الجدد. تعرف على المزيد في الأسئلة المتداولة.

قبل أن تتمكن تطبيقاتك من التفاعل مع Azure Active Directory B2C (Azure AD B2C)، يجب تسجيلها في مستأجر تديره. يوضح لك هذا الدليل كيفية تسجيل تطبيق من صفحة واحدة ("SPA") باستخدام مدخل Microsoft Azure.

نظرة عامة على خيارات المصادقة

تم إنشاء العديد من تطبيقات الويب الحديثة كتطبيقات أحادية الصفحة من جانب العميل ("SPAs"). يكتبها المطورون باستخدام JavaScript أو إطار عمل SPA مثل Angular وVue وReact. تعمل هذه التطبيقات على مستعرض ويب ولهذه خصائص مصادقة مختلفة عن تطبيقات الويب التقليدية من جانب الخادم.

يوفر Azure AD B2C خيارين لتمكين التطبيقات أحادية الصفحة من تسجيل دخول المستخدمين والحصول على رموز مميزة للوصول إلى الخدمات الخلفية أو واجهات برمجة تطبيقات الويب:

تدفق رمز التخويل (مع PKCE)

يسمح تدفق رمز التخويل OAuth 2.0 (مع PKCE) للتطبيق باستبدال رمز تخويل للرمز المميزة للمعرف لتمثيل المستخدم المصادق عليه ورمز الوصول المميز المطلوب لاستدعاء واجهات برمجة التطبيقات المحمية. بالإضافة إلى ذلك، يقوم بإرجاع تحديث الرموز المميزة التي توفر وصولا طويل الأجل إلى الموارد نيابة عن المستخدمين دون الحاجة إلى التفاعل مع هؤلاء المستخدمين.

هذا هو النهج الموصى به . يساعد وجود رموز تحديث محدودة العمر التطبيق الخاص بك على التكيف مع قيود خصوصية ملفات تعريف الارتباط للمستعرض الحديث، مثل Safari ITP.

للاستفادة من هذا التدفق، يمكن للتطبيق الخاص بك استخدام مكتبة مصادقة تدعمه، مثل MSAL.js.

تدفق المنح الضمني

تدعم بعض المكتبات، مثل MSAL.js 1.x، تدفق المنح الضمني فقط أو يتم تنفيذ تطبيقاتك لاستخدام التدفق الضمني. في هذه الحالات، يدعم Azure AD B2C التدفق الضمني OAuth 2.0. يسمح تدفق المنح الضمني للتطبيق بالحصول على الرموز المميزة للمعرفوالوصول من نقطة نهاية التخويل. على عكس تدفق رمز التخويل، لا يرجع تدفق المنح الضمني رمز تحديث مميزا.

لا يتضمن تدفق المصادقة هذا سيناريوهات التطبيق التي تستخدم أطر عمل JavaScript عبر الأنظمة الأساسية مثل Electron وReact-Native. تتطلب هذه السيناريوهات المزيد من القدرات للتفاعل مع الأنظمة الأساسية الأصلية.

المتطلبات الأساسية

• في حال لم يكن لديك اشتراك Azure، فأنشئ حساباً مجانيّاً قبل البدء.

• إذا لم يكن لديك مستأجر Azure AD B2C، فبادر بإنشاء مستأجر الآن. يمكنك استخدام مستأجر Azure AD B2C موجود.

تسجيل طلب SPA

1. قم بتسجيل الدخول إلى بوابة Azure.

2. إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد أيقونة الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة الدلائل + الاشتراكات .

3. في مدخل Microsoft Azure، ابحث عن Azure AD B2C وحددها.

4. حدد App registrations، ثم حدد New registration.

5. أدخل اسمًا للتطبيق. على سبيل المثال، spaapp1.

6. ضمن أنواع الحسابات المدعومة، حدد الحسابات في أي موفر هوية أو دليل تنظيمي (لمصادقة المستخدمين الذين لديهم تدفقات المستخدمين)

7. ضمن Redirect URI، حدد Single-page application (SPA)، ثم أدخل https://jwt.ms في مربع نص URL.

   عنوان URI لإعادة التوجيه هو نقطة النهاية حيث يرسل خادم التخويل (Azure AD B2C، في هذه الحالة) المستخدم بعد إكمال تفاعله مع المستخدم. أيضا، تتلقى نقطة نهاية URI لإعادة التوجيه رمز الوصول أو رمز التخويل عند التخويل الناجح. في تطبيق الإنتاج، عادة ما تكون نقطة نهاية يمكن الوصول إليها بشكل عام حيث يتم تشغيل تطبيقك، مثل https://contoso.com/auth-response. لأغراض الاختبار مثل هذا الدليل، يمكنك تعيينه إلى https://jwt.ms، تطبيق ويب مملوك من Microsoft يعرض المحتويات التي تم فك ترميزها للرمز المميز (لا تترك محتويات الرمز المميز المستعرض مطلقا). أثناء تطوير التطبيق، يمكنك إضافة نقطة النهاية حيث يستمع تطبيقك محليا، مثل http://localhost:5000. يمكنك إضافة وتعديل عناوين "URI" لإعادة التوجيه في تطبيقاتك المسجلة في أي وقت.

   تنطبق القيود التالية على إعادة توجيه عناوين "URI":

   • يجب أن يبدأ عنوان URL للرد بالمخطط https، ما لم يتم استخدام localhost.
   • يكون عنوان "URL" للرد حساسًا لحالة الأحرف. يجب أن تتطابق حالته مع حالة مسار عنوان "URL" للتطبيق قيد التشغيل. على سبيل المثال، إذا كان التطبيق الخاص بك يتضمن كجزء من مساره .../abc/response-oidc، فلا تحدد .../ABC/response-oidc في عنوان URL للرد. نظرا لأن مستعرض الويب يعامل المسارات على أنها حساسة لحالة الأحرف، فقد يتم استبعاد ملفات تعريف الارتباط المقترنة .../abc/response-oidc بها إذا تمت إعادة توجيهها إلى عنوان URL غير المتطابق .../ABC/response-oidc مع حالة الأحرف.

8. ضمن الأذونات، حدد خانة الاختيار منح موافقة المسؤول على أذونات openid وأذونات offline_access .

9. حدد Register.

تمكين تدفق المنح الضمني

يمكنك تمكين تدفق المنح الضمني لسببين، عند استخدام الإصدار MSAL.js 1.3 أو الإصدار السابق أو عند استخدام تسجيل تطبيق لاختبار تدفق مستخدم لأغراض الاختبار.

استخدم هذه الخطوات لتمكين تدفق المنح الضمني لتطبيقك:

1. حدد تسجيل التطبيق الذي أنشأته.

2. ضمن "Manage"، حدد "Authentication".

3. ضمن المنحة الضمنية والتدفقات المختلطة، حدد خانتي الاختيار الرموز المميزة للوصول (المستخدمة للتدفقات الضمنية) والرموز المميزة للمعرف (المستخدمة للتدفقات الضمنية والمختلطة).

4. حدد Save.

ملاحظه

إذا كان تطبيقك يستخدم MSAL.js 2.0 أو أحدث، فلا تقم بتمكين تدفق المنح الضمني لأن MSAL.js 2.0+ يدعم تدفق رمز التخويل OAuth 2.0 (مع PKCE). إذا قمت بتمكين المنحة الضمنية لاختبار تدفق مستخدم، فتأكد من تعطيل إعدادات تدفق المنح الضمنية قبل نشر تطبيقك في الإنتاج.

الترحيل من تدفق المنح الضمني

إذا كان لديك تطبيق موجود يستخدم التدفق الضمني، نوصي بالترحيل لاستخدام تدفق رمز التخويل مع PKCE باستخدام إطار عمل يدعمه، مثل MSAL.js 2.0+.

عندما يبدأ كل إنتاج SPA الذي يمثله تسجيل تطبيق في استخدام تدفق رمز التخويل، قم بتعطيل إعدادات تدفق المنح الضمنية كما يلي:

1. من القائمة اليسرى، تحت خانة "Manage"، حدد "Authentication".
2. ضمن المنحة الضمنية، قم بإلغاء تحديد خانتي الاختيار رموز الوصول المميزةورمز المعرف المميزة .
3. حدد Save.

يمكن أن تستمر التطبيقات التي تستخدم التدفق الضمني في العمل إذا تركت التدفق الضمني ممكنا (محددا).

الخطوات التالية

تعرف على كيفية إنشاء تدفقات المستخدم في Azure Active Directory B2C.