مقدمة عن OAuth 2.0

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

صفحة OAuth الرئيسية: راجع صفحة OAuth الرئيسية للحصول على عرض عالي المستوى لإرشادات OAuth التي التي تقدّمها.

يوفر هذا الموضوع نظرة عامة أساسية على OAuth 2.0 في Apigee Edge.

ما هو OAuth 2.0؟

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

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

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

مسار OAuth 2.0

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

بنود يجب معرفتها

• العميل: يُعرف أيضًا باسم "التطبيق". يمكن أن يكون تطبيقًا يعمل على هاتف محمول جهاز أو تطبيق ويب تقليدي. يرسل التطبيق طلبات إلى خادم الموارد للحصول على حماية الأصول نيابةً عن مالك المورد. يجب أن يمنح مالك المورد التطبيق إذنًا الوصول إلى الموارد المحمية.
• مالك المورد: يُعرف أيضًا باسم "المستخدم النهائي". هذا بشكل عام هو شخص (أو كيان آخر) القادر على منح حق الوصول إلى مورد محمي. بالنسبة على سبيل المثال، إذا احتاج تطبيق ما إلى استخدام بيانات من أحد مواقع التواصل الاجتماعي الخاصة بك، فأنت مالك المورد -- وهو الشخص الوحيد الذي يمكنه منح التطبيق حق الدخول إلى بياناتك.
• خادم الموارد: يمكن اعتبار خادم الموارد خدمة مثل Facebook أو Google أو Twitter؛ أو خدمة الموارد البشرية على شبكتك الداخلية؛ أو خدمة شريك على شبكة B2B الإضافية. 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.

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

ما المقصود بالوصول رمز مميز؟

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

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

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

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

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

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

تسجيل تطبيق

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

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

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

حالة الاستخدام	الموثوقية	أنواع منح تفويض OAuth 2.0 المقترَحة	الوصف
B2B (extranet)، إنترانت، غير ذلك	التطبيقات الموثوق بها للغاية التي كتبها مطوّرون داخليون أو مطوّرو برامج علاقة تجارية بمزود واجهة برمجة التطبيقات. التطبيقات التي تحتاج إلى الوصول إلى الموارد بنفسها.	بيانات اعتماد العميل	وعادةً ما يكون التطبيق أيضًا هو مالك المورد يجب توفّر Client-ID ومفاتيح سرية للعميل. يجب تسجيل التطبيق لدى مقدِّم الخدمة.
مواقع الشبكة الداخلية والبوابات	التطبيقات الموثوق بها التي كتبها مطورون داخليون أو موثوق بهم تابعون لجهات خارجية. وخير مثال على ذلك هو تسجيل الدخول إلى موقع الموارد البشرية لشركتك لإجراء اختيارات التأمين، إرسال مراجعات أو تغيير معلومات شخصية	كلمة المرور ضمنيّ	يجب توفير معرّف العميل وسر العميل، بالإضافة إلى اسم المستخدم وكلمة المرور. يجب تسجيل التطبيق لدى مقدِّم الخدمة.
التطبيقات المتاحة للجميع	يُكتب مطوّرو التطبيقات غير الموثوق بهم التطبيقات غير الموثوق بها وليس لديهم نشاط تجاري موثوق به. علاقة بمزود واجهة برمجة التطبيقات. على سبيل المثال، يحتاج المطوّرون الذين يتسجّلون للحصول على واجهة برمجة تطبيقات عامة البرامج بشكل عام.	رمز التفويض	تتطلب من المستخدم تسجيل الدخول إلى موفّر موارد تابع لجهة خارجية (مثل Twitter أو Facebook) لا يظهر التطبيق أبدًا اسم المستخدم وكلمة المرور للمستخدم يجب تسجيل التطبيق لدى مقدِّم الخدمة.
B2C	هناك مستخدم نهائي فردي (مستخدم للأجهزة الجوّالة)، ويتم تخزين بيانات اعتماد المستخدم. على الجهاز المحمول.	ضمنيّ	يجب تسجيل التطبيق لدى مقدِّم الخدمة. يتم تخزين بيانات اعتماد المستخدم على الجهاز الذي يُشغِّل التطبيق.

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

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

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

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

إجراءات ننصح بها المراجِع

القراءة

راجِع مزيد من المعلومات حول OAuth 2.0.