فك الغموض عن OAuth 2.0 في Microsoft Graph: الأذونات المفوَّضة مقابل أذونات التطبيق

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

Automatically translated with AI from the original post. Read the English original

Titelbild: Demystifying OAuth 2.0 in Microsoft Graph: Delegated vs. Application Permissions

أهلاً بكم مجدداً في المدونة! إذا كنتم تتعمقون في أتمتة Microsoft 365، فمن المرجح أنكم اصطدمتم بالحدود التي تفرضها الموصلات الأصلية وقيود البرمجة النصية التقليدية. قد يكون التعامل مع تعقيدات المصادقة أمراً صعباً عند أتمتة M365، خصوصاً عند محاولة الموازنة بين الأمان القوي والوظائف السلسة. سواء كنتم تبنون تطبيقات مؤسسية مخصصة أو تُعدّون عمليات خلفية مؤتمتة، فإن الإلمام الجيد بنماذج المصادقة أمر بالغ الأهمية. يتناول هذا المنشور الرموز المميزة (Tokens) والنطاقات (Scopes) وتدفقات الموافقة، ليساعدكم على اختيار النموذج المناسب للمهام المرتبطة بالمستخدم أو للمهام الخلفية غير المراقبة. هيا بنا نتعمق مباشرة في كيفية عمل OAuth 2.0 مع واجهة برمجة تطبيقات Microsoft Graph.

مقدمة في مصادقة Microsoft Graph

Microsoft Graph هي البوابة الموحدة إلى منظومة Microsoft 365 بأكملها. فبدلاً من التعامل مع واجهات برمجة تطبيقات منفصلة ومتفرقة لكل من Exchange وSharePoint وTeams وAzure Active Directory (المعروفة الآن باسم Microsoft Entra ID)، يمكن للمطورين ومسؤولي تقنية المعلومات الوصول إلى كل هذه الخدمات عبر نقطة نهاية واحدة. ومع ذلك، ولأن Graph تتحكم في الوصول إلى بيانات الشركات الحساسة، فإن تأمين هذه البوابة يتطلب إطار مصادقة صارماً. إن فهم كيفية تفاعل الهوية ورموز الوصول والأذونات هو الخطوة الأولى نحو بناء أتمتة موثوقة وآمنة، لا تنهار تحت الضغط ولا تُطلق تنبيهات أمنية.

فهم OAuth 2.0 في سياق Microsoft 365

يعتمد Microsoft Graph في جوهره على بروتوكول OAuth 2.0 للتفويض. فعندما يرغب تطبيقكم أو نصكم البرمجي في التواصل مع Graph، لا يمكنه ببساطة إرسال بيانات الاعتماد كما هي عبر الشبكة. بدلاً من ذلك، عليه أن يطلب رمز وصول (Access Token) من منصة هوية Microsoft (Entra ID). يعمل رمز الوصول هذا كجواز سفر رقمي آمن، إذ يُبيّن لـ Microsoft Graph من الذي يقدم الطلب، وأي تطبيق يُستخدم، والأهم من ذلك، ما الأذونات المحددة (النطاقات) الممنوحة لهذا الرمز. وبدون رمز صالح، سترفض Graph الطلب فوراً بخطأ "غير مصرّح" قياسي.

الأذونات المفوَّضة: متى يعمل التطبيق نيابةً عن المستخدم

يتوقف اختيار نموذج الأذونات المناسب كلياً على طبيعة عبء العمل لديكم. صُممت الأذونات المفوَّضة للتطبيقات التي تعمل بدعم من مستخدم قام بتسجيل الدخول. فعندما يستخدم تطبيق الأذونات المفوَّضة، فإنه يتصرف نيابةً عن المستخدم الذي يكون مسجلاً للدخول فعلياً. وإذا شغّل مستخدم نصاً برمجياً لقراءة تقويمه الخاص أو تحديث صورة ملفه الشخصي، فإن Graph تقيّم الطلب استناداً إلى ما يُسمح للتطبيق بفعله، وكذلك إلى ما يملك المستخدم نفسه صلاحية الوصول إليه. وإذا لم يكن لدى المستخدم صلاحية عرض صندوق بريد محدد، فلن يمنحه الرمز المفوَّض هذه الصلاحية أيضاً. يُعد هذا النموذج مثالياً للتطبيقات الموجهة للمستخدم، والأدوات التفاعلية، والنصوص البرمجية الشخصية لتعزيز الإنتاجية.

أذونات التطبيق: تشغيل المهام الخلفية غير المراقبة

