تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تنفيذ نوع منح رمز التفويض

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

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

حول هذا الموضوع

يقدّم هذا الموضوع وصفًا عامًا ونظرة عامة حول نوع منح الإذن OAuth 2.0. ويناقش كيفية تنفيذ هذا التدفق على Apigee Edge.

فيديو

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

حالات الاستخدام

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

عيّنة تعليمات برمجية

يمكنك العثور على نموذج كامل وقابل للتنفيذ لنوع منح رمز التفويض في Apigee Edge في مستودع api-platform-samples على GitHub. الاطّلاع على إعدادات OAuth المتقدمة عينة في دليل api-platform- sample/sample-proxies. يمكنك الاطّلاع على README للاطّلاع على تفاصيل حول العيّنة.

مخطط انسيابي

يوضح مخطط التدفق التالي تدفق OAuth لرمز التفويض مع Apigee Edge كخادم تفويض.

ملاحظة: للاطّلاع على نسخة أكبر من هذا المخطّط البياني، انقر بزر الماوس الأيمن عليه وافتحه في أو احفظها وافتحها في عارض الصور.

خطوات مسار رمز التفويض

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

شرط أساسي: يجب أن يكون تطبيق العميل مسجَّلاً في Apigee Edge من أجل الحصول على معرّف العميل ومفاتيح سر العميل. راجع تسجيل تطبيقات العميل لـ التفاصيل.

1. يبدأ المستخدم التدفق

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

2. يُدخل المستخدم بيانات الاعتماد

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

3- يمنح المستخدِم الموافقة

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

4. تطبيق تسجيل الدخول إرسال طلب في Apigee Edge

إذا تم تسجيل الدخول والموافقة بنجاح، يرسل تطبيق تسجيل الدخول بيانات POST إلى /authorizedcode نقطة نهاية Apigee Edge. تتضمن البيانات معرّف الموارد المنتظم (URI) لإعادة التوجيه ومعرّف العميل والنطاق وأي مستخدم المعلومات التي يريد تضمينها، ومؤشّرًا إلى أنّ عملية تسجيل الدخول تمّت بنجاح.

5- Apigee Edge ينشئ رمز تفويض

عندما يتلقى Edge طلب GET من تطبيق تسجيل الدخول على نقطة نهاية /عيّن رمز التفويض، تحدث الأمور. أولاً، يحدد Edge أن عملية تسجيل الدخول تمت بنجاح (من خلال التحقق من حالة HTTP أو وسائل أخرى). يتحقق Next Edge للتأكد من أن معرف الموارد المنتظم (URI) الخاص بإعادة التوجيه الذي تم إرساله من تطبيق تسجيل الدخول تتطابق مع معرّف الموارد المنتظم (URI) لإعادة التوجيه الذي تم تحديده عند تسجيل التطبيق في Apigee Edge. في حال حذف كل شيء على ما يرام، سينشئ Edge رمز تفويض. مثلاً:

http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

6- الحافة يُعيد إرسال رمز التفويض إلى العميل.

يرسل Edge عملية إعادة التوجيه 302 مع إرفاق كود المصادقة كمعلمة طلب بحث إلى البرنامج.

7. يسترد العميل رمز التفويض ويطلب رمز الدخول من Edge.

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

$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'

8. يتلقى العميل رمز الدخول

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

9. يستدعي العميل واجهة برمجة تطبيقات محمية

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

$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

تهيئة التدفقات والسياسات

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

إنشاء مسارات مخصّصة
إضافة سياسات OAuthV2 وإعدادها

ضبط التدفق المخصَّص

وتضبط عادةً تدفق نوع المنح هذا بحيث تصبح كل خطوة أو "جزء" التدفق هو بالتدفق في الخادم الوكيل في Apigee Edge. لكل مسار نقطة نهاية وسياسة تؤدي المهمة الخاصة ببروتوكول OAuth مطلوبة، مثل إنشاء رمز تفويض أو رمز دخول. بالنسبة كما هو موضح في XML أدناه، لنقطة نهاية /oauth/authorizationcode تُسمى GenerateAuthCode (وهي سياسة OAuthV2 التي تستخدم تم تحديد العملية GenerateAuthorizeCode).

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

