كيفية إعداد واستخدام مصادقة OAuth باستخدام WP REST API

عندما يتعلق الأمر بـ WordPress REST API ، فإن OAuth هو أكثر مزود معالجة المصادقة شيوعًا.

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

ربما يكون أهم استخدام لعملية مصادقة OAuth هو العملية الآمنة للتعامل مع طلبات REST API دون الكشف عن بيانات اعتماد المستخدمين. هذا مهم بشكل خاص في حالة خوادم الإنتاج حيث يتم تبادل بيانات الاعتماد غالبًا. في مثل هذه السيناريوهات ، يتم استخدام مصادقة OAuth لتوفير إجراء آمن للتعامل مع طلب بيانات اعتماد تسجيل الدخول المتكرر.

التقليدية مقابل مصادقة OAuth

لفهم أهمية مصادقة OAuth ، من المهم فهم نموذج المصادقة التقليدية و OAuth.

في نموذج المصادقة التقليدي ، هناك كيانان رئيسيان ؛ العميل والموارد / مزود الخدمة. يمكن أن يكون العميل تطبيق ويب أو خدمة أو مستخدمًا ، بينما يمتلك المورد / مزود الخدمة الموارد أو الخدمات المطلوبة في بيئة مقيدة الوصول.

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

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

نظرًا لوجود ثلاثة كيانات ، تُعرف العملية بالمصادقة ثلاثية الأرجل. ومع ذلك ، في الحالات التي يكون فيها العميل والمستخدم هما الكيانان نفسه ، تصبح عملية المصادقة مصادقة ثنائية.

سير عمل مصادقة OAuth

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

يقوم العميل بإنشاء الطلب الموقع للحصول على رمز طلب. يُعرف هذا الطلب أيضًا باسم بيانات الاعتماد المؤقتة. يتم إرسال الطلب إلى URI لنقطة النهاية ذات الصلة. يتكون هذا الطلب من عدة معايير مهمة:

• oauth_consumer_key : يحدد هذا المفتاح التطبيق الذي أنشأ الطلب.
• oauth_timestamp : تستخدم الخوادم هذا الطابع الزمني لتحسين تخزين nonces.
• oauth_nonce : هذا هو الرمز المميز الذي تم إنشاؤه للتطبيق الفريد لكل طلب فردي.
• oauth_signature : هذا الجزء المهم من طلب API هو تجزئة جميع مكونات الطلب وبعض قيم OAuth.
• oauth_signature_method : يوفر المكون الإضافي OAuth طريقة توقيع واحدة: HMAC-SHA1.
• oath_callback : عنوان URL حيث تتم إعادة توجيه المستخدم بعد الإذن. تم التحقق من الطلب وإصدار رمز طلب بالمعلمات التالية.
• oauth_token : هذا هو الرمز المميز للتطبيق الذي تم تجريده من استجابة خادم التفويض. ثم يتم إرسال هذا الرمز المميز إلى خادم API.
• oauth_token_secret : هذا مشابه لكلمة مرور المستخدم. ثم يتم تفويض الطلب من قبل العميل. لهذا ، يتم إنشاء طلب URI وإضافة oauth_token إلى URI لنقطة نهاية ترخيص الخادم. يصرح المستخدم بإرسال هذا الطلب من خلال تقديم بيانات الاعتماد المناسبة.

في حالة توفر oauth_callback URI في الخطوة الأولى ، يعيد الخادم التوجيه إلى URI مع إضافة المعلمات التالية إلى سلسلة الاستعلام:

• oauth_token : يوجد بالفعل الرمز المميز.
• oauth_verifier : يتحقق من هوية مالك المورد للعميل.

إذا لم يتم توفير oauth_callback URI في الخطوة الأولى ، فسيرسل الخادم قيمة oauth_verifier حتى يتمكن مالك المورد من إبلاغ العميل يدويًا.

بعد تلقي oauth_verfier ، يطلب العميل من الخادم بيانات اعتماد الرمز المميز. يأخذ هذا شكل طلب إلى عنوان URI لنقطة نهاية طلب الرمز المميز. يحتوي هذا الطلب على المعلمات التالية:

• oauth_token
• oauth_verfier
• oauth_consumer_key
• oauth_signature
• طريقة_التوقيع_التوقيع
• oauth_nonce
• oauth_version

تثبيت مصادقة OAuth

في سياق WordPress ، يتم تنفيذ مصادقة OAuth عن طريق تثبيت واجهة برمجة تطبيقات مصادقة OAuth لـ WordPress. يعتمد هذا على مواصفات OAuth 1.0a ويوسع هذه المواصفات فعليًا بواسطة معلمة إضافية wp_scope. يتم إرسال هذه المعلمة إلى نقطة نهاية طلب الاعتماد المؤقت .

المكون الإضافي متاح على Github من فريق WP REST API. في الوقت الحالي ، يتم دعم الإصدار 4.4 والإصدارات الأحدث.

