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

  • مقالة

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

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

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

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

تدفق التعليمات البرمجية للتفويض (مع PKCE)

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

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

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

Single-page applications-auth

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

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

Single-page applications-implicit

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

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

تسجيل طلب SPA

  1. سجل دخولك إلى مدخل Azure.

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

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

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

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

  6. من Supported account types ، حدد Accounts in any identity provider or organizational directory (for authenticating users with user flows)

  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. ضمن أذونات، حدد مربع الاختيار منح موافقة المسؤول لفتح أذونات دخول ووصول عند عدم الاتصال بالإنترنت.

  9. حدد السجل.

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

إذا كنت تستخدم MSAL.js 1.3 أو إصدارا سابقا مع تدفق المنح الضمني في تطبيق SPA الخاص بك، أو إذا قمت بتكوين https://jwt.ms/ التطبيق لاختبار تدفق مستخدم أو نهج مخصص، فأنت بحاجة إلى تمكين تدفق المنح الضمني في تسجيل التطبيق:

  1. من القائمة اليسرى، تحت خانة "Manage"، حدد "Authentication".

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

  3. حدد حفظ.

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

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

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

عندما تبدأ كافة تطبيقات التشغيل أحادية الصفحة الممثلة بتسجيل تطبيق تدفق في استخدام التعليمة البرمجية للتخويل، قم بتعطيل إعدادات تدفق المنح الضمني كما يلي:

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

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

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

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