لماذا يجب عليك إهمال نوع التصريح اعتماد بيانات دخول مالك المورد (ROPC)

المقدمة#

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

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

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

نوع التصريح ROPC مقابل تدفق رمز التفويض#

كيف يعمل نوع التصريح ROPC#

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

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

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

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

المخاطر الأمنية لنوع التصريح ROPC#

1. تعرض بيانات اعتماد المستخدم#

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

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

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

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

تخيل إذا كان لديك تطبيقات متعددة تستخدم نوع التصريح ROPC، فإن الخطر المحتمل لكشف بيانات الاعتماد يتضاعف.

2. لا يدعم ROPC موافقة المستخدم#

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

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

3. لا يدعم ROPC المصادقة متعددة العوامل#

المصادقة متعددة العوامل (MFA) هي تنفيذ أمني يتطلب من المستخدم تقديم عاملين أو أكثر من عوامل التحقق للوصول إلى موارده. تضيف طبقة إضافية من الأمان إلى عملية المصادقة. نوع التصريح ROPC لا يدعم المصادقة متعددة العوامل. بدلاً من ذلك يقتصر عملية المصادقة على عامل واحد فقط، ويتم طلب الرمز فقط استنادًا إلى بيانات اعتماد المستخدم. من المستحيل تنفيذ آليات مصادقة تستند إلى التحدي مثل OTP عبر الرسائل النصية القصيرة، أو OTP عبر البريد الإلكتروني، أو WebAuthn مع نوع التصريح ROPC.

ROPC غير متوافق مع التطبيقات الحديثة#

تم تصميم نوع التصريح ROPC لدعم التطبيقات القديمة التي لا يمكنها دعم الأنظمة الحديثة لإدارة الوصول والهوية مثل الدخول الواحد Single Sign-On (SSO) أو الهويات الموحدة.

1. ROPC غير متوافق مع SSO#

الدخول الواحد (SSO) هو هيكل مصادقة حديث يسمح للمستخدمين بتسجيل الدخول مرة واحدة والوصول إلى تطبيقات متعددة بسهولة.

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

نوع التصريح ROPC لا يدعم SSO. يتطلب من تطبيق العميل جمع بيانات اعتماد المستخدم مباشرة، مما يكسر هيكل SSO. ليس متوافقًا مع الأنظمة الحديثة للدخول الواحد مثل OpenID Connect (OIDC) أو SAML.

2. ROPC غير متوافق مع الهويات الموحدة#

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

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

الخلاصة#

نوع التصريح اعتماد بيانات دخول مالك المورد (ROPC) هو تدفق قديم لـ OAuth 2.0 ينطوي على مخاطر أمنية كبيرة ويجب إهماله. يكشف بيانات اعتماد المستخدم لتطبيق العميل، ولا يدعم آليات الأمان الحديثة مثل MFA أو SSO. نوصي بشدة بتجنب استخدام نوع التصريح ROPC لتطبيقاتك. إذا كان لديك أنظمة مصادقة قديمة تعتمد على نوع التصريح ROPC، فكر في التحويل إلى تدفقات OAuth 2.0 أكثر أمانًا مثل تدفق رمز التفويض أو تدفق بيانات اعتماد العميل.

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