ما هو OAuth؟

• مصطلحات إدارة الهوية والوصول
• ما هو OAuth؟

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

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

OAuth مقابل OAuth 2.0: ما الفرق؟

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

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

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

كيف يعمل OAuth؟

إليك دليل خطوة بخطوة حول كيفية عمل OAuth 2.0 باستخدام تدفق منح رمز التفويض:

1. يبدأ المستخدم عملية التفويض: يرغب المستخدم في منح تطبيق جهة خارجية (ما يُسمى العميل) حق الوصول إلى موارده المستضافة على خادم. يبدأ هذا عادةً عندما ينقر المستخدم زرًا مثل "تسجيل الدخول عبر Google" أو "الربط مع GitHub" في تطبيق العميل.
2. يطلب العميل التفويض: يعيد العميل توجيه المستخدم إلى نقطة نهاية التفويض الخاصة بخادم التفويض. يتضمن الطلب معلمات مثل: client_id وredirect_uri وresponse_type=code وscope و state (لحماية CSRF). قد يُطلَب من المستخدم بعد ذلك المصادقة (إذا لم يكن قد سجل الدخول بالفعل) والموافقة على الوصول المطلوب أو رفضه.
3. تم منح التفويض: إذا وافق المستخدم على الطلب، يعيد خادم التفويض توجيه متصفح المستخدم إلى redirect_uri الخاص بالعميل. ويتم تضمين رمز تفويض في عنوان URL إلى جانب معلمة state ، والتي يجب على العميل التحقق منها لضمان عدم التلاعب بالطلب أو اعتراضه.
4. يطلب العميل رمز وصول: يرسل العميل طلبًا إلى نقطة نهاية الرمز المميز لاستبدال كود التفويض بالرمز المميز. يجب أن يتضمن هذا الطلب العناصر التالية: authorization_code وclient_id وclient_secret (إن وجد) وredirect_uri (ويجب أن يطابق الطلب الأصلي) وgrant_type=authorization_code.
5. يتلقى العميل رموز الوصول والتحديث: إذا تم التحقق من صحة الطلب، يصدر خادم التفويض رمز وصول لمصادقة طلبات واجهة برمجة التطبيقات (API) ورمز تحديث للحصول على رموز وصول جديدة عند انتهاء صلاحية الرمز الحالي. يحفظ العميل هذه الرموز بشكل آمن ويستخدم رمز الوصول في طلبات واجهة برمجة التطبيقات (API).
6. يستخدم العميل رمز التحديث: عندما تنتهي صلاحية رمز الوصول، يمكن للعميل طلب رمز جديد عن طريق إرسال طلب تحديث الرمز إلى نقطة نهاية الرمز. للحصول على رمز وصول جديد، يجب على العميل إرسال طلب جديد إلى نقطة نهاية الرمز بالمعايير التالية: client_id وclient_secret وrefresh_token وgrant_type=refresh_token.

مزايا OAuth

يوفر استخدام OAuth العديد من المزايا، مثل تقليل مخاطر سرقة بيانات الاعتماد وتحسين تجربة المستخدم وتمكين تسجيل الدخول الأحادي (SSO).

يقلل من خطر سرقة بيانات الاعتماد أو إساءة استخدامها

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

يحسِّن تجربة المستخدم

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

يُمكّن تسجيل الدخول الموحد

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

عيوب OAuth

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

يمكن أن تتعرض الرموز للاختراق إذا لم تُخزن بشكل آمن

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

يمكن أن تتعرض الرموز للاختراق إذا لم تُنقل مُؤَمَّنة

إذا تم إرسال الرموز عبر اتصال غير مؤمَّن، مثل استخدام HTTP بدلاً من HTTPS، فيمكن اعتراضها بواسطة هجوم Man-in-the-Middle (MITM). بمجرد اختراق الرمز، يمكن استخدامه للوصول غير المصرح به إلى موارد المستخدم.

عرضة لهجمات التصيد الاحتيالي

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