توفر واجهة برمجة تطبيقات Brightspace للمطورين طريقتين للمصادقة: OAuth 2.0 ومصادقة مفتاح المعرف الخاصة بنا. يركز دليل المصادقة هذا على OAuth 2.0. يرجى ملاحظة أننا نشجعك على استخدام معيار OAuth 2.0 لأن هذا هو المكان الذي نستثمر فيه في D2L.
بغض النظر عن نهج المصادقة، تنطبق أفضل ممارسات الأمان الموضحة هنا.
أمن التطبيق
توفر تطبيقات API وسيلة قوية جدا للوصول إلى Brightspace. يوفر الجمع بين معلومات تطبيق API بالإضافة إلى حساب مستخدم Brightspace الوصول إلى واجهة برمجة تطبيقات Brightspace. لذلك من المهم الحفاظ على معلومات تطبيق API متاحة لعدد أقل من الأشخاص. الأهم من ذلك ، حافظ على أمان هذه المعلومات:
- OAuth 2.0 - سر العميل
- مصادقة مفتاح المعرف - مفتاح التطبيق
سياق مستخدم Brightspace
يتم تسجيل كل مستخدم Brightspace في وحدات Brightspace التنظيمية ذات الدور المحدد. تحدد أذونات هذا الدور ما يمكن للمستخدم فعله وما لا يمكنه فعله داخل واجهة مستخدم Brightspace و باستخدام واجهة برمجة تطبيقات Brightspace.
نطاقات OAuth 2.0
يوفر OAuth 2.0 مستوى إضافيا من التحكم في الوصول إلى Brightspace من خلال واجهة برمجة التطبيقات الخاصة بنا. مع OAuth 2.0، تظل أذونات Brightspace للمستخدم سارية، ولكن يجب أن يكون تطبيق OAuth 2.0 المستخدم أيضًا لديها نطاقات كافية لإجراء استدعاءات واجهة برمجة التطبيقات. A تتوفر قائمة نطاقات OAuth 2.0 المتوفرة في وثائق واجهة برمجة تطبيقات Brightspace الخاصة بنا.
لب:*:*
لا تحتوي جميع مسارات واجهة برمجة التطبيقات على نطاق OAuth 2.0 محدد. تستخدم هذه المسارات نطاقا خاصا يسمى "core:*:*". نخطط لإضافة نطاقات OAuth 2.0 أكثر تحديدا بمرور الوقت. أثناء قيامنا بذلك ، سنواصل دعم نطاق "core:*:*" لتلك المسارات. ومع ذلك، يوصى بشدة بأن تقوم التطبيقات بتحديث تعريف نطاقها ليتماشى مع قيم النطاق الأكثر تحديدا المتاحة.
موارد
توثيق
واجهة برمجة تطبيقات Brightspace وسياق المستخدم
جدول نطاقات OAuth 2.0
بدء استخدام نطاقات OAuth 2.0 - الأسئلة الشائعة
مجتمع
مصادقة مفتاح المعرف - الأسئلة الشائعة حول مصادقة المستخدم وأفضل الممارسات