oauth 2.0

OAuth 2.0

يعد OAuth 2.0 إطار عمل تفويض مستخدم على نطاق واسع يسمح لتطبيق (client) بالحصول على وصول محدود إلى الموارد المحمية نيابة عن المستخدم أو التطبيق نفسه.

ما هو OAuth 2.0؟

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

لنرَ مثالًا واقعيًا لفهم أفضل. لديك تطبيق ويب يسمى MyApp يريد الوصول إلى Google Drive الخاص بالمستخدم. بدلًا من مطالبة المستخدم بمشاركة بيانات اعتماد Google Drive الخاصة بهم، يمكن لـ MyApp استخدام OAuth 2.0 لطلب الوصول إلى Google Drive نيابة عن المستخدم. إليك تدفق مبسط:

في هذا التدفق، لا يرى MyApp أبدًا بيانات اعتماد Google Drive للمستخدم. بدلاً من ذلك، يتلقى رمز الوصول (Access token) من Google الذي يسمح له بالوصول إلى Google Drive نيابة عن المستخدم.

المكونات الرئيسية لـ OAuth 2.0

بالنسبة للمثال أعلاه، فإن MyApp هو العميل (Client) ، وGoogle هي كل من خادم التفويض (Authorization server) و خادم الموارد (Resource server) ، والمستخدم هو مالك المورد (Resource owner) . يتضمن التدفق جميع المكونات الأساسية لـ OAuth 2.0:

Client: التطبيق الذي يريد الوصول إلى الموارد المحمية. غالبًا ما يتم استخدام “Client” و”application” بالتبادل.
Resource owner: المستخدم الذي يمتلك الموارد المحمية. يمكن لمالك المورد منح (تفويض) أو رفض الوصول إلى العميل.
Authorization server: الخادم الذي يقوم بالتفويض (عادةً مع المصادقة) ويصدر رموز الوصول للعميل.
Resource server: الخادم الذي يستضيف الموارد المحمية. يتحقق من رمز الوصول ويقدم الموارد المحمية للعميل.

OAuth 2.0 grants (التدفقات)

Grant يبني الأساس لـ OAuth 2.0 ويحدد كيف يمكن للعميل الحصول على رمز للوصول من الخادم التفويض. يحدد مواصفات OAuth 2.0 الأساسية أربعة أنواع من المنح:

دون التعمق في تفاصيل كل منحة، يمكن توقع هذه المنح في فئتين:

Authorization grants: تُستخدم عندما يحتاج العميل إلى الوصول إلى موارد نيابة عن المستخدم، بمعنى آخر يتطلب تفويض المستخدم.
Client credentials grant: تُستخدم عندما يحتاج العميل إلى الوصول إلى الموارد نيابة عنه. هذه المنحة مناسبة للاتصال اتصال الآلة بالآلة (Machine-to-machine) .

Authorization grants

بغض النظر عن نوع المنحة، تتضمن منح التفويض الخطوات الشائعة التالية:

يبدأ العميل طلب الترخيص (Authorization request) إلى خادم التفويض.
يقوم خادم التفويض بالتحقق من المستخدم (مالك المورد) ويطلب إذنًا للوصول إلى الموارد.
يمنح المستخدم إذن الوصول للعميل.
يصدر خادم التفويض رمز وصول للعميل.
يستخدم العميل رمز الوصول للوصول إلى الموارد المحمية على خادم الموارد (Resource server) .

يرجى ملاحظة أن الخطوات والمعلمات الدقيقة قد تختلف اعتمادًا على نوع المنحة. على سبيل المثال، يتضمن authorization code grant خطوات أكثر مثل توليد الرمز والتبادل.

Client credentials grant

تُعد client credentials grant أسهل بكثير ولا تتضمن تفويض المستخدم. إليك تدفق مبسط:

يرسل العميل طلب الرمز (Token request) إلى خادم التفويض.
يتحقق خادم التفويض من العميل ويصدر رمز الوصول.
يستخدم العميل رمز الوصول للوصول إلى الموارد المحمية على خادم الموارد (Resource server) .

للنقاشات المتعمقة حول منح OAuth 2.0، راجع منح OAuth 2.0 (Grant) ومقالات المنح الخاصة.

التحكم في الوصول باستخدام OAuth 2.0

يُعرّف OAuth 2.0 معلمة نطاق (Scope) لتحديد الأذونات التي يطلبها العميل. قد يتجاهل خادم التفويض النطاقات المطلوبة جزئيًا أو كليًا ويمنح الوصول بناءً على سياساته الخاصة بالتحكم في الوصول.

ومع ذلك، يترك OAuth 2.0 لخادم التفويض حرية اتخاذ القرار حول كيفية تنفيذ التحكم في الوصول (Access control) . يعني ذلك أن خادم التفويض يمكنه تحديد الموارد التي يمكن للموضوع (المستخدم أو العميل) الوصول إليها وما هي الإجراءات التي يمكنهم القيام بها على تلك الموارد.

لنبقَ مع مثال Google Drive. قد يبدأ MyApp طلب تفويض للوصول إلى Google Drive الخاص بمستخدم آخر عن طريق الخطأ. في هذه الحالة، يجب على خادم التفويض الخاص بـ Google رفض الطلب لأن المستخدم ليس لديه الأذونات اللازمة للوصول إلى Google Drive خاص بمستخدم آخر.

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

توضح كلتا الحالتين سبب ضرورة التحكم في الوصول (Access control) عند تنفيذ OAuth 2.0. يجب على خادم التفويض (Authorization server) و خادم الموارد (Resource server) العمل معًا لفرض سياسات التحكم في الوصول وحماية الموارد.

نماذج التحكم في الوصول

للتعامل بشكل جيد مع التحكم في الوصول، يُوصى باستخدام نماذج التحكم في الوصول القياسية مثل التحكم في الوصول بناءً على الأدوار (Role-based access control, RBAC) و التحكم في الوصول المستند إلى السمة (Attribute-based Access Control, ABAC) . لقد أثبتت هذه النماذج فعاليتها في الصناعة وتوفر القابلية للتوسع لمتطلبات المستقبل.

OAuth 2.1

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

OAuth 2.0 وOpenID Connect (OIDC)

يعرّف OAuth 2.0 فقط عملية التفويض ولا يغطي توثيق المستخدم أو الهوية. لهذا السبب، تم تقديم OpenID Connect (OIDC) كطبقة هوية على قمة OAuth 2.0. يقوم OIDC بتوسيع OAuth 2.0 لتوفير توثيق المستخدم ومعلومات الهوية في شكل رمز الهوية (ID token) .

يقوم OpenID Connect بتوسيع اثنين من منح OAuth 2.0 (رمز التفويض والمباشر) لتشمل رموز الهوية، ويقدم منحى جديد يسمى hybrid flow الذي يجمع بين كلاهما.

هذا يعني أن كل معارفك وممارساتك في OAuth 2.0 يمكن تطبيقها مباشرة على OIDC؛ وكل توسعات OAuth 2.0 مثل مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) و مؤشر الموارد (Resource indicator) يمكن استخدامها أيضًا في OIDC.