دليل تسجيل التطبيقات وOAuth للتكامل الآمن للتطبيقات

By Mirko Peters · 2026-05-04

سجّل تطبيقك باستخدام OAuth 2.0. افهم تدفق منح رمز التفويض لضمان الوصول الآمن، وهو جزء أساسي من منح رمز التفويض في OAuth 2.0.

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

لنكن صرحاء: إعداد المصادقة وتسجيل التطبيقات بشكل صحيح لا يقتصر على اتباع بروتوكولات ذكية، بل يتعلق بضمان بقاء مستخدميك وبياناتك ومؤسستك آمنة. يبسط هذا الدليل تسجيل التطبيقات وOAuth 2.0، حتى تتمكن من بناء مصادقة آمنة ومبنية على المعايير باستخدام Microsoft Entra ID (المعروف سابقًا باسم Azure AD) أو أي مزود تختاره.

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

دليل تسجيل التطبيقات وOAuth — التعريف

تسجيل التطبيق هو عملية إنشاء هوية التطبيق وإعدادها لدى مزوّد الهوية (مثل Azure AD أو Google أو Auth0)، بحيث يتمكن التطبيق من طلب المصادقة والتفويض بشكل آمن. وعادةً ما يتضمن ذلك تعيين معرّف العميل (client ID) وسرًا للعميل (client secret) أو شهادة، وتحديد عناوين إعادة التوجيه (redirect URIs)، وضبط الأذونات والنطاقات (scopes)، وإعداد أنواع المنح المسموح بها (grant types).

8 حقائق مفاجئة حول دليل تسجيل التطبيقات وOAuth

• قد تتسرب أسرار العملاء عبر السجلات: يقوم كثير من المطورين دون قصد بتسجيل معرّفات العملاء وأسرارها أثناء تصحيح الأخطاء، مما يجعل بيانات اعتماد تسجيل التطبيق عرضة للخطر ما لم تُشدَّد سياسات التسجيل؛ لذا تعامل دائمًا مع المعرّفات بحذر.
• عناوين إعادة التوجيه أكثر صرامة مما تتوقع: غالبًا ما تشترط مزوّدات OAuth تطابقًا تامًا لعناوين إعادة التوجيه (بما في ذلك الشرطة المائلة في النهاية والمخطط)، لذا قد تؤدي فروق بسيطة إلى تعطل تدفقات تبدو مُعدّة بشكل صحيح في تسجيل تطبيقك.
• العملاء العامون لا يحتاجون إلى أسرار، لكنهم يظلون بحاجة إلى حماية: تُعامَل التطبيقات الأصلية وتطبيقات الصفحة الواحدة كعملاء عامين دون أسرار للعميل، ومع ذلك يجب أن تستخدم PKCE وأساليب آمنة لإعادة التوجيه لمنع اعتراض الرمز.
• النطاقات لا تضمن أقل قدر من الصلاحيات افتراضيًا: عند تسجيل التطبيقات، قد تطلب النطاقات الافتراضية أو شاشات الموافقة صلاحيات واسعة؛ لذا فإن تقييد النطاقات بشكل صريح والموافقة التدريجية ضروريان لفرض مبدأ أقل الصلاحيات.
• إلغاء الرموز غير مدعوم عالميًا: لا تلتزم جميع مزوّدات الهوية بإلغاء الرموز أو توفر تسجيل الخروج الفوري عبر الجلسات، لذا يجب أن يتضمن تسجيل التطبيق إدارة الجلسات وسياسات رموز التحديث.
• بيانات تسجيل التطبيق الوصفية هي سطح هجوم: يمكن لأسماء التطبيقات وشعاراتها وعناوين إعادة التوجيه المكشوفة علنًا أن تساعد المهاجمين في تصميم هجمات تصيد أو إعادة توجيه مفتوحة مقنعة، إذا لم تُدَر بعناية.
• قد يؤدي التوفير الآلي إلى أخطاء في الأذونات: غالبًا ما تمنح أتمتة CI/CD التي تنشئ تسجيلات التطبيقات أذونات واجهة برمجة التطبيقات أوسع من اللازم، أو تفشل في تسجيل عناوين إعادة التوجيه المطلوبة، مما يؤدي إلى أعطال صامتة أو تعريض الأمن للخطر.
• تجربة واجهة الموافقة تؤثر في قرارات الأمان: غالبًا ما يمنح المستخدمون والمسؤولون موافقات واسعة لأن نوافذ الموافقة مربكة؛ وتصميم مطالبات موافقة واضحة ومحدودة في تسجيل التطبيق ودليل OAuth يقلل من منح صلاحيات زائدة.

فهم أساسيات OAuth 2.0 وEntra ID

يُعد OAuth 2.0 العمود الفقري لتدفقات المصادقة الحديثة، إذ يتيح للتطبيقات الوصول إلى بيانات المستخدمين وموارده بشكل آمن دون أن تطّلع أبدًا على كلمة المرور. ويقدّم هذا المقال نظرة عامة على عملية OAuth. وفي جوهره، يحدد OAuth 2.0 طريقة عمل كل من المستخدم (“مالك المورد”)، والتطبيق (“العميل”)، وموفّر الهوية (“خادم التفويض”) معًا، بحيث يبقى المستخدمون متحكّمين في معلوماتهم.

لكن ماذا يحدث عندما تريد مصادقة المستخدمين، لا مجرد منحهم الوصول إلى البيانات؟ هنا يأتي دور OpenID Connect، الذي يضيف طبقة هوية وتسجيل دخول آمنة فوق OAuth 2.0. وباستخدام OpenID Connect، تتيح لك مزوّدات مثل Microsoft Entra ID و Google التحقق من هوية المستخدمين وطلب أذونات محدودة النطاق للموارد الإضافية، وكل ذلك ضمن تجربة موحّدة واحدة.

إذا صادفت مصطلحات مثل “client ID” أو “authorization endpoint” أو “access token”، فلا تدع ذلك يربكك. فجميعها ترتبط بتحديد من يتواصل مع من، وما الذي يُسمح له بفعله. أما Microsoft Entra ID فيستخدم هذه البروتوكولات تحديدًا ليمنح المطوّرين أساسًا قائمًا على المعايير، مناسبًا لكل شيء بدءًا من تطبيقات الأعمال أحادية المستأجر وصولًا إلى منتجات SaaS الضخمة متعددة المستأجرين.

إن فهم هذه الأساسيات يعني أنك تبني على أرضية راسخة. فاختيار تدفق OAuth المناسب لسيناريوك، كأن تختار code flow لتطبيقات الويب أو device flow لأجهزة التلفاز الذكية، يضمن تسجيل دخول آمنًا وبسيطًا يثق به المستخدمون ويقدّره فريق الامتثال لديك.