وعلى النقيض من ذلك، ماذا لو احتجتم إلى تشغيل نص برمجي أو خدمة عند منتصف الليل دون وجود أي مستخدم أمام لوحة المفاتيح؟ بالنسبة للمهام الخلفية غير المراقبة، وخدمات الخلفية (Daemon)، وأدوات التقارير على مستوى المستأجر، تحتاجون إلى أذونات التطبيق. في هذا النموذج، يعمل التطبيق بشكل مستقل عن أي سياق للمستخدم، إذ يعمل بهويته الخاصة. ولأنه لا يوجد مستخدم بشري يسجل الدخول ويمنح الموافقة بشكل تفاعلي، فإن أذونات التطبيق تتطلب تفويضاً مسبقاً صريحاً من مسؤول المستأجر. وبمجرد منحها، يمكن للتطبيق الوصول إلى البيانات عبر المؤسسة بأكملها، مما يجعل هذا النموذج قوياً بشكل استثنائي لأتمتة الإدارة، ونصوص التهيئة للمستخدمين الجدد، ومراقبة الامتثال، لكنه يتطلب في المقابل إشرافاً أمنياً صارماً.

التنقل بين النطاقات والرموز المميزة وتدفقات الموافقة

مفردات المصادقة والتفويض قد تبدو أحيانًا مرهقة، لكن تفكيك سير العمل يوضّح العملية. النطاقات (Scopes) هي الأذونات المحددة التي يطلبها تطبيقك، مثل User.Read.All أو Mail.Read. عندما يفوّض المستخدم أو المسؤول تطبيقًا، فإنه يراجع هذه النطاقات ويوافق عليها. وبعد الموافقة، تُصدر منصة الهوية رمز ويب JSON (JWT). يتضمن الكود الخاص بك هذا الرمز في ترويسة Authorization الخاصة بـ HTTP مع كل طلب يُرسل إلى Microsoft Graph. فإدارة الموافقة بشكل صحيح تضمن أن يحصل تطبيقك على هذه الرموز بسلاسة دون الوقوع في عقبات غير متوقعة.

تجنّب متاهة موافقة المسؤول

من أكثر نقاط الاحتكاك شيوعًا التي يواجهها المطورون والمسؤولون الانتظارُ العالق بانتظار الموافقة الإدارية. عندما يطلب تطبيق نطاقات تطبيق عالية الامتياز أو نطاقات مفوَّضة حساسة، قد تشترط Microsoft Entra ID موافقة مسؤول على التطبيق قبل إصدار أي رموز. وإذا افترض خط نشر البرمجيات لديك أن المستخدمين قادرون على منح الموافقة بأنفسهم، ثم تفاجأ بأن نهج المستأجر يمنعهم، فسيتوقف الأتمتة بالكامل. ولتجنّب متاهة موافقة المسؤول، ارسم دائمًا خريطة للأذونات المطلوبة مسبقًا، ووثّق المبرر التجاري، ونسّق مع مسؤولي المستأجر العامين أو مسؤولي التطبيقات لتهيئة الموافقة على مستوى المستأجر مسبقًا عند الحاجة.

أخطاء شائعة وطرق إصلاحها

حتى المطورون ذوو الخبرة يصادفون أحيانًا عقبات محبطة في التفويض عند العمل مع Microsoft Graph. دعنا نلقِ نظرة على بعض المشكلات الشائعة وكيفية حلها:

يعمل على جهازي، ويفشل عند الآخرين: يحدث عادةً بسبب نقص الموافقة أو نطاقات غير صحيحة. الإصلاح: وثّق النطاقات المطلوبة بوضوح، وهيّئ الموافقة الإدارية على مستوى المستأجر عند الاقتضاء.
جلب حمولات ضخمة بشكل مفرط: سحب قوائم المستخدمين كاملةً دون تصفية يؤدي إلى انتهاء المهلة والتقييد (throttling). الإصلاح: استخدم $select و$top والترقيم بالصفحات واستعلامات delta.
حلقات 401/403 لا تنتهي: تحدث بسبب انتهاء صلاحية الرمز، أو استخدام نوع إذن مفوَّض لمهمة لا يوجد فيها مستخدم. الإصلاح: نفّذ آلية قوية لتجديد الرموز، وانتقل إلى أذونات التطبيق للمهام الخلفية.
بلوغ حدود المعدل: تلقّي استجابات 429 يعني أنك ترسل الطلبات بسرعة كبيرة. الإصلاح: نفّذ التراجع الأسي (exponential backoff)، واحترم ترويسة Retry-After، وجمّع العمليات في دفعات.
انتشار الأسرار: تضمين أسرار العملاء بشكل ثابت في النصوص البرمجية يمثل مخاطرة أمنية كبيرة. الإصلاح: استخدم Azure Key Vault أو الهويات المُدارة أو متغيرات البيئة الآمنة.

