كيف تمنع انتهاء صلاحية OAuth من إيقاف جميع وكلاء الذكاء الاصطناعي؟

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

كيف يتحول عطل صغير إلى توقف جماعي؟

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

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

لماذا لا يكفي التجديد التلقائي؟

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

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

حلقة من أربع مراحل للتحكم في التفويض

1. المراقبة: سجّل آخر طلب ناجح، ووقت آخر refresh، ونطاقات الصلاحية المطلوبة، وعدد أخطاء المصادقة لكل اتصال. يجب أن تظهر صحة الاتصال منفصلة عن صحة الوكيل.
2. التجديد: جدّد قبل الوصول إلى حد انتهاء الصلاحية المتوقع، ثم تحقق بطلب API حقيقي منخفض المخاطر. الحصول على رمز جديد لا يثبت أن API يعمل.
3. التنبيه: اذكر أي اتصال فشل، وعدد الوكلاء والمهام المتأثرة، والخطوة التالية. عبارة “Something went wrong” ليست تنبيهاً تشغيلياً.
4. التعافي: اجعل إعادة التفويض صريحة ومحدودة وقابلة للتدقيق. يعيد الإنسان الوصول، ويختبر النظام الاتصال، ثم تُفتح المهام التابعة تدريجياً بدلاً من إطلاقها كلها معاً.

ثلاث بوابات تمنع انتشار العطل

أولاً، شغّل health check منخفض التكلفة قبل كل مهمة تابعة. ثانياً، أضف circuit breaker: عندما تتجاوز أخطاء المصادقة المشتركة حداً معيناً، أوقف كل الوكلاء التابعين حتى لا ينمو الطابور بلا هدف. ثالثاً، اشترط التحقق من التعافي: بعد إعادة التفويض، نفّذ مثالاً حقيقياً للقراءة فقط ولا تفتح الطابور إلا عند نجاحه.

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

قائمة تنفيذية

لكل بيانات اعتماد، سجّل مالكاً وخدمات تابعة وطريقة اختبار وحد تنبيه ومسار تعافٍ. لا تضع الأسرار داخل prompts أو السجلات. سجّل أوقات refresh ونتائج health check، ولكن لا تسجّل قيمة token نفسها. نفّذ تدريباً دورياً على التعافي لإثبات أن الإجراء المكتوب يعمل فعلاً.

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

إجابات سريعة

هل يبقى refresh token صالحاً دائماً حتى تاريخ معروف؟

لا. يمكن لمقدم الخدمة إبطاله بسبب إلغاء الوصول أو سياسة أمنية أو انتهاء الصلاحية. يجب أن يعامل النظام ذلك كحالة طبيعية قابلة للتعافي.

متى يجب تنبيه الإنسان؟

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

الخلاصة

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

المصدر الرسمي

• سياسات OAuth 2.0 من Google