سأبدأ عملية استنساخ المكون الإضافي بالانتقال إلى / wp-content / plugins / directory:

 استنساخ بوابة https://github.com/WP-API/OAuth1.git 

بعد انتهاء التنزيل ، قم بتنشيط المكون الإضافي من خلال WordPress CLI:

 يقوم المكون الإضافي wp بتنشيط OAuth1

إذا كنت لا ترغب في استخدام WordPress CLI ، فيمكنك الانتقال إلى WordPress Admin >> Plugins وتنشيط المكون الإضافي من القائمة. بدلاً من ذلك ، يمكنك أيضًا تنشيطه من خلال التنقل في المستعرض الخاص بك إلى قسم المكونات الإضافية لمسؤول WordPress إذا كنت لا ترغب في استخدام WP CLI.

تقييم مدى توفر OAuth API

قبل بدء مصافحة OAuth ، سأتحقق أولاً مما إذا تم تمكين واجهة برمجة التطبيقات على الخادم. يتم ذلك عن طريق إرسال طلب GET بسيط إلى / wp-json / endpoint ثم تحليل الاستجابة المرسلة من الخادم.

 احصل على http: // Server-Dev / wp-json /

سيؤدي هذا إلى عرض استجابة JSON على النحو التالي:

تركيزي هنا هو قيمة oauth1 في قيمة خاصية المصادقة . تم تحديد الخصائص التالية لهذا الكائن:

• الطلب : نقطة نهاية طلب الاعتماد المؤقت
• التخويل : نقطة نهاية ترخيص مالك المورد
• الوصول : نقطة نهاية طلب الرمز المميز
• الإصدار : إصدار OAuth قيد الاستخدام

إذا لم يتم تمكين API أوث لموقع ما، فإن استجابة الخادم تحتوي على قيمة العقار إذن فارغة.

إنشاء وإدارة التطبيقات

تتمثل الخطوة الأولى في التأكد من تثبيت المكون الإضافي OAuth1.0 وتنشيطه بشكل صحيح.

بعد ذلك ، يمكنني إنشاء التطبيقات وإدارتها من خلال الانتقال إلى مدير WordPress >> المستخدمون >> التطبيقات.

في صفحة التطبيقات المسجلة هذه ، سأقوم بتسجيل طلب جديد بالضغط على زر إضافة جديد ثم ملء الحقول الثلاثة التالية:

1. Client Name: اسم العميل الذي يظهر في قسم التطبيقات المعتمدة وأثناء عملية التفويض.
2. الوصف : الوصف الاختياري للعميل.
3. عنوان URL لمعاودة الاتصال: يُستخدم عنوان URL لمعاودة الاتصال عند إنشاء بيانات اعتماد مؤقتة.

بمجرد الإنشاء بالنقر فوق الزر Save Client ، ستظهر معلمات Client Key و Client Secret في الجزء السفلي من الصفحة لهذا العميل المحدد.

سأقوم الآن باستنساخ المستودع على العميل عن طريق تشغيل الأمر التالي:

 بوابة استنساخ https://github.com/WP-API/client-cli 

انتقل الآن إلى الدليل المستنسخ وقم بتثبيت تبعيات الحزمة باستخدام Composer:

 cd العميل- cli
تثبيت الملحن

إذا سارت الأمور على ما يرام ، فيجب أن يظهر سطر الأوامر شيئًا مشابهًا لما يلي:

CLI للعميل لإنشاء بيانات اعتماد OAuth

لبدء عملية مصادقة OAuth ، سأحصل أولاً على المعلمات التالية من الخادم:

• oauth_consumer_key
• oauth_consumer_secret

سيتم إنشاء هذا من خلال المحطة وتشغيل أمر WordPress CLI التالي:

 إضافة wp oauth1

المفتاح والسر هما oauth_consumer_key و oauth_consumer_secret على التوالي.

الآن أنا بحاجة إلى ربط العميل بموقع WordPress. على العميل ، انتقل إلى دليل client-cli (تم نسخه سابقًا) وقم بتشغيل الأمر التالي:

 wp --require = client.php api oauth1 connect http: // Server-Dev / --key = <your key here> --secret = <your secret here>

استبدل عنوان URL والمفتاح والسر في الأمر أعلاه. يجب أن يكون الإخراج كالتالي:

 wp --require = client.php api oauth1 connect http: // your-server / wordpress-api / --key = <your key> --secret = <your secret code>
افتح في متصفحك: http: // your-server / wordpress-api / oauth1 / authorize؟ oauth_token = <your-token>
أدخل رمز التحقق:

انتقل إلى عنوان URL الذي قدمه الخادم وقم بالمصادقة بالنقر فوق الزر " تفويض" :

سيتم تقديمك مع رمز التحقق (أو oauth_verifier) ​​على الشاشة التالية:

انسخ المدقق والصقه في الجهاز. ستحصل على مفتاح وسر ، وهما في الأساس oauth_token و oauth_token_secret على التوالي:

عميل HTTP لإنشاء بيانات اعتماد OAuth

