مقدمة عن OAuth 2.0

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info

الصفحة الرئيسية لبروتوكول OAuth: يمكنك الاطّلاع على الصفحة الرئيسية لبروتوكول OAuth للحصول على نظرة عامة على إرشادات OAuth التي نقدّمها .

يقدّم هذا الموضوع نظرة عامة أساسية على بروتوكول OAuth 2.0 على Apigee Edge.

ما هو بروتوكول OAuth 2.0؟

هناك العديد من الكتب والمدوّنات والمواقع الإلكترونية المخصّصة لبروتوكول OAuth 2.0. ننصحك بشدة بالبدء بمراجعة مواصفات IETF OAuth 2.0. في ما يلي تعريف بروتوكول OAuth 2.0 من مواصفات IETF OAuth 2.0 نفسها:

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

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

مسار OAuth 2.0

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

المصطلحات التي يجب معرفتها

• العميل: يُعرف أيضًا باسم "التطبيق". يمكن أن يكون تطبيقًا يعمل على جهاز جوّال أو تطبيق ويب تقليديًا. يرسل التطبيق طلبات إلى خادم الموارد للحصول على مواد عرض محمية نيابةً عن مالك المورد. يجب أن يمنح مالك المورد التطبيق إذن الوصول إلى الموارد المحمية.
• مالك المورد: يُعرف أيضًا باسم "المستخدم النهائي". هذا هو الشخص (أو الكيان الآخر) القادر بشكل عام على منح إذن الوصول إلى مورد محمي. على سبيل المثال، إذا كان أحد التطبيقات بحاجة إلى استخدام بيانات من أحد مواقع التواصل الاجتماعي، فأنت مالك المورد، وهو الشخص الوحيد الذي يمكنه منح التطبيق إذن الوصول إلى بياناتك.
• خادم الموارد: يمكنك اعتبار خادم الموارد خدمة مثل Facebook أو Google أو Twitter، أو خدمة الموارد البشرية على شبكة الإنترانت، أو خدمة شريك على شبكة الإكسترانت بين الشركات. يكون Apigee Edge خادم موارد عندما يكون التحقق من صحة رمز OAuth المميز مطلوبًا لـ معالجة طلبات واجهة برمجة التطبيقات. يحتاج خادم الموارد إلى نوع من التفويض قبل أن يعرض الموارد المحمية للتطبيق.
• خادم التفويض: يتم تنفيذ خادم التفويض بما يتوافق مع مواصفات OAuth 2.0، وهو مسؤول عن التحقق من صحة منح التفويض وإصدار رموز الدخول التي تمنح التطبيق إذن الوصول إلى بيانات المستخدم على خادم الموارد. يمكنك ضبط "نقاط نهاية الرموز المميزة" على Apigee Edge، وفي هذه الحالة، يتولى Edge دور خادم التفويض.
• منح التفويض: يمنح التطبيق إذن استرداد رمز دخول نيابةً عن المستخدم النهائي. يحدّد بروتوكول OAuth 2.0 أربعة "أنواع منح" محدّدة. يمكنك الاطّلاع على "ما هي أنواع منح OAuth 2.0" أدناه.
• رمز الدخول: سلسلة طويلة من الأحرف تُستخدم كبيانات اعتماد للوصول إلى الموارد المحمية. يمكنك أيضًا الاطّلاع على "ما هو رمز الدخول؟" أدناه.
• المورد المحمي: البيانات التي يملكها مالك المورد. على سبيل المثال، الـ قائمة جهات الاتصال الخاصة بالمستخدم أو معلومات الحساب أو غير ذلك من البيانات الحساسة.

دور Apigee Edge

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

توفر Apigee سياسة OAuthV2 متعددة الجوانب تنفذ تفاصيل كل نوع منح، ما يسهل نسبيًا إعداد بروتوكول OAuth على Apigee Edge. على سبيل المثال، يمكنك ضبط سياسة تتلقّى طلبًا لرمز دخول، وتقيِّم جميع بيانات الاعتماد المطلوبة، وتعرض رمز دخول إذا كانت بيانات الاعتماد صالحة.

يُرجى العِلم أنّ أي خوادم موارد تتصل بها واجهة برمجة التطبيقات الآمنة التي يتم توجيهها من خلال الخادم الوكيل يجب أن تكون محمية بجدار حماية (أي يجب ألا يكون من الممكن الوصول إلى الموارد بأي وسيلة أخرى غير الخادم الوكيل لواجهة برمجة التطبيقات أو واجهة برمجة تطبيقات أخرى آمنة بشكل جيد).

ما هي أنواع منح OAuth 2.0 ؟

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

يتوافق Apigee Edge مع أربعة أنواع رئيسية من منح OAuth 2.0:

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

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

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

ما هو رمز الدخول ؟

رمز الدخول هو سلسلة طويلة من الأحرف تُستخدم كبيانات اعتماد للوصول إلى الموارد المحمية. يتم تمرير رموز الموارد (المعروفة أيضًا باسم رموز حامل الأذونات) في عناوين Authorization ، على النحو التالي:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

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

تنتهي صلاحية رموز الدخول بشكل عام (لأسباب أمنية). تسمح بعض أنواع المنح لـ خادم التفويض بإصدار الرمز المميز لإعادة التحميل، ما يتيح للتطبيق جلب رمز دخول جديد عند انتهاء صلاحية الرمز القديم. لمزيد من التفاصيل حول رموز الدخول وإعادة الإنشاء، يُرجى الرجوع إلى مواصفات IETF OAuth 2.0.

وصول محدود من خلال النطاقات

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

تسجيل تطبيق

يجب تسجيل جميع العملاء (التطبيقات) على خادم تفويض OAuth 2.0 الذي ينوون طلب رموز الدخول منه. عند تسجيل تطبيق، تتلقّى مجموعة من المفاتيح. أحدها هو مفتاح علني يُعرف باسم معرّف العميل، والآخر هو مفتاح سري يُعرف باسم سر العميل. بدون هذه المفاتيح، لا يمكن للتطبيق إصدار طلبات رموز تفويض أو رموز دخول إلى خادم التفويض. يُرجى العِلم أنّه على الرغم من أنّ مواصفات IETF OAuth تسمّي هذه المفاتيح معرّف العميل وسر العميل، فإنّ واجهة مستخدم Apigee Edge تسمّيها رقم تعريف المستهلك وسر المستهلك. وهما متطابقان.

ملخّص حالات استخدام OAuth 2.0

يعتمد مسار نوع منح OAuth 2.0 الذي اخترت تنفيذه على حالة الاستخدام المحدّدة، لأنّ بعض أنواع المنح أكثر أمانًا من غيرها. يعتمد اختيارك لأنواع المنح على مدى موثوقية تطبيق العميل ويتطلب دراسة متأنية للغاية، كما هو موضّح في الجدول التالي:

مقارنة بين بروتوكول OAuth 2.0 وأمان مفتاح واجهة برمجة التطبيقات

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

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

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

المراجع المقترَحة

القراءة

يمكنك الاطّلاع على مقالة لمحة عن بروتوكول OAuth 2.0.