دليل تسجيل التطبيقات و OAuth: الأخطاء الشائعة في OAuth 2.0 وEntra ID

يسرد دليل تسجيل التطبيقات و OAuth هذا الأخطاء المتكررة التي تقع فيها الفرق عند تطبيق OAuth 2.0 مع Microsoft Entra ID (Azure AD)، وكيف تؤثر هذه الأخطاء على الأمان والوظائف وتجربة المستخدم.

• الخلط بين مفاهيم OAuth 2.0 ومفاهيم OpenID Connect (مثل توقّع وجود رموز ID في حين لا تُصدر سوى رموز الوصول).
• استخدام تدفقات OAuth بشكل غير صحيح، كأن يُعامَل التدفق الضمني (implicit flow) على أنه مناسب للتطبيقات الحديثة بدلًا من Authorization Code مع PKCE.

• تسجيل عناوين إعادة التوجيه (redirect URIs) بشكل خاطئ، سواء بالمخطط الخاطئ أو بوجود شرطة مائلة زائدة في النهاية، أو باستخدام localhost في بيئة الإنتاج.
• استخدام إعدادات العميل العام (public client) للتطبيقات السرية أو العكس، ما يسبب أخطاء في الرموز أو يكشف الأسرار.
• عدم ضبط أذونات واجهة برمجة التطبيقات أو النطاقات (scopes) بشكل صحيح، أو نسيان منح موافقة المسؤول حيثما كانت مطلوبة.

• تضمين أسرار العميل في الشيفرة من جهة العميل أو في المستودعات العامة.
• عدم تدوير الأسرار والشهادات بانتظام، أو عدم إزالة بيانات الاعتماد منتهية الصلاحية من تسجيل التطبيق.
• استخدام أسرار طويلة الأمد دون داعٍ بدلًا من الشهادات قصيرة الأمد أو الهويات المُدارة.

• عدم التحقق من الرموز بشكل سليم (issuer، وaudience، وsignature، وnonce، وexp).
• تخزين رموز الوصول أو رموز التحديث بشكل غير آمن، مثل التخزين المحلي في المتصفح دون حماية.
• الوثوق بمحتوى الرموز دون التحقق من النطاقات أو الأدوار التي يعيدها Entra ID.

• الافتراض بأن موافقة المستخدم تعني منح التطبيق للأذونات، دون إدراك أن بعض الأذونات تتطلب موافقة المسؤول.
• طلب أذونات أو نطاقات مفرطة، ما يؤدي إلى مخاطر غير ضرورية وارتفاع معدلات الرفض أثناء الموافقة.

• عدم التعامل مع تدوير رموز التحديث وسياسات إبطالها الصادرة عن Entra ID، ما يؤدي إلى تسجيلات خروج غير متوقعة.
• استخدام رموز التحديث في العملاء العامين دون حماية مناسبة (استخدم PKCE ومدد صلاحية مناسبة للرموز).

• عدم ضبط إعدادات تعدد المستأجرين بشكل صحيح للتطبيقات المخصّصة للعمل عبر عدة مستأجرين.
• استخدام نقاط نهاية خاطئة (خاصة بالمستأجر مقابل common)، ما يسبب مشكلات في تسجيل الدخول أو الموافقة.

• عدم اختبار سلوك التطبيق عند تطبيق الوصول المشروط أو المصادقة متعددة العوامل (MFA) أو سياسات امتثال الأجهزة.
• افتراض أن الرموز المميزة (Tokens) ستُصدر دائمًا بالشروط نفسها أمرٌ خاطئ، إذ يمكن للنُهج أن تحظر الوصول أو تفرض خطوات مصادقة إضافية.

• اتباع تدفقات OAuth القديمة أو أنماط Azure AD v1 بدلًا من توصيات منصة هوية Microsoft (الإصدار 2.0).
• استخدام نماذج مجتمعية دون التحقق من تطبيقها لممارسات أمنية سليمة (PKCE، والتخزين الآمن، والتحقق الصحيح من الصلاحيات).

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

استخدم دليل تسجيل التطبيقات وOAuth هذا لمراجعة تطبيقك، واتبع أفضل ممارسات منصة هوية Microsoft، وقلّل المخاطر الأمنية والتشغيلية عند دمج OAuth 2.0 مع Entra ID.

متطلبات تسبق إعداد OAuth وتسجيل التطبيقات

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

ثانيًا، حدّد نوع التطبيق الذي تبنيه والمعرّفات الضرورية لعمله. هل هو تطبيق ويب، أم تطبيق صفحة واحدة (SPA)، أم تطبيق جوال، أم خدمة آلية؟ لكل نوع متطلباته الخاصة فيما يخص المصادقة والتفويض. وتحديد ذلك مبكرًا يحدد إعدادات الأمان التي ستختارها لاحقًا.

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

أخيرًا، اجمع التفاصيل التقنية، مثل عناوين URL المسموح بها لإعادة التوجيه بعد تسجيل الدخول، والمنصات التي ستدعمها (iOS وAndroid وWindows؟)، والأذونات (أو "النطاقات") التي يحتاج تطبيقك إلى طلبها. ترتيب هذه التفاصيل مسبقًا يوفّر وقتًا كبيرًا أثناء الإعداد، ويتجنب مشكلات شائعة مثل عناوين URI غير صالحة أو عدم تطابق أنواع الحسابات لاحقًا.

كيفية تسجيل تطبيقك في Microsoft Entra ID

يمهّد تسجيل تطبيقك في Microsoft Entra ID (المعروف سابقًا باسم Azure AD) الطريق لكل ما يتعلق بالمصادقة والوصول إلى واجهات برمجة التطبيقات. تبدأ العملية في مركز إدارة Entra، حيث تنشئ تسجيل تطبيق جديدًا، فيحصل تطبيقك على هوية فريدة (تُسمى "معرّف العميل" أو "client ID") ضمن دليل مؤسستك.

أدخل اسمًا لتطبيقك، ثم حدّد من يمكنه استخدامه: مؤسستك فقط، أو عدة مؤسسات، أو أي حساب Microsoft. هذه الخطوة حاسمة، خاصةً في تطبيقات SaaS وB2B، لأنها تحدد نطاق وصول تطبيقك وكيفية إدارة موافقة المستأجرين.

بعد اختيار الجمهور، اضبط تفاصيل المنصة الخاصة بتطبيقك. بالنسبة لتطبيقات الويب، أضف معرّف URI لإعادة التوجيه؛ أما بالنسبة لتطبيقات الجوال أو الصفحة الواحدة، فتضمن الإعدادات الخاصة بكل منصة تجربة تسجيل دخول سلسة. ترشدك بوابة Entra خلال إضافة بيانات الاعتماد، مثل أسرار العميل أو الشهادات، التي سيستخدمها تطبيقك لإثبات هويته.

