يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات
Apigee X. المعلومات
ظهر بروتوكول OAuth كبروتوكول التفويض الرائد لواجهات برمجة التطبيقات. ويتم تحديد إصدار OAuth بالتفصيل في هذا الموضوع في مواصفات OAuth 2.0.
OAuth هو بروتوكول يتيح لمستخدمي التطبيقات السماح للتطبيقات بالتصرف نيابةً عنهم. ويتم إجراء ذلك من خلال الحصول على رموز الدخول من مزوّدي واجهات برمجة التطبيقات. يصادق موفِّر واجهة برمجة التطبيقات على بيانات اعتماد مستخدم التطبيق، ويضمن أن يكون المستخدم قد صرح باستخدام التطبيق، ثم يصدر رمز دخول إلى التطبيق. وعندما يستخدم التطبيق واجهة برمجة تطبيقات محمية، يفحص Apigee Edge رمز الدخول للتأكد من صلاحيته وعدم انتهاء صلاحيته. بصفتك مزوّد واجهة برمجة تطبيقات، يجب الكشف عن نقاط النهاية التي تتيح للتطبيقات الحصول على رموز الدخول.
لتسهيل بدء استخدام OAuth، يتيح لك Apigee Edge ضبط بروتوكول OAuth وفرضه باستخدام السياسات، بدون أن يُطلب منك كتابة أي رمز. ستتعرَّف في هذا الموضوع على كيفية حماية واجهات برمجة التطبيقات والحصول على رموز الدخول واستخدام رموز الدخول هذه للوصول إلى واجهات برمجة التطبيقات المحمية.
إعدادات OAuth التلقائية في مؤسستك
لتوفير الراحة، تكون جميع المؤسسات في Apigee Edge مهيأة مسبقًا من خلال مجموعة من نقاط نهاية OAuth 2.0 التي تنفّذ نوع منح بيانات اعتماد العميل. يحدّد نوع منح بيانات اعتماد العميل إجراءً لإصدار رموز الدخول مقابل بيانات اعتماد التطبيق. بيانات اعتماد التطبيق هذه هي ببساطة مفتاح العميل والمفتاح السري الذي يصدره Apigee Edge لكل تطبيق مسجَّل في مؤسسة. تشير "بيانات اعتماد العميل" إلى مفتاح العميل والمفتاح السري نفسهما.
لمزيد من المعلومات حول إصدار بيانات الاعتماد للتطبيقات باستخدام "خدمات مطوّري برامج Edge"، يُرجى الاطّلاع على تسجيل التطبيقات وإدارة المفاتيح.
ولهذا السبب، من السهل نسبيًا "ترقية" نظام أمان واجهة برمجة التطبيقات من التحقق من صحة مفتاح واجهة برمجة التطبيقات إلى بيانات اعتماد عميل OAuth. يستخدم كلا المخططَين مفتاح العميل والسر نفسه للتحقّق من صحة تطبيق العميل. ويكمن الفرق في أنّ بيانات اعتماد العميل توفّر طبقة إضافية من التحكّم، إذ يمكنك بسهولة إبطال رمز الدخول عند الحاجة، بدون أن تطلب منك إبطال مفتاح المستهلك للتطبيق. للعمل مع نقاط نهاية OAuth التلقائية، يمكنك استخدام أي مفتاح وسر عميل تم إنشاؤهما للتطبيق في مؤسستك لاسترداد رموز الدخول من نقطة نهاية الرمز المميز. (يمكنك أيضًا تفعيل بيانات اعتماد العميل للتطبيقات التي تتضمّن مفاتيح وأسرار العميل).
يمكن العثور على المواصفات الكاملة لمنح بيانات اعتماد العميل في مواصفات OAuth 2.0.
حماية واجهة برمجة التطبيقات باستخدام سياسة
قبل أن تتمكّن من استخدام رموز الدخول، يجب عليك إعداد واجهات برمجة التطبيقات لإثبات صحة رموز الدخول عبر OAuth في وقت التشغيل. لإجراء ذلك، عليك ضبط خادم وكيل لواجهة برمجة التطبيقات من أجل validate من رموز الدخول. وهذا يعني أنّه في كل مرة يطلب فيها التطبيق استخدام إحدى واجهات برمجة التطبيقات، يجب أن يقدّم التطبيق رمز دخول صالحًا مع طلب واجهة برمجة التطبيقات. تعالج Apigee Edge التعقيدات المتعلقة بإنشاء رموز الدخول المعروضة وتخزينها والتحقق منها.
يمكنك بسهولة إضافة ميزة "التحقّق من خلال بروتوكول OAuth" إلى واجهة برمجة التطبيقات عند إنشاء خادم وكيل جديد لواجهة برمجة التطبيقات. عند إنشاء خادم وكيل جديد لواجهة برمجة التطبيقات، يمكنك إضافة ميزات. كما هو موضّح أدناه، يمكنك إضافة التحقّق من رموز الدخول عبر OAuth 2.0 من خلال النقر على زر الاختيار بجانب Secure with OAuth v2.0 Access Tokens (التأمين باستخدام رموز الدخول عبر OAuth v2.0). عند تحديد هذا الخيار، سيتم إرفاق سياستين بالخادم الوكيل لواجهة برمجة التطبيقات الذي تم إنشاؤه حديثًا، إحداهما للتحقق من رموز الدخول والأخرى لإزالة رمز الدخول بعد التحقق منه.
بالإضافة إلى ذلك، عند تحديد الخيار Secure with OAuth v2.0 Access Tokens (الآمن باستخدام رموز الدخول عبر OAuth v2.0)، يصبح مربّع الاختيار Publish API Product (نشر منتج واجهة برمجة التطبيقات) قابلاً للاختيار ويتم تحديده تلقائيًا. ضَع علامة في المربّع إذا كنت تريد إنشاء منتج تلقائيًا عند إنشاء الخادم الوكيل الجديد لواجهة برمجة التطبيقات. سيتم إنشاء المنتج الذي يتم إنشاؤه تلقائيًا وربطه بالخادم الوكيل الجديد لواجهة برمجة التطبيقات. إذا كان لديك منتج حالي تريد ربط واجهة برمجة التطبيقات الجديدة به، احرص على إزالة العلامة من مربّع الاختيار هذا لتجنّب إنشاء منتج غير ضروري. لمزيد من المعلومات عن المنتجات، يُرجى الاطّلاع على القسم ما هو منتج واجهة برمجة التطبيقات؟
إذا كنت بحاجة إلى تفعيل التحقق من رمز الدخول للخادم الوكيل لواجهة برمجة التطبيقات الموجود، كل ما عليك فعله هو إرفاق سياسة من نوع OAuthV2 بواجهة برمجة التطبيقات التي تريد حمايتها. تعمل سياسات OAuthV2 من خلال تحديد عملية. وإذا كنت تريد التحقّق من صحة رموز الدخول، عليك تحديد العملية التي تُسمى VerifyAccessToken. (هناك أنواع أخرى من العمليات المتوافقة مع نوع سياسة OAuthV2 هي GenerateAccessToken و GeneratePreviewToken. ويمكنك التعرّف على هذه العمليات عند إعداد نقاط نهاية OAuth.)
سياسة CheckOAuthTokens من النوع OAuthV2
في ما يلي مثال على سياسة للتحقّق من صحة رموز الدخول. (الإعدادات موضّحة في الجدول أدناه.)
<OAuthV2 name="VerifyOAuthTokens"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
إعدادات السياسة
| الاسم | الوصف | تلقائي | مطلوب؟ |
|---|---|---|---|
OAuthV2 |
نوع السياسة | ||
name |
اسم السياسة المُشار إليه في إعداد نقطة النهاية للخادم الوكيل لواجهة برمجة التطبيقات. | لا ينطبق | نعم |
Operation |
العملية التي سيتم تنفيذها بواسطة سياسة OAuthV2. من خلال تحديد CheckAccessToken، يتم إعداد السياسة للتحقُّق من طلبات رموز الدخول والتحقّق من صلاحية رمز الدخول وعدم انتهاء صلاحيته وتمت الموافقة عليه لاستهلاك مورد واجهة برمجة التطبيقات (URI) المطلوب. (لإجراء هذا الفحص، تحدّد السياسة منتج واجهة برمجة التطبيقات الذي تمت الموافقة على استخدام التطبيق له). | لا ينطبق | نعم |
لإنشاء هذه السياسة في واجهة مستخدم الإدارة، انتقِل إلى واجهات برمجة التطبيقات > الخوادم الوكيلة لواجهة برمجة التطبيقات.
من قائمة الخوادم الوكيلة لواجهة برمجة التطبيقات، اختَر weatherapi.
من نظرة عامة في واجهة برمجة التطبيقات weatherapi، اختَر طريقة العرض التطوير.
من القائمة المنسدلة، اختَر سياسة جديدة > OAuth v2.0.
بعد اختيار سياسة OAuth v2.0، ستظهر قائمة ضبط السياسة الجديدة.
امنح السياسة اسمًا وصفيًا وتأكّد من اختيار إرفاق السياسة وFlow PreFlow والطلب كإعدادات لمرفق السياسة.
انقر على إضافة، وسيتم إنشاء السياسة وإرفاقها بطلب ملف weatherapi PreFlow.
بعد إضافة السياسة، سيتم عرض إعدادات PreFlow للطلب أدناه في لوحة Designer (المصمّم).
إذا كنت تعمل على المستوى المحلي ضمن محرِّر نصوص أو بيئة التطوير المتكاملة، عليك إرفاق السياسة بطلب العرض المُسبق لواجهة برمجة التطبيقات الذي تريد حمايته:
<PreFlow>
<Request>
<Step><Name>VerifyOAuthTokens</Name></Step>
</Request>
</PreFlow>
من خلال إرفاق السياسة بالطلب PreFlow، تضمن أنّه يتم دائمًا فرض السياسة على جميع رسائل الطلب.
لقد قمت الآن بتأمين واجهة برمجة تطبيقات باستخدام بيانات اعتماد عميل OAuth 2.0. والخطوة التالية هي معرفة طريقة الحصول على رمز الدخول واستخدامه للوصول إلى واجهة برمجة التطبيقات الآمنة.
استخدام رمز دخول للوصول إلى مورد محمي
بعد أن تم تأمين تطبيق weatherapi باستخدام OAuth 2.0، على التطبيقات تقديم رموز الدخول لاستخدام واجهة برمجة التطبيقات. للوصول إلى مورد محمي، يقدّم التطبيق رمز دخول في الطلب على شكل عنوان HTTP يتضمن"تفويض" على النحو التالي:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
بما أنّ واجهة برمجة التطبيقات تتضمّن سياسة OAuthV2 مرفقة، سيتحقّق Apigee Edge من صلاحية رمز الدخول المقدَّم، ثم يمنح إمكانية الوصول إلى واجهة برمجة التطبيقات، مع عرض تقرير الطقس للتطبيق الذي أنشأ الطلب.
ولكن كيف تحصل التطبيقات على رموز الدخول؟ سنتناول ذلك في القسم التالي.
كيفية استبدال بيانات اعتماد العميل برمز دخول
تحصل التطبيقات على رموز الدخول من خلال تقديم أزواج مفتاح/مفتاح العميل إلى نقطة نهاية الرمز المميّز. يتم ضبط نقطة نهاية الرمز المميّز في الخادم الوكيل لواجهة برمجة التطبيقات الذي يُسمى oauth. لذلك، تحتاج التطبيقات إلى استدعاء واجهة برمجة التطبيقات التي يعرضها الخادم الوكيل لواجهة برمجة التطبيقات oauth للحصول على رمز دخول. بعد أن يحصل التطبيق على رمز دخول، يمكنه طلب رمز الدخول بشكل متكرر إلى أن تنتهي صلاحية رمز الدخول أو يتم إبطال رمز الدخول.
أنت الآن بحاجة إلى تغيير الاتجاه لتفكر في نفسك كمطور تطبيقات. إذا كنت تريد تسمية weatherapi، عليك الحصول على رمز دخول لتطبيقك. وأول ما عليك فعله هو الحصول على مفتاح العميل وزوج سري (يُعرفان أيضًا باسم مفتاح واجهة برمجة التطبيقات أو مفتاح التطبيق).
يمكنك الحصول على مفتاح وسر العميل من خلال تسجيل تطبيق في مؤسستك على Apigee Edge.
يمكنك الاطّلاع على جميع التطبيقات في مؤسستك في واجهة مستخدم إدارة Apigee Edge.
ستظهر لك قائمة بالتطبيقات المُسجّلة في مؤسستك.
(إذا لم تظهر أي تطبيقات، يمكنك التعرّف على كيفية تسجيل تطبيق في الموضوع المسمى تسجيل التطبيقات وإدارة مفاتيح واجهة برمجة التطبيقات.)
اختَر تطبيقًا من القائمة للاطّلاع على ملفه الشخصي التفصيلي.
في طريقة عرض التفاصيل الخاصة بالتطبيق الذي اخترته، دوِّن حقلَي مفتاح العميل وسر العميل. هاتان القيمتان هما بيانات اعتماد العميل التي ستستخدمها للحصول على رمز دخول OAuth.
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps \
-u myname:mypass
تعرض هذه المكالمة قائمة بالتطبيقات حسب رقم تعريف التطبيق.
[ "da496fae-2a04-4a5c-b2d0-709278a6f9db", "50e3e831-175b-4a05-8fb6-05a54701af6e" ]
يمكنك استرداد الملف الشخصي للتطبيق من خلال إجراء استدعاء GET بسيطًا على معرف التطبيق:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/{app_id} \
-u myname:mypass
مثال:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/da496fae-2a04-4a5c-b2d0-709278a6f9db \
-u myname:mypass
يعرض طلب البيانات من واجهة برمجة التطبيقات الملف الشخصي للتطبيق الذي حددته. على سبيل المثال، يتضمن الملف الشخصي لتطبيق weatherapp تمثيل JSON التالي:
{
"accessType" : "read",
"apiProducts" : [ ],
"appFamily" : "default",
"appId" : "da496fae-2a04-4a5c-b2d0-709278a6f9db",
"attributes" : [ ],
"callbackUrl" : "http://weatherapp.com",
"createdAt" : 1380290158713,
"createdBy" : "noreply_admin@apigee.com",
"credentials" : [ {
"apiProducts" : [ {
"apiproduct" : "PremiumWeatherAPI",
"status" : "approved"
} ],
"attributes" : [ ],
"consumerKey" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"consumerSecret" : "hAr4Gn0gA9vAyvI4",
"expiresAt" : -1,
"issuedAt" : 1380290161417,
"scopes" : [ ],
"status" : "approved"
} ],
"developerId" : "5w95xGkpnjzJDBT4",
"lastModifiedAt" : 1380290158713,
"lastModifiedBy" : "noreply_admin@apigee.com",
"name" : "weatherapp",
"scopes" : [ ],
"status" : "approved"
}
دوِّن قيمتَي consumerKey وconsumerSecret. يمكنك استخدام بيانات الاعتماد هذه للحصول على رمز دخول من خلال عرضها كبيانات اعتماد مصادقة أساسية في طلب HTTP على النحو الموضّح أدناه. يتم تقديم نوع المنحة كمَعلمة طلب بحث للطلب.
(تأكَّد من تغيير قيمة المتغيّر {org_name} لتعكس اسم مؤسستك
على Apigee Edge.)
إنشاء طلب للحصول على رمز الدخول
في الطلب التالي، استبدِل قيمة consumerKey بـ client_id. استبدِل قيمة consumerSecret المرتبطة بـ client_secret.
$ curl https://{org_name}-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'
تتحقّق "خدمات واجهة برمجة التطبيقات" من مفتاح وسر المستهلك، ثم تنشئ ردًا يحتوي على رمز الدخول لهذا التطبيق:
{
"issued_at" : "1380892555397",
"application_name" : "957aa73f-25c2-4ead-8021-adc01f0d2c6b",
"scope" : "",
"status" : "approved",
"api_product_list" : "[oauth-test]",
"expires_in" : "3599",
"developer.email" : "tesla@weathersample.com",
"organization_id" : "0",
"client_id" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"access_token" : "ylSkZIjbdWybfs4fUQe9BqP0LH5Z",
"organization_name" : "rqa",
"refresh_token_expires_in" : "0",
"refresh_count" : "0"
}
لاحظ قيمة access_token في الرد أعلاه. هذا هو رمز الدخول الذي
سيستخدمه التطبيق للوصول في وقت التشغيل إلى الموارد المحمية. رمز الدخول لهذا التطبيق هو
ylSkZIjbdWybfs4fUQe9BqP0LH5Z.
لديك الآن رمز دخول صالح، ylSkZIjbdWybfs4fUQe9BqP0LH5Z، يمكن استخدامه للوصول إلى واجهات برمجة التطبيقات المحمية.
استخدام إعدادات OAuth التلقائية
يتم تزويد كل مؤسسة (حتى لو كانت مؤسسة تجريبية مجانية) على Apigee Edge بنقطة نهاية لرمز OAuth المميز. يتم ضبط نقطة النهاية مسبقًا باستخدام السياسات في الخادم الوكيل لواجهة برمجة التطبيقات التي تُسمى oauth. يمكنك البدء في استخدام نقطة نهاية الرمز المميّز فور إنشاء حساب على Apigee Edge.
تعرض نقطة نهاية OAuth التلقائية معرِّف الموارد المنتظم (URI) لنقطة النهاية التالي:
/oauth/client_credential/accesstoken
يمكنك نشر معرّف الموارد المنتظم (URI) هذا للمطوِّرين الذين يحتاجون إلى الحصول على رموز الدخول. يضبط مطوّرو التطبيقات تطبيقاتهم لطلب تسمية نقطة النهاية هذه، من خلال تقديم مفتاح العميل والمفتاح السرّي الخاص بهم للحصول على رموز الدخول.
تظهر نقطة النهاية التلقائية للرمز المميّز لبيانات اعتماد العميل على الشبكة في عنوان URL التالي:
https://{org_name}-{env_name}.apigee.net/oauth/client_credential/accesstoken
على سبيل المثال، إذا كان اسم مؤسستك هو "apimakers"، سيكون عنوان URL هو:
https://apimakers-test.apigee.net/oauth/client_credential/accesstoken
هذا هو عنوان URL الذي يطلبه المطوّرون للحصول على رموز الدخول.
إعدادات بروتوكول OAuth الثلاثي
تتطلّب إعدادات بروتوكول OAuth الثلاثي (أنواع رمز التفويض والأنواع الضمنية ومنح كلمة المرور) منك بصفتك مقدِّم واجهة برمجة التطبيقات مصادقة مستخدمي التطبيقات. بما أنّ كل مؤسسة تصادق المستخدمين بطرق مختلفة، يجب تخصيص بعض السياسات أو إدخال رمز برمجي لدمج OAuth مع متجر المستخدمين. على سبيل المثال، قد يتم تخزين جميع المستخدمين في Active Directory أو في LDAP أو بعض متاجر المستخدمين الأخرى. لإعداد بروتوكول OAuth الثلاثي وتشغيله، عليك دمج التحقق من متجر المستخدمين هذا في مسار OAuth العام.
OAuth 1.0a
لمعرفة تفاصيل عن سياسة OAuth 1.0a، يُرجى الاطّلاع على سياسة OAuth 1.0a.
الحصول على مساعدة
للحصول على مساعدة، يُرجى الاطّلاع على فريق دعم عملاء Apigee.