يمكنك الاطلاع أيضًا على مثال على GitHub.

<Flows>
  <Flow name="RedirectToLoginApp">
         <!-- 
         Publish this URI to developers to use for their 'login' link 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
    <Request>
        <Step><Name>RedirectToLoginPage</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAuthCode">
         <!-- 
         Call this URL from your Login app after you authenticate the user.
         The policy will automatically return the auth code in the response to the 
         redirect_uri registered by the calling app 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
    <Request>
        <Step><Name>GenerateAuthCode</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GenerateAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

ضبط التدفقات باستخدام السياسات

ولكل نقطة نهاية سياسة مرتبطة بها. لنطّلع على أمثلة عن السياسات. عرض أيضًا تهيئة بروتوكول OAuth نقاط النهاية والسياسات لإلقاء نظرة عامة سريعة على الخطوات اللازمة لإضافة سياسات OAuthV2 بنقاط نهاية الخادم الوكيل.

هذا هو المسار /oauth/authorize. تكون السياسة المرفقة مسؤولة عن إعادة توجيه المستخدم إلى تطبيق تسجيل الدخول، حيث يمكن للمستخدم النهائي مصادقة وتفويض الوصول إلى موارده المحمية بدون الإفصاح عن اسم المستخدم وكلمة المرور إلى تطبيق العميل. ويمكنك تحقيق ذلك باستخدام سياسة وسائل شرح للخدمة أو JavaScript أو Node.js أو وغيرها من الوسائل.

يكون طلب البيانات من واجهة برمجة التطبيقات لتنفيذ الطلب هو GET ويتطلب وجود معلمات طلب البحث client_id، وResponse_type وredirect_uri والنطاق والحالة.

$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

الحصول على رمز المصادقة

هذا هو المسار /oauth/authorizationcode. وهو يستخدم سياسة OAuthV2 مع تم تحديد عملية Generate OAuthCode.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode">
    <DisplayName>GetAuthCode</DisplayName>
    <Operation>GenerateAuthorizationCode</Operation>
    <ExpiresIn>600000</ExpiresIn>
    <GenerateResponse/>
</OAuthV2>

استدعاء واجهة برمجة التطبيقات للحصول على رمز التفويض هو GET ويتطلب وجود معلمات طلب البحث client_id وResponse_type واختياري النطاق والحالة، كما هو موضح في هذا المثال:

$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}

الحصول على رمز الدخول

يتم ربط هذه السياسة بمسار /oauth/accesstoken. إنه يستخدم OAuthV2 مع تحديد عملية GenerateAccessCode. في هذه الحالة، تكون المعلمة range_type هي متوقع كمعلمة طلب البحث:

<OAuthV2 name="GetAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>360000000</ExpiresIn> 
    <SupportedGrantTypes> 
        <GrantType>authorization_code</GrantType> 
    </SupportedGrantTypes> 
    <GrantType>request.queryparam.grant_type</GrantType> 
    <GenerateResponse/> 
</OAuthV2>

طلب البيانات من واجهة برمجة التطبيقات للحصول على رمز الدخول هو طريقة POST ويجب أن يتضمن client_id، client_secret وgrant_type=شن_code واختياريًا، نطاق. مثلاً:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

هذا مجرد ملخص أساسي. يتضمن مثال الإنتاج العديد من السياسات الأخرى لإنشاء عناوين URL وإجراء عمليات التحويل وتنفيذ مهام أخرى. راجع العينة على GitHub للحصول على اكتمال المشروع العملي.

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

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

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

جارٍ طلب واجهة برمجة التطبيقات المحمية

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

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

راجع أيضًا إرسال رمز الدخول.