مستقبل التفويض: لماذا يعتبر OAuth 2.0 مجرد البداية

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

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

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

في هذه المقالة، سنقدم نظرة عامة حول كيفية عمل OAuth 2.0 وحالات الاستخدام الشائعة وأفضل الممارسات ونقاط الضعف. سننظر أيضًا إلى ما هو أبعد من OAuth في بروتوكولات التفويض والمصادقة الأكثر تقدمًا التي تهدف إلى تعزيز الأمان - OpenID Connect وTLS المتبادل وWebAuthn. في النهاية، سيكون لديك فهم قوي لـ OAuth 2.0 وكيفية استخدامه بأمان. بالإضافة إلى ذلك، سوف تكتسب نظرة ثاقبة للمعايير والتقنيات الجديدة التي تتجاوز OAuth لمزيد من التحكم الآمن في الوصول للتطبيقات الحديثة.

كيف يعمل بروتوكول OAuth 2.0

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

يحدد OAuth 2.0 أربعة تدفقات ترخيص رئيسية:

تدفق رمز التفويض

يعد تدفق رمز التفويض مناسبًا بشكل أفضل للعملاء السريين مثل تطبيقات الويب. يتضمن رمز ترخيص وسيط لتبادل رمز الوصول:

1. يقوم تطبيق العميل بإعادة توجيه المستخدم إلى خادم الترخيص لتسجيل الدخول والموافقة على الوصول.
2. يقوم خادم التفويض بالمصادقة على المستخدم وإعادة التوجيه مرة أخرى باستخدام رمز التفويض.
3. يقوم العميل باستبدال رمز التفويض برمز وصول.
4. يمكن للعميل استخدام رمز الوصول لإجراء مكالمات API للوصول إلى الموارد.

يوفر هذا التدفق أمانًا متزايدًا لأن رمز الوصول لا يتم إرساله مباشرة عبر متصفح المستخدم.

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

1. يقوم تطبيق العميل بإعادة توجيه المستخدم إلى خادم الترخيص لتسجيل الدخول والموافقة على الوصول.
2. يقوم خادم التفويض بمصادقة المستخدم وإعادة التوجيه مرة أخرى باستخدام رمز وصول في جزء عنوان URL.
3. يمكن للعميل استخدام رمز الوصول لإجراء مكالمات API للوصول إلى الموارد.

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

مقارنة التدفقات

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

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

إيجابيات وسلبيات OAuth 2.0

** الايجابيات: **

• تفويض مفوض دون مشاركة بيانات اعتماد المستخدم
• تدفقات تفويض مرنة لمختلف أنواع العملاء
• اعتماد واسع النطاق عبر المنصات ومقدمي الخدمات الرئيسيين

** سلبيات: **

• التعقيد يؤدي إلى أخطاء شائعة في التنفيذ
• يعتمد على HTTPS وسرية الرمز المميز للأمان
• يمكن أن تتسرب رموز الوصول إذا لم تكن محمية بشكل صحيح
• سياق مستخدم مدمج محدود خارج النطاقات

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

حالات استخدام OAuth 2.0

يُستخدم OAuth 2.0 بشكل شائع لتمكين تدفقات التفويض في مجموعة واسعة من التطبيقات والخدمات عبر الإنترنت. تتضمن بعض حالات الاستخدام والأمثلة الأكثر شيوعًا ما يلي:

• تسجيل الدخول عبر وسائل التواصل الاجتماعي - تستفيد خدمات مثل Facebook وTwitter وGoogle وGitHub من OAuth 2.0 لتمكين المستخدمين من “تسجيل الدخول باستخدام” بيانات اعتماد النظام الأساسي الخاصة بهم. يسمح هذا للمستخدمين بالتخلي عن إنشاء حسابات جديدة، وبدلاً من ذلك يسمح لهذه المواقع بالاتصال بملفاتهم الاجتماعية الحالية.

• ترخيص التطبيق - غالبًا ما تدمج تطبيقات الهاتف المحمول وسطح المكتب بروتوكول OAuth لتخويل الوصول إلى واجهات برمجة تطبيقات REST. على سبيل المثال، قد يستخدم أحد التطبيقات بروتوكول OAuth للوصول إلى صور المستخدم في خدمة التخزين السحابية، أو جهات الاتصال في خدمة دفتر العناوين، أو البيانات الأخرى من موفر واجهة برمجة التطبيقات.- الأمان وتسجيل الدخول الموحد - يسمح OAuth بالمصادقة المركزية من خلال موفر هوية واحد، بدلاً من إدارة بيانات الاعتماد لكل تطبيق على حدة. يعد أسلوب تسجيل الدخول الموحد (SSO) هذا شائعًا في بيئات المؤسسات لتحسين الأمان والراحة.

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

