تعريف التفويض المفتح OAuth

الـ OAuth هي اختصاراً للتفويض المفتوح Open Authorization، وهي وسيلة لإشعار مزود خدمة ما (وليكن فيسبوك) بأن مالك الخدمة (وليكن أنت) يمنح تصريحاً لطرف ثالث Third Party (وليكن تطبيق فيسبوك) للوصول إلى معلومات المالك (وليكن قائمة الأصدقاء)

مثال:

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

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

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

يتكون بروتوكول OAuth من:

العميل OAuth Client : وليكن التطبيق الذي يريد الوصول إلى معلوماتك مزود الخدمة OAuth Provider: مثل فيسبوك أو تويتر مثلاً المالك Owner: الشخص الذي لديه حساب على فيسبوك أو تويتر فكرة عمل التفويض المفتوح OAuth

لكي نفهم فكرة العمل سنتخيل سيناريو معين حتى نستطيع توضيح الفكرة من خلاله.

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

الخطوة الأولى تتم عن طريق مبرمج التطبيق، حيث يجب عليه تعريف التطبيق إلى فيسبوك عن طريق Facebook developers site، لكي يتمكن تزويد فيسبوك بمعلومات عن التطبيق مثل (اسمه – عنوانه – الشعار- رابط إعادة التوجيه بعد التفويض)، وعند الإنتهاء من تعريف التطبيق (ماكيومار) يصبح لديه رقم تعريفي Client ID ورقم سري Secret ID مسموح له بالتواصل مع فيسبوك عن طريق بروتوكول OAuth. الآن عندما يقوم شخص بالنقر على زر التسجيل عن طريق فيسبوك، يقوم التطبيق (ماكيومار) بطلب معلومات من فيسبوك عن طريق رقم العميل Client ID ورابط إعادة التوجيه Redirect URI، وهو الرابط الذي سيتم توجيه المستخدم إليه عند نجاح التسجيل، (وليكن صفحة تسجيل الدخول). وبما أن التطبيق يريد الحصول على بعض المعلومات من حسابك، سيقوم فيسبوك بإشعارك بأن التطبيق يريد أن يقوم بذلك، فهل توافق أم لا. عندما تقوم بالموافقة يقوم فيسبوك بعمل توجيه للتطبيق مع تمرير مفتاح يسمى OAuth Code للرابط. فيقوم التطبيق بالتواصل مع فيسبوك عن طريق الـ OAuth Code  للتأكد من أن كل شيء سليم. إذا كان كل شيء سليم سيمنح فيسبوك رمز وصول Access Token للتطبيق. فيقوم التطبيق بالوصول إلى معلومات المالك (أنت) دون الحاجة لكلمة مرور.

ويسمح برتوكول OAuth بالآتي:

يسمح بالقراء أو الكتابة أو الإثنين معاً يمكن عمل تزامن بين المعلومات التحكم في المعلومات التي يمكن الوصول إليها يمكن إلغاء الإتصال في أي وقت

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

OAuth 0.2

OAuth 0.2 هو الإصدار الثاني من بروتوكول OAuth  (يسمى أيضا عمل Framework).

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

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

تعاريف أساسية الأدوار Roles

الأدوار هنا يقصد بها الجهات التي تكون موجودة ضمن عملية التفويض، ويحدد OAuth 0.2 أربعة أدوار:

مالك الموارد Resource Owner: صاحب الحساب المُراد الوصول إلى معلوماته (غالباً ما يكون أنت). مزود الخدمة Resource Server: خادم استضافة البيانات المحمية (على سبيل المثال جوجل يستضيف ملفك الشخصي والمعلومات الشخصية). العميل Client: التطبيق الذي يطلب الوصول إلى مزود الخدمة (يمكن أن يكون موقع الويب الخاص بك، تطبيق جافا سكريبت أو تطبيقات الهاتف). خادم التفويض Authorization Server: الخادم الذي يصدر الرمز المميز Access Token  للعميل. سيتم استخدام هذا الرمز المميز للعميل عند التواصل مع مزود الخدمة. يمكن أن يكون هذا الخادم هو نفسه مزود الخدمة، وغالبا ما يكون الأمر كذلك وتوكون واجهته البرمجية هي المسؤلة عن إعطاء التفويضات ورموز الوصول Access Tokens. الرمز المميز Access Token

