مشاركة عبر

أنواع التطبيقات التي يمكن استخدامها في Active Directory B2C

  • مقالة

يدعم Azure Active Directory B2C (Azure AD B2C) المصادقة على العديد من بنيات التطبيقات الحديثة. وتستند كل منها على بروتوكولات معيار الصناعة ⁧⁩OAuth 2.0⁧⁩ أو ⁧⁩OpenID Connect⁧⁩. توضح هذه المقالة أنواع التطبيقات التي يمكنك إنشاؤها مستقلة عن اللغة أو النظام الأساسي الذي تفضله. كما يساعدك على فهم السيناريوهات عالية المستوى قبل البدء في إنشاء التطبيقات.

يجب تسجيل كل تطبيق يستخدم متاجرة عمل-مستهلك Azure AD في ⁧⁩مستأجر متاجرة عمل-مستهلك Azure AD باستخدام ⁧⁩مدخل Azure⁧⁩. تجمع عملية تسجيل الطلبات القيم وتعينها، مثل:

  • ⁧⁩معرّف التطبيق⁧⁩ الذي يعرف تطبيقك بشكل فريد.
  • ⁧⁩عنوان URL للرد⁧⁩ يمكن استخدامه لتوجيه الاستجابات إلى التطبيق.

يحدد كل طلب يتم إرساله إلى متاجرة عمل-مستهلك Azure AD تدفق مستخدم (نهج مضمن) أو نهج مخصص يتحكم في سلوك متاجرة عمل-مستهلك Azure AD. كلا نوعي النهج تمكنك من إنشاء مجموعة عالية للتخصيص من تجارب المستخدم.

يتبع التفاعل بين كل تطبيق نمطًا مماثلاً عالي المستوى:

  1. يوجه التطبيق المستخدم إلى نقطة النهاية v2.0 لتنفيذ ⁧⁩نهج⁧⁩.
  2. يكمل المستخدم وفقًا لتعريف النهج.
  3. يتلقى التطبيق رمزًا مميزًا من نقطة النهاية v2.0.
  4. يستخدم التطبيق رمزًا مميزًا للوصول إلى المعلومات المحمية أو مورد محمي.
  5. يتحقق خادم المورد بالتحقق من صحة الرمز المميز للتحقق من أنه يمكن منح الوصول.
  6. يحدث التطبيق الرمز المميز بشكل دوري.

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

تطبيقات الويب

بالنسبة لتطبيقات الويب (بما في ذلك .NET وPHP وJava وRupi وPython Node.js) التي تتم استضافتها على خادم ويب والوصول إليها من خلال مستعرض، يدعم Azure AD B2C OpenID Connect لجميع تجارب المستخدم. في Azure AD تنفيذ B2C ل OpenID Connect، يبدأ تطبيق الويب الخاص بك تجارب المستخدم عن طريق إصدار طلبات المصادقة إلى معرف Microsoft Entra. وتكون نتيجة الطلب هي ⁧id_token⁩. يمثل هذا الرمز المميز هوية المستخدم. كما يقدم معلومات عن المستخدم في نموذج مطالبات:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

تعرّف على المزيد حول أنواع الرموز المميزة والمطالبات المتوفرة لتطبيق في ⁧⁩مرجع الرمز المميز متاجرة عمل-مستهلك Azure AD⁧⁩.

في تطبيق ويب، كل تنفيذ ⁧⁩نهج⁧⁩ يأخذ هذه الخطوات عالية المستوى:

  1. يستعرض المستخدم إلى تطبيق ويب.
  2. يقوم تطبيق الويب بإعادة توجيه المستخدم إلى متاجرة عمل-مستهلك Azure AD للإشارة إلى النهج المطلوب تنفيذه.
  3. يكمل المستخدم النهج.
  4. تُرجع متاجرة عمل-مستهلك Azure AD ⁧id_token⁩ إلى المستعرض.
  5. ينتشر ⁧id_token⁩إلى عنوان URI لإعادة توجيه.
  6. تم التحقق من صحة ملف ⁧id_token⁩ تعريف ارتباط جلسة.
  7. يتم إرجاع صفحة آمنة إلى المستخدم.

التحقق من id_token صحة باستخدام مفتاح توقيع عام يتم تلقيه من معرف Microsoft Entra كاف للتحقق من هوية المستخدم. تحدد هذه العملية أيضًا ملف تعريف ارتباط جلسة التي يمكن استخدامها لتعريف المستخدم على طلبات الصفحة اللاحقة.

لمشاهدة هذا السيناريو في الإجراء، جرّب إحدى عينات التعليمات البرمجية لتسجيل الدخول إلى تطبيق الويب في ⁧⁩قسم البدء⁧⁩.

بالإضافة إلى تسهيل تسجيل الدخول البسيط، قد يحتاج تطبيق الويب أيضا إلى الوصول إلى خدمة ويب خلفية. في هذه الحالة، يمكن لتطبيق ويب تنفيذ ⁧⁩تدفق OpenID Connect⁧⁩ مختلفة قليلاً والحصول على رموز مميزة باستخدام التعليمات البرمجية للتخويل وتحديث الرموز المميزة. يتم تصوير هذا السيناريو في ⁧⁩فسم واجهات برمجة التطبيقات ويب⁧⁩التالي.

تطبيقات من صفحة واحدة

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

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

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

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

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

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

مصادقة التطبيقات أحادية الصفحة

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

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

لا نوصي بهذا النهج.

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

واجهات برمجة تطبيقات الويب