• تكامل الخدمة - يتيح OAuth التكامل السلس بين الأنظمة الأساسية المختلفة من خلال تدفقات التفويض ورموز الوصول المميزة. يمكن للخدمات الاتصال مباشرة ببعضها البعض عبر واجهات برمجة التطبيقات (APIs) نيابة عن المستخدمين، وتجنب الاحتكاك والمتاعب في إجراء خطوات مصادقة زائدة عن الحاجة.

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

أفضل ممارسات OAuth 2.0

للاستفادة الكاملة من المزايا الأمنية لـ OAuth 2.0، من المهم اتباع أفضل الممارسات المتعلقة بالتسجيل والمفاتيح والرموز المميزة ورموز التحديث المميزة.

التسجيل والتعامل مع المفاتيح

• استخدم HTTPS لنقاط نهاية التفويض والرمز المميز. وهذا يحمي من هجمات الرجل في الوسط.

• إنشاء مفاتيح قوية للتشفير مع إنتروبيا كافية. أحجام المفاتيح الموصى بها هي 2048 بت لـ RSA و256 بت لـ EC.

• لا تقم أبدًا بتشفير أسرار العميل في التطبيقات أو مشاركة الأسرار مع أطراف غير موثوقة. تخزين الأسرار بشكل آمن على جانب الخادم.

• قم بتعيين أوقات انتهاء صلاحية قصيرة لرموز التفويض، حوالي 10 دقائق. وهذا يقلل من نافذة الاعتراض.

• إبطال أسرار العميل المكشوفة على الفور وإنشاء مفاتيح جديدة.

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

• احتفظ برموز الوصول لفترة قصيرة، حوالي ساعة واحدة. يمكن أن يكون لرموز التحديث انتهاء صلاحية أطول، حوالي أسبوعين.

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

• تحقق دائمًا من صحة جمهور الرمز المميز لمطابقة الجمهور المتوقع لواجهة برمجة التطبيقات (API) الخاصة بك.

• تحقق من تطابق جهة الإصدار مع مجال خادم التفويض الخاص بك.

• التحقق من خوارزمية توقيع الرمز المميز والمفتاح مقابل المفاتيح الموثوقة المعروفة.

تحديث الرموز- قم بإصدار رموز التحديث المميزة فقط لتطبيقات وأجهزة الطرف الأول الموثوقة. تجنب توفير رموز التحديث لعملاء الجهات الخارجية.

• ربط رموز التحديث بمعرف عميل واحد محدد ومجموعة هوية المستخدم.

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

• رموز التحديث الآمنة المكافئة للترخيص طويل المدى. الإرسال فقط عبر HTTPS وتقييد الوصول من خلال التشفير.

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

نقاط الضعف في OAuth 2.0

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

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

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

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

• انتحال هوية المستخدم - يسرق المهاجم بيانات اعتماد المستخدم أو يخمنها ويستخدمها للمصادقة كمستخدم والوصول إلى بياناته.

• تدفقات OAuth المعطلة - قد يؤدي التنفيذ غير الصحيح لتدفقات OAuth والتحقق من الصحة إلى ترك نقاط النهاية مفتوحة للاستغلال. يمكن للمهاجمين إساءة استخدام العيوب في التحقق من صحة redirect_uri، ومعلمات الحالة، وإصدار الرمز/الرمز المميز للحسابات المخترقة.

• تزوير الطلبات عبر المواقع (CSRF) - يمكن للمهاجمين إجبار المستخدمين المصادقين على تقديم طلبات نيابة عنهم دون علمهم من خلال استغلال اعتماد OAuth على إعادة توجيه المتصفح للتدفقات.

• فتح عمليات إعادة التوجيه - قد يؤدي السماح بعمليات إعادة التوجيه المفتوحة بعد تسجيل الدخول إلى OAuth إلى السماح للمهاجمين بإعادة توجيه المستخدمين إلى مواقع التصيد الاحتيالي وسرقة بيانات الاعتماد أو الرموز المميزة.

لمنع إساءة استخدام OAuth، يعد التنفيذ الصحيح أمرًا بالغ الأهمية:

