تدفقات OAuth 2.0 وأنواع الرموز

يحدد OAuth 2.0 أربعة أدوار. مالك المورد هو المستخدم الذي يملك البيانات، مثل ملفاته على Google Drive. العميل هو التطبيق الذي يطلب الوصول. خادم التفويض هو الذي يصدر رموز الوصول، مثل خادم OAuth الخاص بـ Google. أما خادم المورد فيستضيف البيانات المحمية، مثل Google Drive API. يساعد فهم هذه الأدوار على توضيح الغرض من كل تدفق.

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

صُمم التدفق الضمني لتطبيقات JavaScript التي تعمل في المتصفح فقط ولا تستطيع تخزين أسرار العميل بأمان. كانت الرموز تُعاد مباشرةً في جزء عنوان URL، متجاوزةً القناة الخلفية. أُهمل التدفق الضمني في OAuth 2.1 لأن PKCE (RFC 7636) يتيح للعملاء العامين استخدام تدفق رمز التفويض بأمان من دون سر للعميل.

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

يُستخدم تدفق بيانات اعتماد العميل للمصادقة من آلة إلى آلة (M2M)، حيث لا يوجد مستخدم مشارك. يصادق العميل مباشرةً لدى خادم التفويض باستخدام معرّف العميل والسر الخاص به، ويحصل على رمز وصول لاستخدامه الخاص. ومن حالات الاستخدام الشائعة: المهام التي تعمل في الخلفية، والاتصال بين الخدمات المصغرة، وبوابات API التي تصل إلى خدمات الواجهة الخلفية.

يتيح تدفق تفويض الجهاز (RFC 8628) استخدام OAuth على الأجهزة ذات قدرات الإدخال المحدودة، مثل أجهزة التلفاز الذكية ووحدات تحكم الألعاب والطابعات وأجهزة IoT. يعرض الجهاز رمزًا قصيرًا وعنوان URL. يزور المستخدم عنوان URL من هاتف أو كمبيوتر لإجراء التفويض. ويستعلم الجهاز دوريًا من خادم التفويض إلى أن يكمل المستخدم التفويض.

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

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

يحدد RFC 7662 نقطة نهاية فحص الرموز، التي تتيح لخوادم الموارد الاستعلام من خادم التفويض عن الحالة الحالية لرمز وصول غير شفاف (active/inactive)، ونطاقه، وموضوعه، وانتهاء صلاحيته. يتيح الفحص إبطال الرموز في الوقت الفعلي؛ فعند إبطال رمز لدى خادم التفويض، تعيد استدعاءات الفحص فورًا القيمة active: false.

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

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

يُعد تدفق رمز التفويض مناسبًا للتطبيقات من جهة الخادم. التدفق الضمني مهجور، لذا استخدم PKCE بدلًا منه. وتدفق ROPC مهجور لأنه يلغي الغرض من OAuth. تُستخدم بيانات اعتماد العميل للاتصال من آلة إلى آلة. ويتولى تفويض الجهاز التعامل مع الأجهزة محدودة الإدخال. تكون رموز الوصول غير شفافة أو من نوع JWT. وينبغي تدوير رموز التحديث. ويكمل فحص الرموز (RFC 7662) وإبطالها (RFC 7009) منظومة إدارة الرموز.