إتمام التسجيل يوائم تطبيقك مع معايير OAuth 2.0 ويضمن بقاء تدفق المصادقة آمنًا ومتوافقًا مع المتطلبات التنظيمية. وسواء اخترت مستأجرًا واحدًا أم تخطط للتوسع إلى عدة مستأجرين، فإن فهم هذه الإعدادات مبكرًا يرسي أساسًا متينًا للتوسع والتكامل مستقبلًا.

أبرز فوائد تسجيل تطبيقك في Microsoft Entra ID

• إدارة الهوية المركزية: إدارة المصادقة والتفويض وهويات المستخدمين الخاصة بتطبيقك من مستأجر Entra ID واحد.
• تدفقات OAuth آمنة: استفد من الدعم المدمج لـ OAuth 2.0 وOpenID Connect لتنفيذ تسجيل دخول آمن، وإصدار الرموز المميزة، والوصول المفوّض.
• تسجيل الدخول الموحد (SSO): وفّر تسجيل دخول موحدًا سلسًا عبر Microsoft 365 وAzure وغيرها من الخدمات المتكاملة، لتحسين تجربة المستخدم وتقليل مرات طلب كلمة المرور.
• التحكم الدقيق في الأذونات: حدّد أذونات واجهات برمجة التطبيقات بدقة وأدِرها، مع تجارب الموافقة والوصول بأقل الامتيازات لكل من الأذونات المفوَّضة وأذونات التطبيقات.
• سياسات الوصول المشروط والأمان: فرض المصادقة متعددة العوامل، والامتثال للأجهزة، والموقع، والسياسات القائمة على المخاطر لحماية الوصول إلى التطبيقات والبيانات الحساسة.
• إدارة أسرار التطبيق وبيانات الاعتماد: تخزين أسرار العميل والشهادات وإعدادات تعدد المستأجرين وتدويرها بأمان، مع ممارسات إدارة دورة الحياة للحفاظ على سلامة استخدامات التطبيق.
• التكامل مع خدمات منصة Microsoft: الوصول إلى Microsoft Graph وواجهات Azure البرمجية وTeams وغيرها من إمكانات المنصة باستخدام الرموز المميزة الموحدة ونماذج الموافقة.
• دعم التطبيقات الهجينة ومتعددة المنصات: مصادقة المستخدمين عبر تطبيقات الويب والأجهزة المحمولة وسطح المكتب وسيناريوهات الخدمة إلى الخدمة، باستخدام بروتوكولات هوية متسقة، مع التأكد من أن كل تطبيق يستخدم المعرّفات الصحيحة.
• المراقبة والتدقيق: استخدام السجلات وتقارير تسجيل الدخول ورؤى الأمان لاكتشاف الحالات الشاذة والتحقيق في الحوادث والحفاظ على الامتثال.
• قابلية التوسع والجاهزية للمؤسسات: الاستفادة من البنية التحتية العالمية لـ Entra ID وخيارات تعدد المستأجرين والميزات المؤسسية لدعم قواعد المستخدمين المتنامية والاحتياجات التنظيمية المعقدة.
• أدوات المطورين والتوثيق: الاستفادة من حزم SDK ونماذج التعليمات البرمجية ودليل تسجيل التطبيقات & oauth لتسريع التنفيذ وحل المشكلات الشائعة.

إعداد عناوين URI لإعادة التوجيه وإعدادات المنصة لتطبيقات Entra ID

يبدو تعيين عناوين URI لإعادة التوجيه الصحيحة أثناء تسجيل التطبيق أمراً بسيطاً، لكنه خطوة حاسمة للأمان. فهذه العناوين تحدد لـ Entra ID المكان الذي يُرسل إليه المستخدمون، مع رموزهم المميزة، بعد محاولة تسجيل دخول ناجحة. وعند تعيينها، يفرض Entra قواعد صارمة: لا نطاقات بحرف البدل (wildcard)، ولا مخططات URI خطرة، ولا ثغرات مفتوحة يمكن للمهاجمين استغلالها.

إذا كنت تبني تطبيق صفحة واحدة (SPA)، فستستخدم عادةً عنوان URL عبر HTTPS يشير إلى نطاق تطبيقك لضمان اتصال آمن يتيح للتطبيق الحصول على البيانات. أما التطبيقات الأصلية فتحتاج إلى مخططات URI مرتبطة بحزمة التطبيق أو اسم الحزمة، وهذا يمنع التطبيقات العشوائية من اختطاف الرموز المميزة على الجهاز نفسه. أما تطبيقات الويب فعادةً ما تستخدم نقاط نهاية استدعاء تسجيل الدخول الخاصة بها، ويجب إدراج كل واحدة منها صراحةً.

تؤدي أخطاء الإعداد إلى أخطاء “redirect URI mismatch” المعروفة، والأخطر من ذلك أنها تفتح الباب أمام المهاجمين لاعتراض الرموز المميزة. إن تخصيص الوقت لرسم خريطة لكل منصة سيعمل عليها تطبيقك، مع عناوين URI لإعادة التوجيه المقابلة لها، يساعد على ضمان مصادقة سلسة وطمأنينة.

تذكّر تحديث تسجيل تطبيقك كلما غيّرت عناوين URL الخاصة بالعميل، أو أضفت منصات، أو وسّعت البيئات (مثل بيئة الاختبار وبيئة الإنتاج). إن إبقاء عناوين URI هذه محمية ومنظمة هو الخطوة الأولى للحفاظ على تدفق الرموز المميزة محكماً.

أساسيات تدفقات OAuth وإدارة الرموز المميزة

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

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

إدارة الرموز المميزة لا تقتصر على التعامل مع تواريخ الانتهاء، بل تتعلق بالحفاظ على أمانها في كل مرحلة. ويشمل ذلك استخدام اتصال آمن (مثل HTTPS)، وعدم كشف الأسرار أبداً في التعليمات البرمجية الجانبية للعميل، وتطبيق مبدأ أقل الامتيازات عند طلب النطاقات (Scopes).

يهيّئ هذا القسم لفهم كيفية تعامل OAuth مع عمليات التواصل الحاسمة بين المستخدمين والتطبيقات والمنصات، وكيف تدعم إدارة الرموز المميزة المتينة سير عمل مستمراً وآمناً للمستخدمين النهائيين والأنظمة الآلية على حد سواء.

تنفيذ تدفق رمز تفويض OAuth