نظرًا لأن المكون الإضافي لخادم OAuth 1.0a يتبع التدفق القياسي ثلاثي القوائم ، فإن إنشاء بيانات اعتماد OAuth يتضمن الخطوات التالية:

• الحصول على أوراق اعتماد مؤقتة
• أذونات المستخدم
• تبادل الرموز

الحصول على أوراق اعتماد مؤقتة

سأرسل طلب POST إلى / oauth1 / request endpoint للحصول على بيانات اعتماد مؤقتة. لاحظ أن نقطة النهاية هذه يجب أن تكون قابلة للاكتشاف التلقائي لأن الخادم قد يحل محل المسار بمفرده.

يجب أن يشتمل طلب POST على معلمات oauth_consumer_secret كما تم الحصول عليها عند تسجيل مستهلك للتطبيق. قد يتضمن الطلب أيضًا معلمة oauth_callback ويجب أن يتطابق عنوان URL لمعاودة الاتصال مع المخطط والمضيف والمنفذ ومسار عنوان URL لمعاودة الاتصال الذي تم توفيره عند تسجيل التطبيق.

بالإضافة إلى المعلمات oauth_consumer_key وoauth_consumer_secret، ينبغي أن يتضمن الطلب أيضا المعلمات oauth_signature وoauth_signature_method.

عند استخدام Postman ، يتم إنشاء oauth_signature تلقائيًا. أريد فقط أن أذكر معلمة oauth_signature_method . في الوقت الحالي ، يتم دعم طريقة توقيع HMAC-SHA1 فقط بواسطة المكون الإضافي لخادم OAuth.

سأقوم الآن بتهيئة Postman لإرسال طلب POST إلى نقطة نهاية بيانات اعتماد الرمز المميز المؤقت. بعد ذلك ، في علامة تبويب التفويض ، حدد خيار OAuth 1.0 من القائمة المنسدلة. املأ حقلي " مفتاح العميل" و " سر العميل " بالقيم التي يقدمها المستهلك. أخيرًا ، تحقق من ضبط خيار Signature Method على HMAC-SHA1 .

ترخيص المستخدم

بالنسبة لخطوة ترخيص المستخدم ، سأفتح نقطة نهاية ترخيص مالك المورد في المتصفح وأمرر oauth_token و oauth_token_secret كما تم الحصول عليها في الخطوة السابقة كمعلمات استعلام:

 http: // server-dev / oauth1 / authorize؟ oauth_token = <token_here> & oauth_token_secret = <secret_here> 

قم بتفويض التطبيق بالنقر فوق الزر " تفويض" . ستعرض الشاشة التالية رمز التحقق. سيعمل هذا الرمز المميز الآن كرمز oauth_verifier في الخطوة التالية.

بمجرد أن يصرح المستخدم للعميل ، سيظهر التطبيق ضمن قسم التطبيقات المعتمدة في صفحة المستخدمون> ملفك الشخصي .

تبادل الرموز

باستخدام خيار OAuth 1.0 مرة أخرى في علامة تبويب المصادقة ، املأ الحقول الخاصة بمفتاح المستهلك وسر المستهلك بالقيم التي يوفرها المستهلك. في المجالات رمز ورمز السري، أدخل oauth_token قيمة والمعلمات oauth_token_secret (أوراق اعتماد مؤقتة).

نظرًا لأنه يمكنني أيضًا تمرير المعلمات في عنوان URL كمعلمات استعلام ، قم بإلحاق معلمة oauth_verifier بعنوان URL على النحو التالي:

 http: // server-dev / oauth1 / access؟ oauth_verifier = <oauth_verifier_value>

مع وجود جميع المعلمات في مكانها الصحيح ، أرسل الطلب بالنقر فوق الزر " إرسال" . إذا سارت الأمور على ما يرام ، فسيرجع الخادم رمز الحالة 200 - OK مع نص الاستجابة الذي يحتوي على معلمات oauth_token و o auth_token_secret .

 oauth_token = <oauth_token_value> & oauth_token_secret = <oauth_secret_value>

في هذه المرحلة ، يتم تجاهل الرموز المميزة التي تم الحصول عليها مسبقًا ولا يمكن استخدامها بعد الآن.

معلمات oauth_token و oauth_token_secret الجديدة هي بيانات اعتماد OAuth التي يمكنك استخدامها في العميل لإنشاء طلبات مصادقة.

إرسال طلب مصدق للاختبار

الآن بعد أن حصلت على بيانات اعتماد الرمز المميز ، سأرسل طلب اختبار إلى الخادم باستخدام Postman. سيتطلب الطلب المعلمات التالية:

ستحتاج إلى ما يلي قبل أن تبدأ:

• oauth_consumer_key
• oauth_consumer_secret
• oauth_token
• oauth_token_secret

حدد OAuth 1.0 من القائمة المنسدلة ضمن علامة تبويب التفويض في Postman.

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

في حالة نجاح الطلب ، سيرسل الخادم رمز الحالة 200 - موافق .

تغليف!

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