يتم الآن عرض مستندات 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 2.0 التابع لمجموعة مهندسي شبكة الإنترنت (IETF).
وصول محدود من خلال النطاقات
ومن خلال آلية النطاقات، يمكن لبروتوكول OAuth 2.0 منح التطبيق إمكانية الوصول المحدود إلى الموارد المحمية. على سبيل المثال، قد يتم منح أحد التطبيقات إذن الوصول إلى موارد محدّدة فقط، أو قد يكون بإمكانه تعديل الموارد، أو قد يتم منحه إذنًا بالقراءة فقط. ضمن ما يُعرف باسم تدفقات بروتوكول OAuth "الثلاثية"، يحدّد المستخدم عادةً مستوى الوصول من خلال صفحة الموافقة (على سبيل المثال، صفحة ويب يختار فيها المستخدم النطاق مع مربّع اختيار لآلية أخرى).
تسجيل التطبيق
على جميع البرامج (التطبيقات) التسجيل باستخدام خادم تفويض OAuth 2.0 الذي يريدون طلب رموز الدخول منه. عند تسجيل تطبيق، تحصل مرة أخرى على مجموعة من المفاتيح. أحدهما عبارة عن مفتاح عام يُسمى معرّف العميل والآخر مفتاح سري يسمى سر العميل. بدون هذه المفاتيح، لا يمكن للتطبيق إصدار طلبات للحصول على رموز التفويض أو رموز الدخول إلى خادم التفويض. يُرجى العلم أنّه مع أنّ مواصفات بروتوكول OAuth في مجموعة مهندسي شبكة الإنترنت (IETF) تستدعي هذين المفتاحَين معرّف العميل وسر العميل، تطلق عليهما واجهة مستخدم Apigee Edge معرّف العميل وسر العميل. إنهما متكافئان.
ملخّص حالات استخدام OAuth 2.0
يعتمد مسار نوع منح بروتوكول OAuth 2.0 الذي تختار تنفيذه على حالة استخدامك المحدّدة، لأنّ بعض أنواع المِنح أكثر أمانًا من غيرها. ويعتمد اختيارك لأنواع المنح على مدى موثوقية تطبيق العميل، ويتطلّب ذلك دراسة متأنية للغاية، على النحو الموضّح في الجدول التالي:
| حالة الاستخدام | الموثوقية | أنواع منح تفويض OAuth 2.0 المقترَحة | الوصف |
|---|---|---|---|
| علاقة تجارية بين نشاط تجاري وآخر (شبكة خارجية)، شبكة داخلية، وغير ذلك |
هي تطبيقات موثوقة للغاية، وهي كتبها مطوّرون داخليون أو مطوّرون لديهم علاقة عمل موثوقة مع موفِّر واجهة برمجة التطبيقات. التطبيقات التي تحتاج إلى الوصول إلى الموارد بنفسها. |
|
|
| مواقع الشبكات الداخلية، البوابات |
تطبيقات موثوق بها أنشأها مطوّرون داخليون أو تابعون لجهات خارجية موثوق بهم. وخير مثال على ذلك هو تسجيل الدخول إلى موقع الموارد البشرية الخاص بشركتك لإجراء خيارات التأمين، أو إرسال مراجعات، أو تغيير المعلومات الشخصية. |
|
|
| التطبيقات المتاحة للجميع | تتم كتابة التطبيقات غير الموثوق بها من قِبل مطوّرين تابعين لجهات خارجية وليس لديهم علاقة تجارية موثوقة مع موفِّر واجهة برمجة التطبيقات. على سبيل المثال، يجب ألا يكون المطوّرون الذين يسجّلون في برامج واجهات برمجة التطبيقات العامة موثوقًا بهم بشكل عام. |
|
|
| بين الأنشطة التجارية والمستهلك | يكون هناك مستخدم نهائي فردي (مستخدم جوّال)، ويتم تخزين بيانات اعتماد المستخدم على الجهاز الجوّال. |
|
|
الفرق بين OAuth 2.0 وأمان مفتاح واجهة برمجة التطبيقات
يتطلب التحقّق من صحة مفتاح واجهة برمجة التطبيقات أن يرسل التطبيق مفتاحًا إلى Edge. يجب أن يكون المفتاح مفتاح عميل صالحًا من تطبيق مطوّر Apigee Edge مرتبط بالخادم الوكيل لواجهة برمجة التطبيقات. إذا كنت بحاجة لسبب ما إلى إبطال إذن أحد تطبيقات العميل لإجراء مكالمات إلى خادم وكيل، يجب إبطال هذا الإذن. لن تتمكّن أي تطبيقات عميل تستخدم هذا المفتاح من الوصول إلى الخادم الوكيل لواجهة برمجة التطبيقات. ومن ناحية أخرى، يمكن إبطال رمز OAuth المميز في أي وقت بدون إبطال مفاتيح التطبيق. يمكن للتطبيق ببساطة طلب رمز مميّز جديد نيابةً عن المستخدم. وفي حال منح رمز مميّز، بإمكان التطبيق مواصلة استخدام الخادم الوكيل لواجهة برمجة التطبيقات.
يتمثّل الاختلاف الآخر بين مفتاح واجهة برمجة التطبيقات والرمز المميّز في أنّ الرمز المميّز يمكن أن يتضمّن سمات البيانات الوصفية التي يمكنك استردادها واستخدامها لاحقًا. على سبيل المثال، يمكنك تخزين رقم تعريف المستخدم الذي يُجري طلب البيانات من واجهة برمجة التطبيقات واستخدامه لتخصيص عمليات الاستدعاء لخدمة الواجهة الخلفية.
للحصول على تفاصيل حول التحقق من صحة مفتاح واجهة برمجة التطبيقات، يمكنك الاطّلاع على مفاتيح واجهة برمجة التطبيقات. لمزيد من المعلومات حول استخدام سمات مخصّصة مع رموز OAuth المميزة، يمكنك الاطّلاع على تخصيص الرموز المميّزة ورموز التفويض.
المراجع المقترَحة
القراءة
يمكنك الاطّلاع على مزيد من المعلومات عن OAuth 2.0.