تعلن Cloudflare عن الرفع الكامل للقيود على OAuth، ولم يعد مطورو AI Agent بحاجة إلى مراجعة يدوية.

أعلنت Cloudflare عن فتح خدمة OAuth المدارة ذاتيًا لجميع المطورين، دون الحاجة إلى مراجعة يدوية للتسجيل. الدافع وراء ذلك هو النمو الهائل في الطلب على تفويض الصلاحيات من أدوات الوكيل الذكي (AI Agent)، بالإضافة إلى استبدال محرك أساسي يتضمن ترحيل 130 مليون صف من البيانات.
(خلاصة سابقة: بيانات Cloudflare: 34% من حركة المرور على الإنترنت ليست بشرية، وروبوتات الذكاء الاصطناعي تنمو بمعدل 8 أضعاف)
(خلفية إضافية: UBS و TD Cowen يرفعان السعر المستهدف لـ Arm إلى 475 دولارًا في نفس اليوم، بسبب الإيرادات المستقبلية من المعالجات المطورة ذاتيًا)

جدول المحتويات

Toggle

• لماذا يتم الفتح الآن؟
• استبدال محرك أساسي يشمل 130 مليون صف من البيانات
• مشكلة إلغاء سلسلة refresh token في عملاء MCP

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

لماذا يتم الفتح الآن؟

Cloudflare ليست جديدة على OAuth. فمنذ أن استخدم المطورون أداة Wrangler CLI أو الاتصال بخدمات الشركاء مثل PlanetScale، كان OAuth يعمل بصمت في الخلفية. لكن هذه التكاملات كانت نمطًا مغلقًا يتطلب "تسجيلًا يدويًا"، ولم يتمكن مطورو الطرف الثالث من إنشاء سير عمل OAuth قياسي بأنفسهم.

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

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

استبدال محرك أساسي يشمل 130 مليون صف من البيانات

ولكن لفتح OAuth على نطاق واسع، كان على Cloudflare أولاً حل مشكلة هندسية: محرك التفويض الأساسي Hydra لم يعد قادرًا على تحمل العبء.

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

تم تقسيم خطة الترقية إلى مرحلتين. المرحلة الأولى كانت ترقية Hydra إلى الإصدار 1.X، حيث اكتشف المهندسون أنه حتى مع الترحيل البسيط للإصدارات، كانت تغييرات هيكل قاعدة البيانات كبيرة. أعادوا كتابة نصوص SQL للترحيل، باستخدام تقنيات مثل CREATE INDEX CONCURRENTY التي لا تؤدي إلى قفل الكتابة، وقاموا بتخصيص إصدار بناء Hydra لاستبدال استعلامات SELECT * بالحقول المحددة صراحةً، مما قلل من نقل البيانات غير الضروري.

المرحلة الثانية كانت النشر الأزرق-الأخضر (blue-green deployment) لـ Hydra 2.X. النشر الأزرق-الأخضر يعني الحفاظ على نظامين قديم وجديد يعملان في وقت واحد، مع تحويل حركة المرور تدريجيًا بعد التأكد من استقرار النظام الجديد، مع إمكانية العودة الفورية في أي وقت، مما يخفض خطر انقطاع النظام إلى الصفر تقريبًا. ذكرت Cloudflare أنه في هذا الإطار، بنوا نظام قوائم انتظار يعتمد على Cloudflare Queues، مما يضمن مزامنة أحداث الإلغاء بشكل صحيح بين النظامين القديم والجديد.

كان حجم ترحيل قاعدة البيانات كبيرًا جدًا: تم تحديث 132.5 مليون صف، وإدراج 114.7 مليون صف جديد، وإنتاج 136.97 جيجابايت من البيانات المؤقتة.

مشكلة إلغاء سلسلة refresh token في عملاء MCP

بعد اكتمال التبديل الأزرق-الأخضر، ظهرت إشارة غير متوقعة في بيانات المراقبة: زيادة معدل أخطاء refresh token.

بعد التحقيق، تبين أن الإصدار الجديد من Hydra يطبق آلية إلغاء أكثر صرامة لإعادة استخدام refresh token: بمجرد اكتشاف إعادة استخدام نفس refresh token، يتم إلغاء مجموعة بيانات الوصول بالكامل (access token و refresh token) معًا.

تسبب هذا في مشاكل لعملاء Wrangler و MCP، لأن هذه الأدوات في حالات عدم استقرار الشبكة أو الطلبات المتزامنة قد تتسبب في إعادة استخدام refresh token.

الحل كان إضافة "آلية دمج refresh token" في Worker الذي يوجه حركة مرور OAuth: عندما يتم اكتشاف طلبات تحديث متعددة لنفس token في نفس الوقت، يقوم النظام بدمجها في طلب واحد، لتجنب تفعيل منطق الإلغاء المتسلسل. هذا الإصلاح أعاد تفاعل عملاء MCP إلى حالته الطبيعية.

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

بعد اكتمال الترقية، كانت تحسينات مؤشرات الأداء ملحوظة. انخفض تأخير API P95 من 185 مللي ثانية إلى 101 مللي ثانية، بنسبة 45%؛ وانخفض استخدام الذاكرة المقيمة من 888 ميجابايت إلى 763 ميجابايت، بنسبة 14%؛ وانخفض تخصيص ذاكرة Go heap من 449 ميجابايت إلى 271 ميجابايت، بنسبة 40%؛ وانخفض عدد Goroutines من 4,015 إلى 3,076، بنسبة 23%؛ وانخفض استخدام CPU من 1.07 نواة إلى 0.67 نواة، بنسبة 37%.

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