الرموز المميزة هي سلاسل عشوائية تم إنشاؤها بواسطة خادم التفويض Authorization Server ويتم إصدارها عندما يطلب العميل (التطبيق) ذلك. وهي التي تسمح للعميل بالوصول للمعلومات ولن يتم منح هذا الرمز إلا بعد أن تتم جميع عمليات المصادقة والتحقق من ملكية الحساب وأن التطبيق مسموح له بذلك.

هناك نوعان من الرمز المميز:

رمز الوصول المميز Access Token

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

رمز التحديث المميز Refresh Token

يتم إصدار هذا الرمز مع رمز الوصول المميز Access Token ولكن على عكس الأخير، لا يتم إرساله في كل طلب من العميل إلى مزود الخدمة. ولكن يتم إرساله إلى خادم التفويض Authorization Server لتجديد رمز الوصول Access Token عند انتهاء صلاحيته. ولأسباب أمنية، ليس من الممكن دائما الحصول على رمز التحديث المميز. سنرى لاحقا الظروف التي يحدث فيها ذلك.

نطاقات الرمز المميز Scope

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

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

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

وإذا لاحظت أنه يطلب منك السماح للتطبيق بالوصول إلى معلومات حسابك العامة والبريد الإلكتروني “your public profile and email address”.

HTTPS

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

تسجيل كعميل

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

وهنا المعاملات (قد تختلف اعتمادا على مزود الخدمة) ولكن بشكل عام هذه المعاملات جزء منها يخص العميل ويتم تعريفه عند تسجيل العميل لدى مزود الخدمة والآخرى التي سيتم إرجاعها بواسطة خادم التفويض في الرد HTTP Response:

تسجيل العميل

عند تسجيل عميل (تطبيق) يجب إرسال هذه المعلومات إلى خادم التفويض

اسم التطبيق رابط إعادة توجيه: يكون رابط UR خاص بالتطبيق لتلقي رمز التفويض OAuth Code ورمز الوصول المميز Access Token النطاق Scope: وهي المعلومات التي يريد العميل الحصول عليها جافاسكريبت الأصل (اختياري): اسم المضيف الذي سيتم السماح له بتبادل المعلومات مع مزود الخدمة عن طريق XMLHttpRequest رد خادم التفويض Authorization server response

بعد تسجيل معلومات العميل وطلب المعلومات من خادم التفويض يقوم خادم التفويض بالرد بالآتي:

رقم العميل Client ID: ويكون سلسلة نصية عشوائية لكن لا مشكلة في أن تكون عامة الرقم السري للعميل Client Secret: وهو أيضاً سلسة نصية ويجب دائماً أن يكون سرياً أنواع التفويض Authorization Grant Types

هناك أربع حالات لمنح التفويض، يتم تصنيفها حسب موقع وطبيعة العميل (التطبيق) الذي يطلب كود التفويض، حيث يتم التفويض إما عن طرق:

منح كود للتفويض Authorization Code Grant أو المنح الضمني Implicit Grant أو منح معلومات كلمة المرور الخاصة بمالك الخدمة Password Grant أو منح معلومات العميل نفسه Client Credentials Grant منح كود للتفويض Authorization Code

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

مثال:
مالك الموارد: أنت
خادم الموارد: جوجل
العميل: أي موقع
خادم التفويض: جوجل

سيناريو:

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

يأخذ شكل الرابط الخاص بالتسجيل هذا الشكل

https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx

بحيث يكون:

code: يشير إلى أن الخادم  الخاص بالعميل يتوقع تلقي رمز تفويض client_id: معرف العميل الذي تلقيته عند تسجيل التطبيق عند مزود الخدمة لأول مرة redirect_uri: وهو رابط لإعادة توجيه المستخدم إليه بعد اكتمال التفويض scope: هي النطاق وتشير إلى المعلومات التي يحتاج التطبيق للوصول إليها في حساب المستخدم الذي تريد الدخول إليه (وليكن قراءة أو قراءة وكتابة) state: سلسلة نصية عشوائية تم إنشاؤها بواسطة التطبيق، والتي سنعرف فائدتها لاحقا

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