1. بدء التفويض: يعيد تطبيقك توجيه المستخدم إلى نقطة نهاية التفويض في Entra ID، متضمناً تفاصيل مثل معرّف العميل (Client ID)، والنطاقات المطلوبة، ومعامل state فريداً وعشوائياً للحماية من تزوير الطلبات عبر المواقع (CSRF).
2. منح الإذن: يراجع المستخدم شاشة الموافقة، التي توضح بجلاء الأذونات التي يحتاجها تطبيقك، ثم يوافق على الوصول.
3. استلام رمز التفويض: بعد الموافقة، يعيد Entra ID توجيه المستخدم إلى معرّف الإعادة (redirect URI) الذي حددته، ويمرّر معه رمز تفويض مؤقتًا وقيمة state التي ضبطتها في البداية.
4. استبدال الرمز بالرموز المميزة: يرسل الخادم الخلفي لتطبيقك الرمز بأمان، مع بيانات اعتماد العميل الخاصة بك (وكذلك PKCE code verifier إن كنت تستخدمه)، إلى نقطة نهاية الرموز المميزة في Entra. وعند التحقق، تحصل على رمز وصول (access token) وغالبًا رمز تحديث (refresh token).
5. استخدام الرموز للوصول إلى واجهات برمجة التطبيقات: يرفق تطبيقك الآن رمز الوصول بكل طلب إلى واجهة برمجة التطبيقات، ليثبت التفويض نيابةً عن المستخدم. رموز الوصول صالحة لمدة قصيرة فقط للحد من التعرض للخطر، بينما تُستخدم رموز التحديث للحصول على رموز وصول جديدة للجلسات المستمرة.

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

أفضل الممارسات لإدارة انتهاء صلاحية رموز الوصول ورموز التحديث

1. تخزين الرموز بأمان: استخدم وسائل التخزين الآمنة التي يوفرها نظام التشغيل، مثل Keychain على iOS وKeystore على Android، أو مديري الأسرار المشفّرة على الخادم. لا تضمّن الرموز المميزة أبدًا في ملفات التطبيق الثنائية، ولا تعرضها في السجلات (logs).
2. احترام مدد صلاحية الرموز: راقب قيمة انتهاء الصلاحية (exp claim) في كل رمز، وقم بالتحديث بشكل استباقي قبل انتهائه لتجنب إخفاق طلبات واجهة البرمجة وسوء تجربة المستخدم.
3. دعم تدوير الرموز (token rotation): استخدم دائمًا أحدث رمز تحديث في كل طلب، وتخلص بسرعة من الرموز المُعاد استخدامها أو القديمة. هذا يحدّ من الأثر إذا تعرّض رمز للاختراق.
4. تقييد الأذونات لكل رمز: اطلب فقط النطاقات (scopes) التي تحتاجها، وفضّل رموز الوصول قصيرة العمر. هذا يقلل الضرر بشكل كبير إذا تسرّب رمز أو سُرق.

تأمين تطبيقات OAuth في سياقات مختلفة

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

تقنيات مثل PKCE (Proof Key for Code Exchange) تُحكم تأمين تدفق الرموز للعملاء العامين، فتمنع المهاجمين من اعتراض الرموز واستبدالها بالرموز المميزة. أما التطبيقات التي تعمل في بيئات آمنة، فتصبح الأسرار (client secrets) والشهادات أدواتك الأفضل لإثبات الهوية وإدارة الثقة.

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

فيما يلي استراتيجيات مجرّبة ومثبتة الفعالية في مواجهة التهديدات الشائعة، وفي تهيئة إعداد OAuth لديك لتوفير حماية قوية لجميع أنواع التطبيقات والبيئات.

كيف يحمي PKCE تفويض OAuth في العملاء العامين

يُعد PKCE (Proof Key for Code Exchange) ضروريًا عند استخدام OAuth في تطبيقات الهاتف والتطبيقات المعتمدة على المتصفح، أي العملاء العامين (public clients) الذين لا يمكن فيهم تخزين سرّ بأمان. عند بدء تدفق رمز التفويض، يولّد تطبيقك "code verifier" عشوائيًا و"code challenge" مُجزّأً (hashed). تنتقل هذه القيم مع المستخدم وصولًا إلى طلب الرمز المميز النهائي. وحتى لو تمكن المهاجم من التقاط رمز تفويض، فلن يستطيع استبداله برمز مميز دون هذا السرّ المتمثل في code verifier، مما يجعل هجمات اعتراض الرموز شبه مستحيلة على Microsoft Entra ID والمنصات المشابهة.

إدارة الأسرار والشهادات والاعتمادات الموحّدة (Federated Credentials)

• الأسرار (Client Secrets): تستخدمها التطبيقات السرّية (confidential apps)، مثل الخدمات الخلفية الموثوقة، لإثبات هويتها أمام نقطة نهاية الرموز المميزة. خزّن الأسرار في خزائن آمنة، وقم بتدويرها بانتظام، ولا تشحنها أبدًا ضمن كود التطبيق على جهة العميل.
• الشهادات: لتحقيق مستوى أعلى من الضمان، استخدم شهادات X.509 بدلًا من الأسرار العادية لتعزيز أمان معرّفات تطبيقك. تتيح الشهادات التحقق بشكل أكثر أمانًا عبر أزواج المفاتيح العامة والخاصة، وهي مثالية للقطاعات الخاضعة للتنظيم أو التطبيقات ذات متطلبات الامتثال الصارمة.
• الاعتمادات الموحّدة (Federated Credentials): لإعدادات "أحضر هويتك الخاصة" (bring your own identity)، استخدم الاعتمادات الموحّدة مثل الهوية الموحّدة في Microsoft Entra أو مزودي الهوية الخارجيين. يتيح ذلك المصادقة دون التعامل مع الأسرار بشكل مباشر، مما يقلل العبء الإداري.
• معالجة خطوط الأنابيب (Pipeline Handling): في سير عمل CI/CD، أدرج الأسرار والشهادات وبدّلها عند الحاجة، ولا تُضمّنها أبدًا في نظام التحكم بالمصادر. وتضيف تنبيهات انتهاء الصلاحية الآلية طبقة إضافية من المرونة.

تأمين الرموز المميزة وتقليل تعرّض الصلاحيات

• خزِّن الرموز المميزة في مواقع آمنة فقط (مخازن أنظمة التشغيل، أو بيئات الخوادم المشفّرة)، ولا تخزّنها أبدًا في مساحة تخزين يمكن للمستخدم الوصول إليها.
• أرسل الرموز المميزة دائمًا عبر HTTPS أو قنوات آمنة، فبروتوكول HTTP غير المشفّر يعرّضها للاعتراض.
• اطلب الحد الأدنى من الأذونات («النطاقات») لكل رمز مميز، ولا تطلب أبدًا أكثر مما يحتاجه تطبيقك.
• راجِع استخدام الرموز المميزة وتعيينات الصلاحيات بانتظام لمنع تراكم الأذونات دون أن ينتبه أحد إليه.

