التفويض المفتوح (OAuth) هو إطار تفويض مفتوح المعايير يمنح التطبيقات حق الوصول إلى موارد محمية خاصة بالمستخدم النهائي، كالصور أو التقويمات أو منشورات الوسائط الاجتماعية، دون حاجة إلى تسجيل الدخول إلى حساب المستخدم ولا كلمة مروره.
تُعدّ مواقع الويب وتطبيقات الطرف الثالث التي تسأل المستخدم: "هل تريد تسجيل الدخول باستخدام حساب Google؟" أو "هل تريد السماح بالوصول إلى معلومات حسابك؟" حالات استخدام شائعة تستخدم التفويض المفتوح (OAuth). يمكّن بروتوكول التفويض المفتوح المستخدمين من منح هذه التطبيقات الوصول بسهولة إلى بيانات حساباتهم دون الحاجة إلى مشاركة بيانات اعتمادهم.
بالإضافة إلى تطبيقات الويب، يمكن للتفويض المفتوح أيضًا أن يعطي واجهات برمجة التطبيقات والتطبيقات التي تعمل من جانب الخادم وتطبيقات أنظمة التشغيل الأصلية وتطبيقات الأجهزة المحمولة وبعض الأجهزة، كالتلفاز الذكي والأجهزة الذكية، حق الوصول إلى الموارد. لا تتطلب هذه العملية، في بعض الحالات، أي مساعدة من المستخدم البشري حيث يمكن للتفويض المفتوح السماح بالوصول إلى التطبيق نيابةً عن المؤسسة أو نيابةً عن حساب نشاط تجاري.
النشرة الإخبارية الخاصة بالمجال
ابقَ على اطلاع دومًا بأهم—اتجاهات المجال وأكثرها إثارة للفضول—بشأن الذكاء الاصطناعي والأتمتة والبيانات وغيرها الكثير مع نشرة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيتم تسليم اشتراكك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك هنا. راجع بيان خصوصية IBM لمزيد من المعلومات.
يوفر التفويض المفتوح فوائد مهمة لإدارة الوصول للمستخدمين والمطورين والشركات، وذلك بالحفاظ على بيانات تسجيل الدخول من الوصول غير المصرَّح به وتقييد الوصول إلى المعلومات الحساسة الأخرى. كما أنه يسهِّل على التطبيقات الوصول إلى معلومات الحساب الضرورية دون حاجة إلى مشاركة بيانات اعتماد المستخدم، لتفادي مثل هذه الثغرات الأمنية التي يمكن اختراقها.
من خلال تبسيط الوصول الآمن، يمكن لبروتوكول التفويض المفتوح 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):
هذا هو المستخدم النهائي الذي يملك الحساب الذي يحاول التطبيق الوصولَ إليه، مثل حساب Facebook أو Google. يعطي مالكُ الموارد التطبيقَ الموافقة على الوصول إلى بعض الموارد المحمية في هذا الحساب، كالصور مثلاً أو بعض البيانات الشخصية. وفي بعض الحالات، قد يكون مالك الموارد عبارة عن حساب شركة أو حساب نشاط تجاري.
هذا هو الخادم الذي يتم فيه تخزين الموارد المحمية نيابةً عن المستخدم. يستلم خادم الموارد ويقبل رموز OAuth المميزة التي يتلقاها من العميل ويتحقق من صحتها، ثم يعطي المستخدمَ البيانات التي وافق مالكُ المورد على السماح بها لهذا المستخدم.
العميل هو التطبيق، أو موقع الويب، أو واجهة برمجة التطبيقات، أو الجهاز الذي يطلب الوصول. وهو الذي يطلب التفويض من خادم التفويض من خلال تقديم معرِّف العميل. ثم بعد أن يقدم مالك الموارد موافقته على الطلب، يتلقى العميل رمز وصول مميزًا يمكنه استخدامه للوصول إلى الموارد المحمية على خادم الموارد.
هذا هو الخادم الأساسي الذي يوجه بروتوكول OAuth. حيث يقوم بتشغيل نقطتَي النهاية لمنح الوصول إلى خادم الموارد.
تطالب نقطة نهاية التفويض مالك الموارد بتقديم الموافقة على الوصول إلى موارد محمية بعينها. تتلقى نقطة نهاية الرمز المميز طلب الرمز المميز من عميل OAuth وتنشئ رموز وصول مميزة جديدة تمنح الوصول إلى الموارد.
النطاقات هي معلمات الوصول إلى الموارد المحمية على خادم الموارد.
فمثلاً، قد يُطلب من مالك الموارد تقديم الموافقة على الوصول إلى بيانات موجودة في بريد إلكتروني أو في ملفات أو صور. فالنطاق يُقصر وصول العميل على هذا العناصر فقط لا غير.
فيما يلي نظرة عامة أساسية على كيفية عمل تدفق OAuth:
تسمى عملية تزويد التطبيق برمز وصول مميز بعملية منح التفويض أو تدفق التفويض. وتوجد أنواع مختلفة من عمليات منح وتدفق OAuth يمكن استخدامها لأنواع عديدة من التطبيقات أو الأجهزة أو واجهات برمجة التطبيقات، مثل:
يُستخدم هذا النوع من منح التفويض في الغالب مع تطبيقات الويب وتطبيقات الأجهزة المحمولة. في تدفق التفويض، يوفر خادم التفويض رمز التفويض للعميل لمرة واحدة. ثم بعد ذلك، يمكن للعميل استبدال رمز التفويض هذا برمز وصول مميز من نقطة نهاية الرمز المميز الخاصة بخادم التفويض.
يضيف هذا التدفق أمنًا إضافيًّا إلى منح رمز التفويض لحماية التطبيقات من هجمات حقن رموز التعليمات البرمجية. يمكن لهذه الأنواع من الهجمات خداع التطبيقات لتشغيل رموز تعليمات برمجية ضارة قادرة على تغيير طريقة عملها.
يقوم مفتاح التدقيق لتبادل الرموز (PKCE) بإضافة "سر عميل" الذي يصادق العميل مع خادم التفويض قبل إصدار رمز وصول مميز. ولأن العميل الأصلي هو الوحيد الذي يمتلك هذا السر، فلا يمكن لأي مستخدم سيِّئ النية التظاهر بأنه العميل وإدخال رموز تعليمات برمجية ضارة.
تم تصميم هذا النوع من منح التفويض للمواقف التي لا يتدخل فيها أي مستخدم بشري، مثل العمليات المؤتمتة والتفاعلات والخدمات المصغرة التي تتم بين آلة وآلة.
يتم منح التطبيقات حق الوصول إلى موارد النظام التي تحتاج هذه التطبيقات إليها لتنفيذ مهام معينة، لكن لا يتم منحها حق الوصول إلى موارد المستخدم النهائي. فمثلاً، يؤدي منح بيانات اعتماد العميل إلى السماح لأحد تطبيقات الطقس بالوصول إلى واجهة برمجة التطبيقات لاسترداد بيانات حول أحدث توقعات الطقس.
يوفر هذا النوع من منح التفويض تدفقًا أبسط لتطبيقات الويب JavaScript. وعلى عكس منح رمز التفويض، فإن التدفق الضمني لا يتطلب رمز تفويض قبل إصدار رمز مميز للوصول.
بل بعد أن يقدم المستخدم موافقته، يتم تضمين الرمز المميز للوصول في معرِّف الموارد الموحَّد (URI) الخاص بإعادة التوجيه، والذي يقوم بإعادة المستخدم إلى التطبيق الذي يطلب الوصول، ثم يحصل التطبيق على الرمز المميز للوصول من معرِّف URI.
إذا انتهت صلاحية الرمز المميز للوصول، فإن نوع منح التفويض هذا يزود التطبيق برمز مميز محدّث يمكن استبداله برمز جديد مميز للوصول. بدون الرمز المميز المحدّث، سيتعين على المستخدم النهائي تقديم الموافقة مرّة أخرى حتى يتمكن التطبيق من الحصول على رمز وصول جديد.
الفرق الأساسي هو أن تسجيل الدخول الموحَّد (SSO) هو بروتوكول لمصادقة المستخدم، بينما بروتوكول OAuth هو بروتوكول تفويض.
في حالة تسجيل الدخول الموحَّد (SSO)، يتم غالبًا استخدام أحد موفري الهوية (IdP) ولغة ترميز تأكيد الأمن (SAML)، التي تعتمد على لغة التوصيف القابلة للتوسعة (XML)، لمصادقة هويات المستخدمين الرقمية من خلال أسماء المستخدمين وكلمات المرور.
لا يقوم OAuth بمصادقة المستخدمين، لكنه يفوضهم للوصول إلى موارد النظام. في بعض الأحيان، تلجأ حلول SSO إلى استخدام OAuth لتزويد المستخدمين المعتمدين بإمكانية الوصول بسهولة إلى التطبيقات والخدمات عبر المؤسسة.
يُعَدّ OpenID Connect (OIDC) بروتوكول مصادقة قائمًا على OAuth 2.0. ومن خلال عملهما معًا، يمكن لبروتوكول OpenID Connect التحقق من هوية المستخدم، ثم يمكن لبروتوكول OAuth أن يفوّض هذا المستخدم للوصول إلى الموارد والخدمات.