عندما يقوم بالنقر على Allow يتم توجيه المستخدم مرة أخرى للتطبيق مع كود التفويض OAuth Code

https://example-app.com/cb?code=AUTH_CODE_HERE&state=1234zyx

بحيث يكون:

code: هو كود التفويض OAuth Code state: هو الرقم العشوائي الذي قام التطبيق بإرساله، حيث يقوم خادم التفويض بإرجاعه مرة أخرى للتطبيق

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

ثم يقوم التطبيق بمقايضة كود التفويض OAuth code برمز الوصول Access Token عن طريق إرسال هذه المعلومات لخادم التفويض

POST https://api.authorization-server.com/token grant_type=authorization_code& code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET

بحيث يكون:

grant_type: هو نوع التفويض المطلوب للتطبيق code: لإضافة كود التفويض redirect_uri: رابط إعادة التوجيه ويجب أن يكون مطابق للرابط الذي يتم إرساله عند طلب التفويض client_id: رقم العميل الذي الخاص بالتطبيق والذي يتم توليده عند تسجيله أول مرة عند مزود الخدمة client_secret: مادام الطلب قادم من خادم، يجب تمرير الرقم السري للتطبيق

فيقوم خادم التفويض بالرد هكذا:

{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "expires_in":3600 }

أو إن كان هناك خطأ يكون الرد هكذا

{ "error":"invalid_request" }

بالطبع لا ترى الرمز المميز للوصول Access Token، ولكن سيتم تخزينها من قبل الموقع (في الجلسة Session على سبيل المثال). وترسل جوجل أيضا معلومات أخرى مع الرمز المميز للوصول، مثل الصلاحية ورمز التحديث المميز Refresh Token.

هذا هو السيناريو المثالي والأكثر أمانا لأن رمز الوصول لا يتم تمريره للعميل مباشرة. (المتصفح في حالتنا).

 

المنح الضمني Implicit Grant

النوع الثاني من منح التفويص هو المنح الضمني، ويتم استخدامه عادة عندما يكون العميل يعمل من خلال متصفح Web Browser باستخدام أحد لغة البرمجة النصية scripting language  مثل جافاسكريبت، أو بمعنى آخر هي التطبيقات التي لا تحافظ على سرية الرقم السري Client Secret. وهذا النوع لايسمح بمنح رمز التحديث المميز. ويتم إرسال رمز الوصول المميز Access token مباشرة دون الحاجة لخطوة تبادل كود التفويض OAuth Code مع رمز الوصول Access Token

ويكون سريان عملية التفويض بهذا التسلسل:

يقوم المستخدم بتفويض التطبيق يقوم خادم التفويض بإرسال رمز الوصول Access Token مباشرة للتطبيق

مثال:
مالك الموارد: أنت
مزود الخدمة: فيسبوك
العميل: موقع ويب يستخدم AngularJS
خادم التفويض: فيسبوك

سيناريو:

العميل (AngularJS) يريد الحصول على معلومات حول ملفك الشخصي في فيسبوك. تتم إعادة توجيهك بواسطة المتصفح إلى خادم التفويض (فيسبوك). إذا سمحت بالدخول، يعيد خادم التفويض توجيهك إلى موقع الويب مع إرفاق الرمز المميز للوصول Access Token ويتم تمريره للرابط (لن يتم إرساله إلى خادم الويب). مثال على رد الاتصال: http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN يمكن الآن استخدام رمز الوصول من قبل العميل (AngularJS) لتواصل مع فيسبوك.

مثال على ذلك:

https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN

والشكل التالي يوضح تسلسل العملية بالكامل

 

منح معلومات كلمة المرور الخاصة بمالك الخدمة Password Grant

عندما تحدثنا عن منح كود التفويض OAuth code، ذكرنا أنه تتم عملية مقايضة/تبادل بين  العميل وخادم التفويض بحيث يقوم العميل بإرسال OAuth code فيقوم خادم التفويض بإرسال رمز الوصول المميز Access Token، لكن هنا يقوم العميل بإرسال معلومات الدخول نفسها (كلمة المرو) بدلاً من OAuth code.