أفضل الممارسات لاستخدام OAuth في التطبيقات المحمولة والأصلية

تواجه التطبيقات المحمولة والأصلية اليوم تحديات فريدة: فالأجهزة قد تُفقد، والتطبيقات تتشارك مساحة التخزين، والمستخدمون يتوقعون تسجيل دخول سريعًا يكاد يكون غير مرئي. لذلك يُحدث اتباع أفضل ممارسات OAuth على iOS وAndroid وأجهزة سطح المكتب، باستخدام حزم SDK المدمجة وآليات التخزين المثبتة الفعالية، فرقًا كبيرًا.

تتولى حزمة SDK المناسبة (مثل MSAL لـ Microsoft Entra ID) الكثير من العمل الشاق، كإدارة الرموز المميزة ومنطق التجديد والتكامل مع وحدة التخزين الآمن على مستوى نظام التشغيل. وبالنسبة إلى الرموز الحساسة، تحدد هذه الحزم أكثر مستودعات التخزين أمانًا تلقائيًا، مع مراعاة الخصائص الخاصة بالجهاز أو نظام التشغيل.

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

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

الروابط الشاملة ومصادقة الجهات الأولى الأصلية

تجعل الروابط الشاملة (على iOS) ومخططات التطبيقات (على Android) مصادقة المستخدم أكثر أمانًا. فباستخدام روابط يتحقق منها نظام التشغيل ومرتبطة بهوية تطبيقك، تمنع التطبيقات الخبيثة من اعتراض عمليات إعادة التوجيه الخاصة بتسجيل الدخول والاستيلاء على رموز مميزة ليست لها. كما تعتمد المصادقة الأصلية على متصفحات النظام الموثوقة، فيسجّل المستخدم الحقيقي دخوله بنفسه، وبذلك يُستبعد التصيّد، والتنصّت على الرموز المميزة، وتسجيلات الدخول العرضية عبر تطبيقات غير ذات صلة. وبالجمع بين هذه الأدوات، يحصل المستخدمون على تجربة سلسة وآمنة تكاد تكون منيعة أمام تهديدات OAuth الشائعة على الأجهزة المحمولة.

استكشاف أخطاء OAuth وإصلاحها والسيناريوهات المتقدمة

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

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

مع الإرشادات المتعلقة بالإخفاقات الشائعة والحالات المتقدمة، ستكون أكثر قدرة على استكشاف أخطاء حلول OAuth المتينة وتصميمها وصيانتها، حتى مع تزايد تعقيد منظومة تطبيقاتك.

سواء كنت تبحث عن خطأ عنيد في نقطة نهاية الرموز المميزة، أو تُعدّ تطبيقك لمواجهة تحديات الواقع (حيث الأجهزة محدودة الإدخال والخدمات بدون واجهة منتشرة في كل مكان)، فستساعدك هذه الرؤى على إبقاء تكاملاتك سلسة وآمنة.

فك ترميز استجابات أخطاء OAuth وإخفاقات تبادل الرموز

• عنوان URI لإعادة التوجيه غير صالح: يحدث عندما لا يتطابق عنوان إعادة التوجيه مع القائمة المسجّلة؛ تحقّق جيدًا من المدخلات وحالة الأحرف.
• رمز التفويض منتهي الصلاحية: يتأخر المستخدمون أحيانًا، أو يُعاد استخدام الرموز؛ استخدمها دائمًا مرة واحدة فقط وبسرعة بعد استلامها.
• عدم تطابق بيانات اعتماد العميل: تم تقديم سر أو شهادة خاطئة؛ تحقّق من بيانات الاعتماد وقم بتدويرها عند الحاجة.
• نطاق أو مورد غير صالح: الواجهة البرمجية المطلوبة أو النطاقات غير مسموح بها أو مكتوبة بشكل خاطئ؛ تحقّق من الإعدادات وأذونات التطبيق.

حسابات الخدمة وأجهزة الإدخال المحدود وامتدادات OAuth

• حسابات الخدمة (تدفق بيانات اعتماد العميل): تتيح للتطبيقات المصادقة دون مستخدم، وهي مثالية للأتمتة ومهام الخادم إلى الخادم.
• تدفق رمز الجهاز: مخصّص للتلفزيونات الذكية وأجهزة إنترنت الأشياء، إذ يطلب من المستخدمين إتمام الخطوة على جهاز آخر؛ وهو مناسب حيث لا يتوفر متصفح.
• امتداد TLS المتبادل: يستخدم الشهادات للخادم والعميل معًا، ما يعزز الأمان للتكاملات الحساسة ويضمن أن التطبيق يستخدم طرق مصادقة قوية.
• التسجيل الديناميكي للعملاء: يؤتمت تهيئة التطبيقات في أنظمة SaaS الكبيرة أو متعددة المستأجرين، مما يبسّط إدارة بيانات الاعتماد على نطاق واسع.

دليل تسجيل التطبيقات وOAuth في Entra ID

الإيجابيات

• إدارة هويات مركزية: تتكامل مع Microsoft Entra ID لتوفير هوية متسقة للمستخدمين والتطبيقات عبر الخدمات.
• ضوابط أمان قوية: تدعم OAuth 2.0 وOpenID Connect والوصول المشروط والأذونات الدقيقة (النطاقات والأدوار).
• بروتوكولات معيارية في الصناعة: تعتمد على معايير OAuth وOIDC واسعة الدعم، مما يبسّط التوافق مع الأدوات والمكتبات التابعة لجهات خارجية.
• تهيئة تفصيلية للتطبيقات: تتيح ضبط عناوين إعادة التوجيه والشهادات والأسرار وأذونات واجهات برمجة التطبيقات وخيارات العلامة التجارية للتطبيقات.
• نموذج موافقة دقيق: يدعم الأذونات المفوّضة وأذونات التطبيقات، مع تدفقات موافقة المسؤول للحد من التطبيقات ذات الأذونات الزائدة.
• ميزات للمؤسسات: تدعم التطبيقات متعددة المستأجرين وتعاون B2B والتكامل مع Microsoft 365 وخدمات Azure.
• المراقبة والتدقيق: سجلات مدمجة وعمليات تسجيل دخول ومسارات تدقيق لتسجيلات التطبيقات وتدفقات OAuth، للمساعدة في الامتثال واستكشاف الأخطاء وإصلاحها.
• أدوات المطورين وحزم SDK: حزم SDK واسعة لمنصة هوية Microsoft، وتوثيق وعينات بدء سريع تسهّل التنفيذ.

السلبيات

