أنواع التطبيقات لمنصة هوية Microsoft
يدعم النظام الأساسي للهوية من Microsoft المصادقة لمجموعة متنوعة من بنيات التطبيقات الحديثة، وكلها تستند إلى البروتوكولات المتوافقة مع معايير الصناعة OAuth 2.0 أو OpenID Connect. توضح هذه المقالة أنواع التطبيقات التي يمكنك إنشاؤها باستخدام نظام هوية Microsoft، بغض النظر عن اللغة أو النظام الأساسي المفضل لديك. صُممت المعلومات لمساعدتك على فهم السيناريوهات عالية المستوى قبل البدء في العمل باستخدام التعليمة البرمجية في سيناريوهات التطبيق.
أساسيات
يجب عليك تسجيل كل تطبيق يستخدم نظام هوية Microsoft الأساسي في App registrations في مدخل Microsoft Azure. تجمع هذه العملية القيم وتعينها لتطبيقك:
- Application (client) ID الذي يعرّف تطبيقك بشكل فريد
- Redirect URI الذي يمكنك استخدامه لتوجيه الردود مرة أخرى إلى تطبيقك
- بعض القيم الأخرى الخاصة بالسيناريو مثل أنواع الحسابات المدعومة
للحصول على التفاصيل، تعرف على كيفية تسجيل تطبيق.
بعد تسجيل التطبيق، يتصل التطبيق بمنصة تعريف Microsoft من خلال إرسال الطلبات إلى نقطة النهاية. نقدم أطر عمل ومكتبات مفتوحة المصدر تتعامل مع تفاصيل هذه الطلبات. لديك أيضاً خيار تنفيذ منطق المصادقة بنفسك عن طريق إنشاء طلبات لنقاط النهاية:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
تطبيقات الصفحة الواحدة (JavaScript)
تحتوي العديد من التطبيقات الحديثة على واجهة أمامية لتطبيق من صفحة واحدة مكتوبة أساساً بلغة JavaScript، وغالباً مع إطار عمل مثل Angular أو React أو Vue. يدعم النظام الأساسي للهوية من Microsoft هذه التطبيقات باستخدام بروتوكول OpenID Connect للمصادقة وتدفق منح OAuth 2.0 الضمني أو أحدث رمز مصادقة OAuth 2.0 + تدفق PKCE للتفويض (انظر أدناه).
يوضح الرسم التخطيطي للتدفق أدناه منح رمز تفويض OAuth 2.0 (مع حذف تفاصيل حول PKCE)، حيث يتلقى التطبيق رمزاً من نقطة نهاية النظام الأساسي للهوية لـ Microsoft authorize، ويستبدلها برمز مميز للوصول ورمز مميز للتحديث باستخدام التقاطع -طلبات الويب. تنتهي صلاحية الرمز المميز للوصول كل 24 ساعة، ويجب أن يطلب التطبيق رمزاً آخر باستخدام رمز التحديث. بالإضافة إلى الرمز المميز للوصول، عادةً ما يُطلب id_token الذي يمثل المستخدم الذي قام بتسجيل الدخول إلى تطبيق العميل من خلال نفس التدفق و/أو طلب OpenID Connect منفصل (غير معروض هنا).
لمشاهدة هذا السيناريو عملياً، راجع البرنامج التعليمي: تسجيل الدخول للمستخدمين واستدعاء Microsoft Graph API من JavaScript SPA باستخدام تدفق كود المصادقة.
تدفق كود التفويض مقابل التدفق الضمني
بالنسبة لمعظم تاريخ OAuth 2.0، كان التدفق الضمني هو الطريقة الموصى بها لإنشاء تطبيقات من صفحة واحدة. مع إزالة ملفات تعريف الارتباط للجهات الخارجية واهتمام أكبر بالمخاوف الأمنية المتعلقة بالتدفق الضمني، انتقلنا إلى تدفق شفرة التفويض لتطبيقات صفحة واحدة.
لضمان توافق تطبيقك في Safari والمتصفحات الأخرى المهتمة بالخصوصية، لم نعد نوصي باستخدام التدفق الضمني وبدلاً من ذلك نوصي بتدفق رمز التفويض.
تطبيقات الويب
بالنسبة لتطبيقات الويب (.NET، PHP، Java، Ruby، Python، Node) التي يصل إليها المستخدم من خلال متصفح، يمكنك استخدام OpenID Connect لتسجيل دخول المستخدم. في OpenID Connect، يتلقى تطبيق الويب رمزاً مميزاً للمعرف. رمز المعرف هو رمز أمان يتحقق من هوية المستخدم ويوفر معلومات حول المستخدم في شكل مطالبات:
// 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"
...
}
تتوفر المزيد من التفاصيل حول الأنواع المختلفة من الرموز المميزة المستخدمة في النظام الأساسي للهوية من Microsoft في مرجع الرمز المميز للوصول ومرجع id_token
في تطبيقات خادم الويب، يأخذ تدفق مصادقة تسجيل الدخول الخطوات عالية المستوى:
يمكنك التأكد من هوية المستخدم من خلال التحقق من صحة الرمز المميز للمعرف باستخدام مفتاح توقيع عام يُستلم من نظام هوية Microsoft. يُعيَّن ملف تعريف ارتباط الجلسة، الذي يمكن استخدامه لتحديد المستخدم في طلبات الصفحة اللاحقة.
لمشاهدة هذا السيناريو عملياً، جرب نماذج التعليمات البرمجية في تطبيق الويب الذي يقوم بتسجيل الدخول إلى سيناريو المستخدمين .
بالإضافة إلى تسجيل الدخول البسيط، قد يحتاج تطبيق خادم الويب إلى الوصول إلى خدمة ويب أخرى، مثل REST API. في هذه الحالة، يشارك تطبيق خادم الويب في تدفق OpenID Connect وOAuth 2.0 المدمجين، باستخدام تدفق كود مصادقة OAuth 2.0 . لمزيد من المعلومات حول هذا السيناريو، اقرأ عن بدء استخدام تطبيقات الويب وواجهات برمجة تطبيقات الويب.
واجهات برمجة تطبيقات الويب
يمكنك استخدام نظام هوية Microsoft لتأمين خدمات الويب، مثل واجهة برمجة تطبيقات الويب RESTful لتطبيقك. يمكن تنفيذ واجهات برمجة تطبيقات الويب بالعديد من الأنظمة الأساسية واللغات. يمكن أيضاً تنفيذها باستخدام مشغلات HTTP في وظائف Azure. بدلاً من الرموز المميزة للمعرف وملفات تعريف الارتباط للجلسة، تستخدم واجهة برمجة تطبيقات الويب رمز مميز للوصول OAuth 2.0 لتأمين بياناتها ولمصادقة الطلبات الواردة. يُلحق مستدعي واجهة برمجة تطبيقات الويب رمز مميز للوصول في عنوان التفويض لطلب HTTP، مثل هذا:
GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...
تستخدم واجهة برمجة تطبيقات الويب الرمز المميز للوصول للتحقق من هوية طالب واجهة برمجة التطبيقات واستخراج معلومات حول المتصل من المطالبات المشفرة في الرمز المميز للوصول. تتوفر المزيد من التفاصيل عن الأنواع المختلفة من الرموز المميزة المستخدمة في النظام الأساسي للهوية من Microsoft في مرجع الرمز المميز للوصول ومرجع id_token.
يمكن لواجهة برمجة تطبيقات الويب أن تمنح المستخدمين القدرة على الاشتراك أو إلغاء الاشتراك في وظائف أو بيانات معينة عن طريق الكشف عن الأذونات، المعروفة أيضاً باسم النطاقات. لكي يحصل تطبيق الاتصال على إذن لنطاق، يجب أن يوافق المستخدم على النطاق أثناء التدفق. تطلب منصة هوية Microsoft من المستخدم الإذن، ثم تسجل الأذونات في جميع الرموز المميزة للوصول التي تتلقاها واجهة برمجة تطبيقات الويب. تتحقق واجهة برمجة تطبيقات الويب من الرموز المميزة للوصول التي تتلقاها في كل مكالمة وتقوم بإجراء فحوصات التفويض.
يمكن لواجهة برمجة تطبيقات الويب أن تتلقى الرموز المميزة للوصول من جميع أنواع التطبيقات، بما في ذلك تطبيقات خادم الويب، وتطبيقات سطح المكتب والجوال، وتطبيقات الصفحة الواحدة، والرسائل الخفية على جانب الخادم، وحتى واجهات برمجة تطبيقات الويب الأخرى. يبدو التدفق عالي المستوى لواجهة برمجة تطبيقات الويب كما يلي:
لمعرفة كيفية تأمين واجهة برمجة تطبيقات الويب باستخدام الرموز المميزة للوصول OAuth2، تحقق من نماذج رموز واجهة برمجة تطبيقات الويب في سيناريو API ويب المحمية.
في كثير من الحالات، تحتاج واجهات برمجة التطبيقات على الويب أيضاً إلى تقديم طلبات صادرة إلى واجهات برمجة تطبيقات الويب الأخرى المتلقية للمعلومات والمؤمنة عن طريق النظام الأساسي للهوية من Microsoft. للقيام بذلك، يمكن لواجهات برمجة تطبيقات الويب الاستفادة من تدفق On-Behalf-Of، الذي يسمح لواجهة برمجة تطبيقات الويب بتبادل رمز مميز للوصول وارد لرمز مميز للوصول آخر لاستخدامه في الطلبات الصادرة. لمزيد من المعلومات، راجع نظام هوية Microsoft وتدفق OAuth 2.0 On-Behalf-Of.
تطبيقات الجوال والتطبيقات الأصلية
غالباً ما تحتاج التطبيقات المثبتة على الجهاز، مثل تطبيقات الجوال وسطح المكتب، إلى الوصول إلى الخدمات الخلفية أو واجهات برمجة تطبيقات الويب التي تخزن البيانات وتؤدي وظائف نيابة عن المستخدم. يمكن لهذه التطبيقات إضافة تسجيل الدخول والتفويض إلى الخدمات الخلفية باستخدام تدفق رمز مصادقة OAuth 2.0.
في هذا التدفق، يتلقى التطبيق رمز ترخيص من النظام الأساسي للهوية من Microsoft عندما يقوم المستخدم بتسجيل الدخول. يمثل رمز التفويض إذن التطبيق للاتصال بالخدمات الخلفية نيابة عن المستخدم الذي سجَّل الدخول. يمكن للتطبيق استبدال رمز التفويض في الخلفية برمز مميز للوصول OAuth 2.0 ورمز مميز للتحديث. يمكن للتطبيق استخدام الرمز المميز للوصول للمصادقة على واجهات برمجة تطبيقات الويب في طلبات HTTP، واستخدام رمز التحديث للحصول على رموز وصول جديدة عند انتهاء صلاحية الرموز المميزة للوصول القديمة.
ملاحظة
إذا كان التطبيق يستخدم طريقة عرض الويب الافتراضية للنظام، تحقق من المعلومات حول وظيفة "تأكيد تسجيل الدخول الخاص بي" ورمز الخطأ AADSTS50199 في مصادقة مصادقة Azure AD ورموز خطأ المصادقة.
الرسائل الخفية والتطبيقات على جانب الخادم
تحتاج التطبيقات التي تتضمن عمليات تشغيل طويلة أو التي تعمل دون تفاعل مع مستخدم أيضاً إلى طريقة للوصول إلى الموارد المؤمنة، مثل واجهات برمجة تطبيقات الويب. يمكن لهذه التطبيقات المصادقة والحصول على الرموز المميزة باستخدام هوية التطبيق، بدلاً من الهوية المفوّضة للمستخدم، من خلال تدفق بيانات اعتماد عميل OAuth 2.0. يمكنك إثبات هوية التطبيق باستخدام CLI. لمزيد من المعلومات، راجع تطبيق وحدة تحكم NET Core. باستخدام النظام الأساسي للهويات في Microsoft.
في هذا التدفق، يتفاعل التطبيق مباشرة مع /token نقطة النهاية للحصول على الوصول:
لإنشاء تطبيق الخفي، راجع وثائق بيانات اعتماد العميل، أو حاول تطبيق نموذج .NET.
الخطوات التالية
الآن بعد أن تعرفت على أنواع التطبيقات التي يدعمها النظام الأساسي للهوية من Microsoft، تعرف على المزيد حول OAuth 2.0 وOpenID Connect لاكتساب فهم لمكونات البروتوكول التي تستخدمها السيناريوهات المختلفة.