ما المقصود بالتفويض المفتوح (OAuth)؟

تُعدّ مواقع الويب وتطبيقات الطرف الثالث التي تسأل المستخدم: "هل تريد تسجيل الدخول باستخدام حساب Google؟" أو "هل تريد السماح بالوصول إلى معلومات حسابك؟" حالات استخدام شائعة تستخدم التفويض المفتوح (OAuth). يمكّن بروتوكول التفويض المفتوح المستخدمين من منح هذه التطبيقات الوصول بسهولة إلى بيانات حساباتهم دون الحاجة إلى مشاركة بيانات اعتمادهم.

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

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

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

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

وفي عام 2012، أصدر فريق عمل هندسة الإنترنت (IETF) بروتوكول OAuth 2.0 تحت مسمى RFC 6749 و RFC 6750. ويُعَدّ RFC (طلب تعليقات) مستند IETF يصف بروتوكولات الاتصالات عبر الإنترنت. ويُعدّ RFC 6749 الإطار الأساسي لبروتوكول OAuth 2.0، بينما يتولى RFC 6750 تحديد كيفية استخدام الإطار لرموز الوصول المميزة.

أدى هذا الإصدار المحدَّث من OAuth إلى توسيع قدرات البروتوكول إلى ما هو أكبر من متصفحات الويب لتشمل قدرات تفويض للتطبيقات ولواجهات برمجة التطبيقات وللأجهزة. وقد حل بروتوكول OAuth 2.0 محل البروتوكول OAuth 1.0، ويُعدّ المعيار السائد حاليًّا في هذه الصناعة.

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

وتستخدم رموز OAuth المميزة في الغالب معيار JSON Web Token (JWT) لقدرته على نقل البيانات بشكل آمن.

فيما يلي العناصر الأساسية لإطار التفويض المفتوح (OAuth):

• مالك الموارد
• خادم الموارد
• عميل
• خادم التفويض
• النطاق

فيما يلي نظرة عامة أساسية على كيفية عمل تدفق OAuth:

1. مثلاً يريد أحمد (مالك الموارد) السماح لأحد مواقع التواصل الاجتماعي (العميل) بالوصول إلى جهات اتصال بريده الإلكتروني (الموارد).
   
   
2. يُطالب خادم تفويض البريد الإلكتروني أحمد بتقديم موافقته على هذا الوصول.
   
   
3. بعد الحصول على موافقة أحمد، يقوم خادم التفويض بتزويد موقع التواصل الاجتماعي برمز وصول مميز.
   ⏎
   
4. يقدم موقع التواصل الاجتماعي رمز الوصول إلى خادم الموارد الذي يقوم بتخزين معلومات حساب البريد الإلكتروني الخاص بأحمد.
   
   
5. يتعرف خادم الموارد على الرمز المميز للوصول ويمنح موقع التواصل الاجتماعي إمكانية الوصول إلى جهات اتصال البريد الإلكتروني الخاصة بأحمد. ولأن الرمز المميز للوصول يتضمن نطاق موافقة أحمد، فلا يمكن لموقع التواصل الاجتماعي الوصول إلى أي بيانات أخرى موجودة في حساب أحمد
   

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

• رمز التفويض
• مفتاح التدقيق لتبادل الرموز (PKCE)
• بيانات اعتماد العميل
• المنحة الضمنية
• الرمز المميز المحدّث

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

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

يقوم مفتاح التدقيق لتبادل الرموز (PKCE) بإضافة "سر عميل" الذي يصادق العميل مع خادم التفويض قبل إصدار رمز وصول مميز. ولأن العميل الأصلي هو الوحيد الذي يمتلك هذا السر، فلا يمكن لأي مستخدم سيِّئ النية التظاهر بأنه العميل وإدخال رموز تعليمات برمجية ضارة.

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

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

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

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

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

الفرق الأساسي هو أن تسجيل الدخول الموحَّد (SSO) هو بروتوكول لمصادقة المستخدم، بينما بروتوكول OAuth هو بروتوكول تفويض.

في حالة تسجيل الدخول الموحَّد (SSO)، يتم غالبًا استخدام أحد موفري الهوية (IdP) ولغة ترميز تأكيد الأمن (SAML)، التي تعتمد على لغة التوصيف القابلة للتوسعة (XML)، لمصادقة هويات المستخدمين الرقمية من خلال أسماء المستخدمين وكلمات المرور.

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

يُعَدّ OpenID Connect (OIDC) بروتوكول مصادقة قائمًا على OAuth 2.0. ومن خلال عملهما معًا، يمكن لبروتوكول OpenID Connect التحقق من هوية المستخدم، ثم يمكن لبروتوكول OAuth أن يفوّض هذا المستخدم للوصول إلى الموارد والخدمات.