التدفق الضمني مقابل تدفق رمز التفويض: لماذا التدفق الضمني لم يعد مستخدمًا؟

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

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

ما هو OAuth 2.0؟#

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

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

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

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

ما هو التدفق الضمني؟#

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

كيف يعمل التدفق الضمني؟#

1. ينقر المستخدم على زر أو رابط في التطبيق العميل لبدء عملية المصادقة.
2. يُعيد التطبيق العميل توجيه المستخدم إلى خادم التفويض للمصادقة، متضمناً نطاق الوصول المطلوب.
3. يدفع خادم التفويض المستخدمين لتسجيل الدخول ومنح الإذن للتطبيق العميل.
4. عند نجاح المصادقة والتفويض، يُعيد خادم التفويض توجيه متصفح المستخدم إلى URI المحول المحدد للعميل، مع تضمين رمز الوصول في شظية عنوان URL.
5. يستخرج التطبيق العميل رمز الوصول من شظية عنوان URL ويستخدمه للوصول إلى موارد المستخدم على خادم الموارد.

المخاطر الأمنية للتدفق الضمني#

للتدفق الضمني عدة ثغرات أمنية:

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

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

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

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

كيف يعمل تدفق رمز التفويض للعملاء الخاصة مع مكون خادم الآمنة؟#

1. ينقر المستخدم على زر أو رابط في التطبيق العميل لبدء عملية المصادقة.
2. يُعيد التطبيق العميل توجيه المستخدم إلى خادم التفويض للمصادقة مع نطاق الوصول المطلوب.
3. يدفع خادم التفويض المستخدمين لتسجيل الدخول ومنح الإذن للتطبيق العميل.
4. عند نجاح المصادقة والتفويض، يُعيد خادم التفويض رمز تفويض إلى العميل.
5. يُبادل التطبيق العميل بشكل آمن رمز التفويض برمز وصول عن طريق إجراء طلب خدمية إلى نقطة النهاية الرمزية باستخدام بيانات اعتماد العميل.
6. يتحقق خادم التفويض من صحة رمز التفويض وبيانات اعتماد العميل ويعيد رمز وصول إلى العميل.
7. يستخدم التطبيق العميل رمز الوصول للوصول إلى موارد المستخدم على خادم الموارد.

كيف يعمل تدفق رمز التفويض للعملاء العامة مع PKCE؟#

1. ينقر المستخدم على زر أو رابط في التطبيق العميل لبدء عملية المصادقة.
2. يُولد التطبيق العميل مدقق رمز وتحدي رمز.
3. يُعيد التطبيق العميل توجيه المستخدم إلى خادم التفويض للمصادقة مع تحدي الرمز.
4. يُخزن خادم التفويض تحدي الرمز للمصادقة اللاحقة.
5. يُصدق المستخدم ويمنح الوصول للتطبيق العميل.
6. يُعيد خادم التفويض رمز تفويض للعميل.
7. يُبادل التطبيق العميل رمز التفويض برمز وصول عن طريق إجراء طلب خدمية إلى نقطة النهاية الرمزية باستخدام مدقق الرمز.
8. يتحقق خادم التفويض من صحة رمز التفويض ومدقق الرمز مقارنةً بتحدي الرمز المخزن.
9. يُعيد خادم التفويض رمز الوصول إلى العميل.
10. يستخدم التطبيق العميل رمز الوصول للوصول إلى موارد المستخدم على خادم الموارد.

تعلم المزيد عن PKCE التدفق.

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

هل يمكن لتدفق رمز التفويض التخلص من المشاكل الأمنية للتدفق الضمني؟#

الإجابة هي نعم:

يُقدم تدفق رمز التفويض خطوة إضافية لمبادلة رمز التفويض برمز وصول، مما يقلل بشكل كبير من خطر كشف الرمز.

• بالنسبة للعملاء الخاصة مع مكون خادم آمن، يمكن للتطبيق العميل تبادل رمز التفويض بشكل آمن برمز وصول باستخدام بيانات اعتماد العميل.
• بالنسبة للعملاء العامة بدون مكون خادم آمن، يمكن استخدام امتداد PKCE لحماية عملية مبادلة رمز التفويض.

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