• صعوبة على المبتدئين: قد تكون نماذج التهيئة والأذونات (عناوين إعادة التوجيه وعناوين الرد وتدفقات Implicit مقابل Authorization Code والنطاقات) مربكة للمطورين الجدد.
• منحنى تعلّم حادّ لميزات الأمان: تتطلب إعدادات الوصول المشروط والهويات المُدارة وإعدادات الرموز المتقدمة معرفة أمنية أعمق لضبطها بأمان.
• خطر تضخم الأذونات: قد يؤدي الموافقة غير السليمة أو الأذونات الواسعة للتطبيقات إلى تطبيقات ذات أذونات زائدة إذا لم تُراجع بانتظام.
• دقائق إدارة الرموز المميّزة: إدارة رموز التحديث ومدد صلاحية الرموز وإبطالها تحمل سلوكاً خاصاً بكل منصة، وقد يسبب ذلك مشكلات في التكامل.
• اعتبارات حدود المستأجر: يضيف سلوك التطبيقات متعددة المستأجرين ومطالبات موافقة المسؤول تعقيداً تشغيلياً في سيناريوهات عبر المستأجرين.
• تغييرات في الواجهة والمصطلحات: تحدّث Microsoft واجهة Entra وتسمياته بين فترة وأخرى (Azure AD ← Entra ID)، مما قد يسبب عدم تطابق في التوثيق أو التباساً.
• الاعتماد على منظومة Microsoft: الارتباط الوثيق بميزات Entra ID قد يحدّ من إمكانية النقل إلى مزودي هوية غير تابعين لـ Microsoft دون إعادة عمل.
• احتمال الإعداد الخاطئ: قد تُنشئ إعدادات تسجيل التطبيق غير الصحيحة (مثل عناوين إعادة التوجيه وعناوين الرد وإعدادات تدفق Implicit) ثغرات أمنية أو تعطّل تدفقات المصادقة.

الخطوات التالية والمصادر المجتمعية الأساسية للنجاح في OAuth

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

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

هل أنت راضٍ عن تسجيل تطبيقك؟ جيد. الآن تعرّف على ما يبتكره الآخرون في الميدان. تصفّح منتديات المطورين ولوحات النقاش الرسمية، وألقِ نظرة على مستودعات GitHub الخاصة بمكتبات المصادقة. إذا واجهت عائقاً، فمن المرجح أن شخصاً آخر قد حلّ مشكلتك نفسها، أو على الأقل اشتكى منها بصوت عالٍ يكفي ليجيب عنها أحد.

إذا كنت ممن يحبون التجربة والتعلم بالممارسة، فاطلع على التجارب المجانية المتاحة وحسابات الاختبار وميزات المعاينة العامة. تتيح لك هذه الأدوات كسر الأشياء (بأمان) واكتشاف ما ينجح قبل طرح التغييرات على مستخدميك الفعليين. ولا تنسَ أن OAuth والأمان جهدٌ مجتمعي، فشارك إنجازاتك وأسئلتك، فذلك يُبقي المنظومة كلها شفافة ونامية، ويساعد الجميع على فهم آلية عمل OAuth.

قائمة مراجعة دليل تسجيل التطبيقات وOAuth - Entra ID

• خطِّط لنوع التطبيق ونموذج الوصول: اختر بين مستأجر واحد أو متعدد المستأجرين أو حسابات Microsoft شخصية، وحدِّد ما إذا كان التطبيق SPA أو تطبيق ويب أو تطبيق جوال أو daemon أو تطبيق خدمة.
• تسجيل التطبيق في Entra ID: أنشئ تسجيل تطبيق جديد (App Registration) باسم واضح، وحدّد أنواع الحسابات المدعومة.
• تكوين معرّفات URI لإعادة التوجيه: أضف معرّفات URI صحيحة لإعادة التوجيه أو الاستدعاء لكل منصة (https، أو مخطط مخصص، أو localhost للتطوير).
• ضبط إعدادات منصة التطبيق: فعّل خيارات منصة SPA والويب والجوال وسطح المكتب، وكوّن تدفقات implicit أو منح الأذونات حسب الحاجة.
• إنشاء البيانات السرية للعميل وإدارتها: أنشئ بيانات سرية للعملاء السريين، وسجّل تاريخ انتهاء صلاحيتها، وخزّنها بأمان في Key Vault.
• استخدام الشهادات للمصادقة: ارفع شهادات المفتاح العام للعملاء السريين في بيئة الإنتاج بدلًا من الأسرار طويلة الأمد.
• تكوين أذونات واجهة برمجة التطبيقات: أضف النطاقات والأذونات المطلوبة من Microsoft Graph أو من واجهات برمجة التطبيقات المخصصة التي يحتاجها التطبيق.
• منح موافقة المسؤول عند الحاجة: اطلب موافقة المسؤول على الأذونات المفوَّضة التي تتطلب موافقة على مستوى المستأجر، وسجّل هذه الموافقة.
• تعريف النطاقات المخصصة وإتاحتها (في حال كان التطبيق واجهة برمجة تطبيقات): أضف نطاقات ضمن "Expose an API"، وحدّد أسماء النطاقات وأوصافها وأسماء العرض الخاصة بموافقة المسؤول.
• إعداد أدوار التطبيق عند الحاجة: حدّد أدوار التطبيق والأدوار المفوَّضة للتحكم في الوصول القائم على الأدوار، وعيّنها للمستخدمين أو المجموعات أو تطبيقات العملاء.
• تكوين CORS لتطبيقات SPA التي تستدعي واجهات برمجة التطبيقات: أضف المصادر المسموح بها على واجهة برمجة التطبيقات، أو كوّن نهج CORS في البوابة.
• اختيار تدفق OAuth 2.0: اختر Authorization Code (مع PKCE للعملاء العامين)، أو Client Credentials للتطبيقات الخدمية (daemon)، أو Device Code حسب الحالة.
• تطبيق PKCE للعملاء العامين: فعّل Proof Key for Code Exchange لتطبيقات SPA والتطبيقات الأصلية لمنع اعتراض رمز التفويض.
• التحقق من الرموز المميزة بشكل صحيح: تحقّق من المُصدِر والجمهور المستهدف والتوقيع وتاريخ الانتهاء والمطالبات (Claims) المطلوبة، باستخدام مكتبات الهوية من Microsoft أو منطق التحقق من JWT.
• استخدام مكتبات المصادقة من Microsoft (MSAL): فضّل MSAL للحصول على الرموز المميزة وتخزينها مؤقتًا وتجديدها والتعامل معها بأمان عبر المنصات.
• تكوين الوصول المشروط والمصادقة متعددة العوامل (MFA) عند الحاجة: طبّق النهج على تسجيل التطبيق أو على تدفقات تسجيل دخول المستخدمين لفرض ضوابط الأمان.
• مراقبة عمليات تسجيل الدخول وسجلات التدقيق: فعّل التسجيل وراجع أحداث تسجيل الدخول والموافقات وعمليات المسؤول في سجلات Entra ID.
• تطبيق مبدأ أقل امتياز في الأذونات: اطلب الأذونات اللازمة فقط، وفضّل الموافقة التدريجية لتقليل التعرض للمخاطر.
• تدوير الأسرار والشهادات بانتظام: طبّق التدوير الآلي والتنبيهات للبيانات الاعتمادية التي قاربت على الانتهاء.
• تأمين الشيفرة وأماكن التخزين من جهة العميل: تجنّب تخزين الأسرار في تطبيقات العميل، واستخدم تخزينًا آمنًا وأفضل ممارسات كل منصة.
• اختبار تدفقات تسجيل الدخول والرموز المميزة في بيئتي التطوير والتجهيز: تحقّق من تدفقات المصادقة، ومدد صلاحية الرموز، ومنطق التجديد، ومعالجة الأخطاء، وتجربة الموافقة.
• إعداد التوثيق للمستخدمين والمسؤولين: ضمّنه خطوات الموافقة، والأذونات المطلوبة، وإرشادات استكشاف الأخطاء وإصلاحها.
• مراجعة تسجيلات التطبيقات وتحديثها بشكل دوري: دقّق الأذونات والأدوار والأسرار والتسجيلات بحثًا عن التطبيقات القديمة أو غير المستخدمة.
• تطبيق حماية الشبكة وواجهات برمجة التطبيقات: فكّر في API Management وWAF وتحديد معدل الطلبات ونقاط نهاية الخدمة لحماية واجهات برمجة التطبيقات الخلفية.