مع هذا النوع من التفويض، يتم إرسال معلومات دخول المالك (كلمة المرور) إلى العميل ومن ثم إلى مزود الخدمة. ولذلك، لا بد من وجود ثقة مطلقة بين هذين الكيانين. وغالباً ما يُستخدم هذا النوع عندما يتم تطوير العميل (التطبيق) من قبل الكيان المسؤل عن خادم التفويض.

على سبيل المثال، يمكننا تصور موقع ويب باسم example.com يسعى إلى الوصول إلى الموارد المحمية في نطاقه الفرعي api.example.com. ليس من العجب أن يقوم المستخدم بكتابة اسم المستخدم / كلمة المرور على الموقع example.com فالمصدر واحد في النهاية ولا خوف من ذلك.

مثال:
مالك الموارد: لديك حساب على موقع acme.com
مزود الخدمة : شركة ACME والتي لها واجهة برمجية في api.acme.com
العميل: الموقع الإلكتروني للشركة  acme.com
خادم التفويض: acme

سيناريو:

شركة ACME، تفكر في توفر RESTful API لتطبيق طرف ثالث. وتعتقد الشركة أنه سيكون من المناسب استخدام API الخاصة بها لتجنب إعادة اختراع العجلة. هنا ستحتاج الشركة إلى رمز مميز للدخول إلى وظائف API الخاصة بها. لهذا، تطلب منك الشركة إدخال بيانات الدخول عبر نموذج HTML Form عادي. سيقوم التطبيق (موقع acme.com) باستبدال معلومات الدخول برمز وصول تم توليده من خادم التفويض (إذا كانت بيانات الاعتماد صالحة، بالطبع).

[highlight background=”” color=””]بصيغة أبسط، سيتم توليد رمز الوصل مقابل معلومات الدخول الخاصة بالمالك مباشرة مادامت معلومات الدخول الخاصة بالمالك سليمة، دون الحاجة لعمليات مصادقة[/highlight]

هذا التطبيق يمكنه الآن استخدام رمز الوصول لطلب المعلومات من مزود الخدمة (api.acme.com).

ويأخذ شكل طلب التفويض في هذه الحالة الشكل التالي

POST https://api.authorization-server.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID

 

منح معلومات العميل نفسه Client Credentials Grant

يتم استخدام هذا النوع من التفويض عندما يكون العميل هو نفسه مزود الخدمة. وهنا لاحاجة للحصول على إذن من المالك.

فإذا كان مزود الخدمة مثلاً لديه تطبيق خاص به ويحتاج وسيلة تسمح للتطبيق بتحديث المعلومات الخاصة به مثل URL الخاص بالموقع  أو أيقونات، أو أنها قد ترغب في الحصول على إحصاءات حول مستخدمي التطبيق. في هذه الحالة، يحتاج التطبيقات إلى طريقة للحصول على رمز وصول لحسابهم الخاص، وليس له علاقة بمستخدم معين. في هذه الحالة يتم تمرير معلومات التطبيق نفسه Client_id and Client_secret

مثال:
مالك الموارد: أي موقع
مزود الخدمة: جوجل كلاود ستوريج
العميل: مالك المورد
خادم التفويض: خادم جوجل

سيناريو:

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

ويأخذ شكل طلب التفويض الشكل التالي

POST https://api.authorization-server.com/token grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET

..

كيفية استخدام رمز الوصول Access Token

يمكن إرسال رمز الوصول المميز بعدة طرق لمزود الخدمة.

عن طريق GET or POST باستخدام URL هكذا https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN عن طريق الـ Request Headers GET /profile HTTP/1.1 Host: api.example.com Authorization: Bearer MzJmNDc3M2VjMmQzN

لكن لن يسمح مزودو الخدمات باستقال الـ Headers بهذا الشكل لضعف احتياطات الأمان

عن طريق cURL curl -H "Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia" \ https://api.authorization-server.com/1/me الأمان

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

جوانب الضعف في منح كود التفويض OAuth Code