• استخدم معلمات الحالة والرقم لمنع CSRF
• فرض تسجيل العميل الآمن والتحقق من صحته
• الاستفادة من قنوات الاتصال المشفرة
• تعيين أوقات انتهاء قصيرة على الرموز
• إلغاء الرموز عندما لم تعد هناك حاجة إليها
• استخدم رموز التحديث بشكل مقتصد وبعناية
• اتبع أفضل ممارسات OAuth للتحقق من الصحة وإعادة التوجيهبينما يوفر OAuth 2.0 إطارًا موحدًا للترخيص، يجب على المؤسسات الاهتمام بتخفيف نقاط الضعف من خلال التنفيذ السليم وضوابط الأمان وسياسات الوصول القوية. تعتمد البروتوكولات الإضافية مثل OpenID Connect على OAuth لتعزيز الأمان، مما يوضح الحاجة إلى التطوير المستمر.

الانتقال إلى ما بعد OAuth 2.0

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

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

• عدم تشفير الرموز المميزة افتراضيًا - غالبًا ما يتم إرسال رموز OAuth 2.0 المميزة غير مشفرة، مما يجعلها مفتوحة للاعتراض. تتطلب المواصفات https لتدفق التفويض، ولكن لا يزال من الممكن إرسال رموز الوصول بشكل واضح.

• لا توجد طرق مدمجة للتحقق من الهوية - يركز OAuth 2.0 على التفويض وتفويض الوصول. ولا يتحقق من هوية المستخدم. وهذا يترك مجالًا لهجمات انتحال الشخصية.

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

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

• معايير التشفير المحدودة - يدعم OAuth 2.0 فقط التشفير الأقدم مثل SHA-1. الخوارزميات الحديثة الأقوى مثل SHA-256 ليست مدمجة في المواصفات الأساسية.

مع تطور التهديدات، وصلت قدرات OAuth 2.0 للحماية منها إلى حدودها القصوى. على الرغم من أن OAuth 2.0 لا يزال قيد الاستخدام على نطاق واسع، إلا أنه يحتاج إلى تعزيزه واستبداله بمعايير ترخيص أكثر قوة وحداثة لحالات استخدام معينة. يوفر استكشاف البروتوكولات مثل OpenID Connect وTLS المتبادل وWebAuthn خيارات لتوفير أمان أقوى في المستقبل.

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

يسمح OpenID Connect للعملاء بالتحقق من هوية المستخدم من خلال المصادقة مع خادم الترخيص. يتيح ذلك للعميل الحصول على معلومات الملف الشخصي الأساسية للمستخدم. يستخدم OpenID Connect JWT (JSON Web Tokens) التي تحتوي على مطالبات حول مصادقة المستخدم، والتي يمكن تمريرها مرة أخرى إلى العميل.

بعض حالات الاستخدام الرئيسية حيث يعمل OpenID Connect على تحسين الأمان:

• تسجيل الدخول الموحد (SSO) - يسمح OpenID Connect بتسجيل الدخول الموحد البسيط عبر مواقع وتطبيقات متعددة. تتم معالجة المصادقة بواسطة خادم ترخيص موفر الهوية، لذلك لا تحتاج المواقع إلى معالجة المصادقة الخاصة بها.

• زيادة التكامل - يحتوي رمز المعرف على مطالبات موقعة تم التحقق منها بشكل آمن بواسطة موفر الهوية. يوفر هذا ضمانات تكامل أفضل من رموز وصول OAuth القياسية.

• الوصول إلى ملف تعريف المستخدم - يوفر OpenID Connect اختياريًا إمكانية الوصول إلى معلومات ملف تعريف المستخدم النهائي، مما يمنح العميل سياقًا إضافيًا حول هوية المستخدم دون الحاجة إلى استدعاءات API إضافية.

• ثقة أعلى في الهوية - توفر المعايير المتعلقة باستخدام النطاق ومطالبات JWT والتشفير ثقة أكبر في أن المستخدم هو من يدعي مقارنةً بـ OAuth الأساسي.

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

TLS المتبادل لمصادقة أقوى

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

إليك كيفية عمل مصادقة mTLS:

• يبدأ العميل المصافحة عن طريق إرسال شهادة العميل الخاصة بالخادم. يتم إصدار هذه الشهادة من مرجع مصدق موثوق به (CA) وتتحقق من هوية العميل.

• يقوم الخادم بعد ذلك بتوفير شهادة الخادم الخاصة به للعميل. يتم التحقق من صحة هذه الشهادة مقابل المرجع المصدق الموثوق به لمصادقة هوية الخادم.- يتفاوض العميل والخادم على جلسة TLS مشفرة إذا نجح الطرفان في التحقق من صحة شهادات بعضهما البعض. يؤدي هذا إلى إنشاء قناة اتصال ثنائية الاتجاه معتمدة.