الوصول إلى رموز Azure المميزة واستخدام OAuth والمصادقة

ما هو دليل تسجيل التطبيقات وOAuth، ولماذا هو مهم؟

يشرح دليل تسجيل التطبيقات وOAuth كيفية تسجيل تطبيق عميل لدى موفّر الهوية (على سبيل المثال باستخدام Azure)، وتطبيق تدفقات تفويض OAuth 2.0 حتى يتمكن تطبيقك من طلب الوصول إلى الموارد المحمية بأمان. وهذا أمر بالغ الأهمية سواء كنت تبني تطبيقات ويب أو تطبيقات صفحة واحدة (SPA) أو تطبيقات سطح مكتب أو واجهات خلفية لخوادم الويب، لأن التطبيق يحتاج إلى معرّف التطبيق (application ID) ومعرّف العميل (client ID) والبيانات السرية للعميل (للعملاء السريين) للحصول على رمز الوصول، واستلام رمز الهوية عند الاقتضاء.

كيف أسجّل تطبيق Azure وأحصل على معرّف التطبيق (application ID)؟

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

أي تدفق تفويض OAuth 2.0 ينبغي أن أستخدم لتطبيقات الصفحة الواحدة (SPA)؟

يجب أن تستخدم تطبيقات الصفحة الواحدة (Single-page apps) منحة رمز التفويض مع PKCE (Proof Key for Code Exchange) بدلاً من التدفق الضمني (implicit flow)، لضمان أن يكون التطبيق الذي يحصل على الرموز المميزة آمناً. تتيح منحة الرمز مع PKCE للتطبيق استبدال الرمز برمز وصول (access token) بشكل آمن من عميل يعمل في المتصفح، فتتيح لتطبيقات الصفحة الواحدة استخدام OAuth مع تجنب كشف الأسرار السرية للعميل (client secrets) داخل المتصفح.

كيف يعمل طلب التفويض، وما المعلمات المطلوبة؟

يُرسل طلب التفويض إلى نقطة نهاية التفويض (authorization endpoint) لموفر الهوية، ويتضمن عادةً client_id (معرّف التطبيق)، وresponse_type (مثل code)، وredirect_uri، وscope، وstate. بالنسبة لتطبيقات الصفحة الواحدة التي تستخدم منحة الرمز مع PKCE، تُضاف أيضاً المعلمتان code_challenge وcode_challenge_method. يصادق المستخدم ويمنح الموافقة (OAuth consent)، ثم يعيد خادم التفويض رمزاً إلى redirect URI، ويمكن للتطبيق استبداله برمز وصول.

كيف أكتب الكود لاستبدال الرمز برمز وصول (code for an access token)؟

بعد استلام رمز التفويض، يرسل تطبيق العميل طلباً إلى نقطة نهاية الرموز المميزة (token endpoint) يتضمن الرمز، وclient_id (وclient_secret للتطبيقات السرية)، وredirect_uri، وgrant_type=authorization_code. في حالة PKCE، تُضاف المعلمة code_verifier. تعيد نقطة النهاية رمز الوصول، ورمز الهوية (id token) عند طلبه، وربما رمز التحديث (refresh token) للحصول على رمز وصول جديد عند انتهاء صلاحية الرمز الحالي.

كيف أحصل على رمز الوصول (access token) وأستخدمه لاستدعاء واجهات برمجة التطبيقات (APIs)؟

احصل على رمز الوصول بإكمال تدفق OAuth 2.0 المختار واستدعاء نقطة نهاية الرموز المميزة. بعد الحصول على رمز الوصول، أرسله في ترويسة Authorization بالصيغة Bearer عند استدعاء خدمات Microsoft أو واجهات برمجة تطبيقات أخرى (مثل Google Calendar أو واجهات البرمجة المخصصة). تحقّق من الرموز المميزة على خادم الويب أو على جانب المورد (resource) للتأكد من أن طلبات التطبيق مصرّح بها.

ماذا أفعل عند انتهاء صلاحية رمز الوصول، وكيف أحصل على رمز تحديث (refresh token) جديد؟

عند انتهاء صلاحية رمز الوصول، استخدم رمز التحديث (إن توفّر) لطلب رمز وصول جديد من نقطة نهاية الرموز المميزة باستخدام grant_type=refresh_token. قد تُصدر بعض التدفقات أو الموفرين رمز تحديث جديداً عند التحديث، بينما قد يعيد آخرون استخدام رمز التحديث نفسه. وإذا لم يكن رمز التحديث متاحاً (في العملاء العامين أو التدفقات قصيرة العمر)، فأعد توجيه المستخدم إلى تطبيقك لإجراء طلب تفويض جديد.

هل أحتاج إلى تسجيلات تطبيقات منفصلة لتطبيقات الويب وتطبيقات الجوال أو سطح المكتب؟

غالباً ما تحتاج إلى تسجيلات تطبيقات منفصلة عندما تختلف أنواع التطبيقات اختلافاً كبيراً (مثل خادم الويب التقليدي مقابل تطبيقات الصفحة الواحدة مقابل تطبيقات سطح المكتب)، لأن redirect URIs والأسرار السرية للعميل (client secrets) والتدفقات المسموح بها تختلف بينها. يتيح لك فصل التسجيلات ضبط تدفقات التفويض وredirect URIs الخاصة بكل نوع من التطبيقات.