يمكنك استخدام متاجرة عمل-مستهلك Azure AD لتأمين خدمات الويب مثل واجهة برمجة تطبيقات الويب RESTful الخاصة بالتطبيق. يمكن لواجهات برمجة تطبيقات الويب استخدام OAuth 2.0 لتأمين البيانات الخاصة بهم، عن طريق مصادقة طلبات HTTP الواردة باستخدام الرموز المميزة. يُلحق المتصل بواجهة برمجة تطبيقات ويب رمز مميز في عنوان التخويل لطلب HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

يمكن لواجهة برمجة تطبيقات الويب بعد ذلك استخدام الرمز المميز للتحقق من هوية المتصل بواجهة برمجة التطبيقات واستخراج معلومات حول المتصل من المطالبات التي تم ترميزها في الرمز المميز. تعرّف على المزيد حول أنواع الرموز المميزة والمطالبات المتوفرة لتطبيق في ⁧⁩مرجع الرمز المميز متاجرة عمل-مستهلك Azure AD⁧⁩.

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

  1. ينفذ تطبيق الويب نهج ويكمل المستخدم تجربة المستخدم.
  2. تُرجع متاجرة عمل-مستهلك Azure AD (OpenID Connect) ⁧id_token⁩ وتعليمة برمجية للتفويض إلى المستعرض.
  3. ينشر المستعرض ⁧id_token⁩ ورمز التخويل إلى URI المعاد توجيهه.
  4. يتحقق خادم الويب من صحة ⁧id_token⁩ ثمّ يعين ملف تعريف ارتباط جلسة.
  5. يطلب خادم ويب متاجرة عمل-مستهلك Azure AD للحصول على ⁧access_token⁩ بتزويده برمز التخويل ومعرّف عميل التطبيق وبيانات اعتماد العميل.
  6. يتم إرجاع ⁧access_token⁩و⁧refresh_token⁩ إلى خادم الويب.
  7. يتم استدعاء واجهة برمجة تطبيقات الويب بـ ⁧access_token⁩ في عنوان تخويل.
  8. تتحقق واجهة برمجة تطبيقات الويب من صحة الرمز المميز.
  9. يتم إرجاع البيانات الآمنة إلى تطبيق الويب.

لمعرفة المزيد حول رموز التخويل وتحديث الرموز المميزة وخطوات الحصول على الرموز المميزة، اقرأ عن ⁧⁩بروتوكول OAuth 2.0⁧⁩.

لمعرفة كيفية تأمين واجهة برمجة تطبيقات الويب باستخدام متاجرة عمل-مستهلك Azure AD، راجع البرامج التعليمية لواجهة برمجة التطبيقات على الويب في ⁧⁩قسم البدء⁧⁩.

تطبيقات الجوال والتطبيقات الأصلية

غالبًا ما تحتاج التطبيقات المثبتة على الأجهزة، مثل تطبيقات الجوال وسطح المكتب، إلى الوصول إلى الخدمات الخلفية أو واجهات برمجة التطبيقات على الويب نيابةً عن المستخدمين. يمكنك إضافة تجارب إدارة الهوية المخصصة إلى التطبيقات الأصلية الخاصة بك واستدعاء الخدمات الخلفية بأمان باستخدام متاجرة عمل-مستهلك Azure AD وتدفق ⁧⁩رمز التخويل OAuth 2.0⁧⁩.

في هذا التدفق، ينفذ التطبيق النهج ويتلقى authorization_code من معرف Microsoft Entra بعد أن يكمل المستخدم النهج. يمثل ⁧authorization_code⁩ إذن التطبيق للاتصال بخدمات النهاية الخلفية نيابة عن المستخدم الذي تم تسجيل الدخول إليه حاليًا. يمكن للتطبيق حينئذٍ تبادل ⁧authorization_code⁩ في الخلفية لـ ⁧access_token⁩ و⁧refresh_token⁩. يمكن للتطبيق استخدام ⁧access_token⁩ للمصادقة على واجهة برمجة تطبيقات ويب خلفية في طلبات HTTP. ويمكن أيضًا استخدام ⁧refresh_token⁩ للحصول على ⁧access_token⁩ جديد عند انتهاء صلاحية واحدة من الأقدم.

التطبيقات الخفية/الخادم

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

بالنسبة إلى Azure AD B2C، قد يكون تدفق بيانات اعتماد عميل OAuth 2.0 قيد المعاينة العامة حاليًا. ومع ذلك، يمكنك إعداد تدفق بيانات اعتماد العميل باستخدام معرف Microsoft Entra ونقطة النهاية النظام الأساسي للهويات في Microsoft /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) لتطبيق Microsoft Graph أو تطبيقك الخاص. لمزيد من المعلومات، راجع مقالة مرجع الرمز المميز Microsoft Entra.

أنواع التطبيقات غير المدعومة

سلاسل واجهة برمجة التطبيقات على الويب (نيابة عن التدفق)

تتضمن العديد من البنيات واجهة برمجة تطبيقات ويب تحتاج إلى استدعاء واجهة برمجة تطبيقات ويب أخرى في المصب، حيث يتم تأمين كليهما بواسطة متاجرة عمل-مستهلك Azure AD. هذا السيناريو شائع في العملاء الأصليين الذين لهم واجهة برمجة تطبيقات ويب الخلفية ويستدعي خدمة Microsoft عبر إنترنت مثل واجهة برمجة تطبيقات Microsoft Graph.

يمكن دعم هذا السيناريو لواجهة برمجة تطبيقات الويب المتسلسلة باستخدام منحة اعتماد حامل 2.0 JWT OAuth، المعروف أيضًا باسم نيابة عن التدفق. ومع ذلك، لا يتم حالياً تطبيق نيابة عن التدفق في متاجرة عمل-مستهلك Azure AD.

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

تعرف على المزيد حول النهج المضمنة التي يوفرها ⁧⁩تدفق المستخدم في Azure Active Directory B2C⁧⁩.