• يمكن الآن للعميل والخادم تبادل البيانات بشكل آمن من خلال نفق TLS المشفر مع العلم أنه تم التحقق من الهويات على كلا الطرفين.

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

استخدم الحالات التي يعمل فيها mTLS على تحسين الأمان:

• تأمين الاتصالات بين الخدمات المصغرة. يمنع mTLS الخدمات الصغيرة غير المصرح بها من الانضمام إلى الشبكة.

• المصادقة على ربط كبسولات Kubernetes داخليًا. يتحقق mTLS من هويات البودات التي تتواصل داخل المجموعة.

• تأمين اتصالات أجهزة إنترنت الأشياء. يقوم mTLS بتأمين الاتصال من جهاز إلى جهاز عن طريق طلب شهادات العميل.

• المعاملات المصرفية والمالية. يضمن mTLS سلامة المعاملات بين الأنظمة المالية.

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

##WebAuthn/FIDO2

يعد WebAuthn (مصادقة الويب) وFIDO2 من معايير الويب الناشئة التي توفر بديلاً للمصادقة التقليدية المستندة إلى كلمة المرور.

يسمح WebAuthn لمواقع الويب بتسجيل المستخدمين ومصادقتهم باستخدام تشفير المفتاح العام بدلاً من كلمات المرور. ويتم تمكين ذلك من خلال أدوات المصادقة مثل مفاتيح الأمان أو القياسات الحيوية. تم إنشاء المعيار بواسطة تحالف FIDO واتحاد شبكة الويب العالمية (W3C).

FIDO2 عبارة عن مجموعة من المواصفات الفنية التي تتيح طرق المصادقة بدون كلمة مرور باستخدام بيانات الاعتماد الآمنة مثل مفاتيح الأمان أو القياسات الحيوية أو مصادقة النظام الأساسي. إنه امتداد لمعيار FIDO (الهوية السريعة عبر الإنترنت).

فيما يلي بعض المزايا الرئيسية لـ WebAuthn وFIDO2 مقارنة بمصادقة كلمة المرور التقليدية:

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

• تكاليف أقل - تنفق المؤسسات مبلغًا أقل في التعامل مع عمليات إعادة تعيين كلمة المرور ومكالمات مكتب المساعدة والمشكلات الأخرى المتعلقة بكلمة المرور والتي تضيف أعباء تقنية المعلومات.

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

• محايد للنظام الأساسي/الجهاز - يعمل WebAuthn عبر أجهزة سطح المكتب والأجهزة المحمولة. ولا يحبس المستخدمين في نظام أساسي أو جهاز معين.

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

الخلاصة

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

تهدف البروتوكولات الأحدث إلى تحسين OAuth 2.0 بطرق مختلفة:

• OpenID Connect يعتمد على OAuth 2.0 لإضافة خدمات الهوية، وتوفير التحقق من الهوية إلى جانب المصادقة والترخيص. ويساعد هذا في معالجة بعض الثغرات الأمنية في OAuth 2.0.

• ** يوفر TLS المتبادل ** مصادقة قائمة على الشهادة لكل من العميل والخادم، مما يمنع هجمات الوسيط. على الرغم من أن تنفيذ TLS المتبادل أكثر تعقيدًا، إلا أنه يعمل على تحسين السلامة وحماية الخصوصية مقارنةً بـ OAuth 2.0 وحده.

• WebAuthn/FIDO2 يستخدم تشفير المفتاح العام بدلاً من كلمات المرور للمصادقة، مما يوفر تسجيل دخول مقاومًا للتصيد الاحتيالي ومقاومًا للتلاعب. يمكن أن يحل هذا البروتوكول محل OAuth بالكامل لتسجيل الدخول في كثير من الحالات.

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

بالنسبة للتطبيقات الحساسة للغاية مثل الرعاية الصحية والخدمات المالية وإدارة الهوية، يجب مراعاة TLS المتبادل والبروتوكولات مثل WebAuthn لتوفير دفاع متعمق. حتى بالنسبة لتطبيقات المستهلك، يساعد تعزيز OAuth باستخدام OpenID Connect على ضمان سلامة أفضل لهوية المستخدم والمصادقة.تابع أخبار APIRobots للحصول على مزيد من الرؤى والتحديثات حول هذا المجال المثير. لا تفوت الفرص التي يمكن أن توفرها واجهات برمجة التطبيقات لشركتك. اتصل بنا اليوم على API Robots an وكالة تطوير واجهات برمجة التطبيقات ودعنا نطلق الإمكانات الكاملة لواجهات برمجة التطبيقات معًا.