ما الفرق بين تسجيل التطبيق للعميل والتطبيق في المستأجر؟

يشير تسجيل التطبيق للعميل إلى إدخال التسجيل المحدد لدى موفر الهوية (تطبيق Azure)، والذي يحتفظ بإعدادات مثل redirect URIs والأسرار السرية. أما التطبيق في المستأجر فيعني أن التسجيل موجود في مستأجر Azure AD معيّن، ويمكن تعيين الأدوار والأذونات له داخل ذلك المستأجر. يمكن أن يكون تسجيل التطبيق الواحد متعدد المستأجرين (multi-tenant) أو أحادي المستأجر (single-tenant) حسب احتياجاتك.

كيف أطلب الوصول إلى خدمات Microsoft، وما الأذونات المطلوبة؟

اطلب الوصول بتحديد النطاقات (scopes) التي يحتاجها تطبيقك في طلب التفويض. بالنسبة لخدمات Microsoft، اضبط أذونات واجهات البرمجة (API permissions) في تسجيل تطبيق Azure، ثم اطلب من المستخدمين منح الموافقة (OAuth consent) أو اطلب من المسؤول منح الموافقة على مستوى المستأجر بالكامل. يطلب التطبيق نطاقات مثل User.Read أو نطاقات واجهات برمجة مخصصة ضمن طلبات التطبيق، ثم يستخدم رمز الوصول لاستدعاء الخدمات.

كيف أؤمّن الأسرار السرية للعميل (client secrets) وأتجنب تسريب بيانات الاعتماد في تطبيقات الصفحة الواحدة؟

لا ينبغي لتطبيقات الصفحة الواحدة تخزين الأسرار السرية للعميل، لأن الشيفرة التي تعمل في المتصفح يمكن فحصها. استخدم منحة رمز التفويض مع PKCE حتى يتمكن التطبيق من الحصول على رمز وصول بأمان دون استخدام سر عميل. أما التطبيقات السرية (خوادم الويب)، فخزّن معرّف العميل والسر السري على جانب الخادم حيث لا يكونان مكشوفين للمستخدمين.

ما دور redirect URI، ولماذا يجب أن يتطابق مع تسجيل التطبيق؟

عنوان إعادة التوجيه (Redirect URI) هو الموقع الذي يرسل إليه مزود الهوية استجابة التفويض (الرمز أو الرمز المميز). يجب أن يطابق هذا العنوان عنوان إعادة التوجيه المسجّل في تسجيل التطبيق، وذلك لمنع اختطاف استجابة التفويض. استخدم المطابقة التامة أو الأنماط المسموح بها كما يحددها المزود؛ فأي اختلاف سيؤدي إلى فشل تبادل الرمز المميز.

كيف أجعل المستخدمين يتحققون من هويتهم ويستلمون رمز هوية (id token) إلى جانب رمز الوصول (access token)؟

لاستلام رمز الهوية (id token)، اطلب النطاق openid وأرسل قيمة response_type التي تؤدي إلى إصدار رمز الهوية (تدفق رمز التفويض مع openid). يحتوي رمز الهوية على المطالبات (claims) الخاصة بهوية المستخدم الذي تم التحقق منه. استخدم رمز الهوية لتسجيل دخول المستخدم إلى تطبيق العميل الخاص بك، واستخدم رمز الوصول لاستدعاء واجهات برمجة التطبيقات (APIs) اللاحقة.

ما تدفقات التفويض المحددة التي تنطبق على تطبيقات الويب التقليدية مقابل تطبيقات الصفحة الواحدة (SPA)؟

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

هل يمكن استخدام تسجيل تطبيق واحد لعدة تطبيقات عميلة، أم يجب إنشاء تسجيل تطبيق لكل تطبيق؟

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

كيف أتحقق من صحة الرموز المميزة في خادم الويب أو واجهة برمجة التطبيقات الخاصة بي؟

يجب أن يتحقق خادم الويب أو واجهة برمجة التطبيقات من التوقيع والمُصدِر والجمهور (معرّف التطبيق أو application id) وتاريخ انتهاء الصلاحية لرمز الوصول أو رمز الهوية. استخدم وثيقة الاكتشاف (discovery document) الخاصة بالمزود للحصول على مفاتيح التوقيع، واتبع مكتبات التحقق الموصى بها لمنصتك. يضمن التحقق قبول الطلبات الصادرة من تطبيقات مصادَق عليها ومصرَّح لها فقط.

ما خطوات طلب رمز وصول لخدمة خلفية باستخدام بيانات اعتماد العميل؟

في سيناريوهات الخادم إلى الخادم، سجّل تطبيقًا في Azure، ثم امنحه أذونات التطبيق، واستخدم بعد ذلك تدفق بيانات اعتماد العميل: أرسل طلب POST إلى نقطة نهاية الرمز المميز (token endpoint) مع grant_type=client_credentials وclient_id وclient_secret وscope/resource. تُعيد نقطة النهاية رمز وصول يمكن للخدمة الخلفية استخدامه لاستدعاء خدمات Microsoft أو واجهات برمجة التطبيقات المحمية.

كيف أتعامل مع موافقة OAuth والموافقة الإدارية للتطبيقات متعددة المستأجرين؟

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

ما خطوات استكشاف الأخطاء وإصلاحها التي ينبغي أن أتبعها إذا فشل طلب التفويض؟

تأكد من تسجيل التطبيق في بوابة Microsoft، ومن تطابق عنوان إعادة التوجيه، وصحة معرّف العميل والسر، وصلاحية النطاقات، وصحة نوع المنحة ومعاملات PKCE (إن استُخدمت). تحقق من رسائل الخطأ التي تُعيدها نقطة نهاية التفويض أو الرمز المميز، وراجع السجلات على جانب العميل والخادم معًا. يمكن أن تساعدك منصة Stack Overflow ووثائق المزود في فهم رموز الأخطاء المحددة.

كيف يمكنني دمج واجهات برمجة تطبيقات خارجية مثل تقويم Google مع التطبيق المسجل لدي؟

لدمج تقويم Google أو واجهات برمجة تطبيقات خارجية أخرى، نفّذ تدفقات تفويض OAuth 2.0 التي يتطلبها هذا المزود. يجب أن يطلب تطبيقك النطاقات الصحيحة لواجهة برمجة التطبيقات الخارجية، وأن يتعامل مع دورات حياة رموز منفصلة. قد تحتاج إلى تسجيلات تطبيقات عميلة منفصلة لدى كل مزود، وإلى تنسيق الحصول على رموز الوصول لكل خدمة.

متى ينبغي أن أستخدم تدفق رمز الجهاز (device code) أو تدفقات خاصة أخرى لأجهزة معينة؟

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