هناك ضعف ما في هذا النوع من منح التفويض والذي قد يسمح للمهاجم بسرقة حساب المستخدم في ظل ظروف معينة. وغالبا ما يحدث هذا والعديد من المواقع المعروفة (مثل بينتيريست، ساوند كلاود، ديغ، …) لم تنجو منه، حيث لم يتم تنفذ البروتوكول بشكل صحيح.

أمثلة على جوانب الضعف:

لدى الضحية حساب صالح على موقع ويب يسمى A. والموقع A يسمح للمستخدم بالدخول أو التسجيل عن طريق الفيسبوك وهذا الموقع مُسجل مسبقاُ كعميل في خادم OAuth2 لفيسبوك.  إذن يمكنك النقر على زر الاتصال بالفيسبوك من الموقع A ولكن لا يتم إعادة توجيهك بسبب إضافة فايرفوكس  NoRedirect أو باستخدام  Burp لكن فيسبوك قام بتوليد رمز الدخول وأرفقه برابط الموقع وعلى سبيل المثال يبدو رابط إعادة التوجيه هكذا: http://site-internet-a.com/facebook/login?code = OGI2NmY2NjYxN2Y4YzE3 هنا يمكنك الحصول على الربط (الذي يحتوي على رمز التفويض) الذي كان من المفترض إعادة توجيهك إليه (يمكنك رؤيته في Firebug). الآن لديك القدرة على إجبار الضحية على زيارة هذا الرابط عبر IFrame مخفي على موقع ما أو عن طريق صورة في رسالة بريد إلكتروني على سبيل المثال. إذا كانت الضحية مسجلة في موقع A، ثم قام بالنقر على الرابط فسيتم السماح لحساب الفيسبوك صاحب رمز الوصول الموجود في الرابط بالدخول إلى هذا الحساب (حساب الضحية) الآن لديك حق الوصول إلى حساب الضحية في الموقع A باستخدام حساب الفيسبوك الخاص بك. وكل ما عليك الآن هو فقط النقر على زر الدخول عن طريق الفيسبوك وسوف تكون متصلا مع حساب الضحية. كيفية الحماية

هناك طريقة لمنع ذلك عن طريق إضافة مُعامل “state”.وهو الموصى به فقط وغير إجباري في المواصفات. بحيث إذا قام العميل بإرسال هذا المعامل عند طلب رمز تفويض فإنه سيتم إرجاعه مرة أخرى دون تغيير من قبل خادم التفويض في الرد HTTP Response وسيتم مقارنته من قبل العميل قبل فحص رمز التفويض OAuth Code مقابل رمز الوصول Access Token.هذا المعامل يتتطابق بشكل عام مع  رقم عشوائي مشفر يتم تخزينه في جلسة المستخدم User Session.

على سبيل المثال في PHP يمكن توليد هذا الرقم العشوائي هكذا

sha1(uniqid(mt_rand(), true))

وبالتالي في مثالنا السابق، إذا كان الموقع “A” يستخدم المعامل “state”، سيدرك أن الرمز المشفر لا يتطابق مع المخزن في جلسة الضحية، وبالتالي يمنع سرقة حساب الضحية.

جوانب الضعف في المنح الضمني

هذا النوع من التراخيص هو الأقل أمانا لأنه يعرض الرمز المميز للوصول (جافا سكريبت معظم الوقت). هناك فجوة كبيرة تنبع من حقيقة أن العميل لا يعرف ما إذا تم إنشاء رمز الوصول له أو لا. وهذا يسمح للمهاجم لسرقة حساب المستخدم.

مثال:

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

ولتجنب ذلك، يجب أن يوفر خادم التفويض في واجهته البرمجية API طريقة لاسترداد معلومات الدخول المميز. وهكذا، فإن الموقع A يكون قادر على مقارنة client_id الخاص برمز الوصول القادم من المهاجم مع client_id الخاصة به. وبما أن الرمز المميز المسروق قد تم إنشاؤه من أجل الموقع B، فيكون هناك اختلاف في client_id، ويتم رفض الاتصال.

فضلاً لاتتردد في ترك استفساراتك في التعليقات فهذا يسعدني ويشعرني بالتفاعل الذي يدفعني دائماً لتقديم كل ما في الإمكان لنشر معلومة قيمة
وفقنا الله وإياكم 🙂