أفضل الممارسات في الأمن والحوكمة

عندما تفتح باب مستأجر Microsoft 365 الخاص بك عبر واجهة البرمجة، يجب أن يكون الأمن أولويتك القصوى. فالالتزام بمبدأ أقل الامتيازات يعني ألا تطلب إلا الحد الأدنى المطلق من النطاقات اللازمة لعمل تطبيقك، ولا تطلب أبدًا Directory.AccessAsUser.All لمجرد قراءة الاسم المعروض لمستخدم. احتفظ بسجل واضح للموافقات يوضح التطبيقات التي تملك حق الوصول إلى مستأجرك، وعزل بشكل كامل تسجيلات تطبيقاتك في بيئات التطوير والاختبار والإنتاج، وضع جدولًا صارمًا لتدوير أسرار العملاء والشهادات.

استعلاماتك الحقيقية الأولى (أمثلة)

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

موظفون جدد منذ تاريخ محدد:
GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
اجتماعاتي القادمة:
GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
أعضاء فريق في مجموعة:
GET /groups/{group-id}/members?$select=id,displayName,mail
المستخدمون الذين تغيّروا (delta):
GET /users/delta?$select=id,displayName,mail

الأدوات الموصى بها

الاستفادة من الأدوات المناسبة تجعل بناء استعلامات Microsoft Graph وتصحيح أخطائها أسهل بكثير. يُعد Graph Explorer ملعبًا إلكترونيًا لا غنى عنه لاختبار نقاط النهاية والتحقق من تلميحات الموافقة. أما لكتابة الكود، فإن حزم تطوير البرمجيات (SDKs) الخاصة بـ Microsoft Graph (لغات .NET وJavaScript وPython) تُخفي الكثير من تفاصيل HTTP الأساسية. وتُعد Postman أو امتدادات REST Client في بيئة التطوير المتكاملة مفيدة جدًا لإدارة المجموعات والبيئات، بينما تتولى Power Automate وLogic Apps وPowerShell أتمتة سير العمل المرئي والتشغيلي بكفاءة عالية.

الأسئلة المتداولة

الأذونات المفوَّضة مقابل أذونات التطبيق، كيف أختار؟

تُناسب الأذونات المفوّضة (Delegated permissions) المهام التي يقوم بها المستخدم بنفسه. أما المهام غير المُشرف عليها، والخدمات الخلفية (daemons)، والمهام الإدارية الواسعة النطاق، فتتطلب أذونات التطبيق (Application permissions) مع موافقة مسؤول مناسبة.

كيف أتجنب التقييد (Throttling)؟

استخدم $select لتقليل حجم الحمولات، ونفّذ ترقيم الصفحات واستعلامات Delta، وادمج الطلبات كلما أمكن ذلك. واحرص دائمًا على أن تتعامل نصوصك البرمجية مع رموز الحالة 429 بسلاسة، مع منطق لإعادة المحاولة.

هل يمكنني استخدام Graph دون كتابة شيفرة برمجية؟

نعم! يمكنك تجربة نقاط النهاية أولًا في Graph Explorer، وتنسيق سير العمل باستخدام Power Automate. وفي حالات المنطق المعقّد، انتقل إلى استخدام حزم SDK الرسمية أو نصوص PowerShell البرمجية.

هل Graph آمن بما يكفي لتقارير الامتثال؟

بالتأكيد. عند تطبيقه وفق مبدأ أقل الامتيازات، مع تسجيل مركزي للأحداث، ومسارات موافقة خاضعة للتدقيق، وإدارة آمنة للأسرار، فإن Microsoft Graph يستوفي معايير الامتثال الصارمة للمؤسسات.

الخاتمة

إتقان المصادقة في Microsoft Graph هو المفتاح الأهم لأي مسؤول أو مهندس معماري أو مطوّر يسعى إلى الاستفادة الحقيقية من قدرات Microsoft 365. فمن خلال فهم الفرق الجوهري بين الأذونات المفوّضة وأذونات التطبيق، وإدارة النطاقات (scopes) والرموز (tokens) بعناية، والالتزام بحوكمة أمنية صارمة، يمكنك بناء أتمتة قوية وآمنة في الوقت نفسه. وللتعمق أكثر في هذا الموضوع، والاطلاع على نماذج الشيفرة، وتعلّم استراتيجيات متقدمة لمعالجة الأخطاء والتقييد، لا تفوّت الحلقة البودكاست ذات الصلة: Automate Microsoft 365 with Microsoft Graph API. أتمنى لك أتمتة موفقة!