تصور کنید توسعه‌دهنده‌ای هستید که می‌خواهد یک ابزار اتوماسیون برای مدیریت زیرساخت‌هایش بسازد، اما برای دسترسی به APIها باید هر بار با یک فرآیند دستی و محدود درگیر شود. کلاودفلر در ۳ ژوئن ۲۰۲۶ این سد را شکست و دسترسی به OAuth خودمدیریت را برای تمام مشتریانش آزاد کرد. این تغییر، جایگزین محدودیت‌های قدیمی شد که OAuth را تنها به دایره‌ای کوچک از شرکا محدود می‌کرد.
طبق اعلام این شرکت، نیاز فزاینده به پلتفرم‌های توسعه‌دهنده داخلی و ابزارهای عامل‌محور (Agentic) — که مانند دستیارهای هوشمندی هستند که می‌توانند به‌جای شما کارهای اداری یا فنی را انجام دهند — محرک اصلی این تصمیم بود. این رویکرد با چشم‌انداز گسترده‌تر پروتکل‌های ارتباطی همسو است، مشابه آنچه در راهکار MCP برای تسهیل دسترسی کاربران به ابزارهای سازمانی دیده می‌شود. هدف، گذار از یک فرآیند محدود و دستی برای پذیرش OAuth شخص ثالث به سیستمی است که در آن هر مشتری بتواند اپلیکیشن‌های خود را برای مدیریت دسترسی‌های تفویضی به API ایجاد کند.
کلاودفلر در حال حاضر خدماتی ارائه می‌دهد که تقریباً ۲۰٪ وب بر بستر آن‌ها می‌چرخد. اما این شرکت می‌داند توسعه‌دهندگان در پلتفرم آن‌ها از ابزارهای متنوع و بی‌شماری از شرکت‌های دیگر نیز استفاده می‌کنند. کلاودفلر با ارائه یک API غنی، امکان ساخت اتوماسیون‌ها، خطوط لوله CI/CD و ادغام‌هایی را فراهم می‌کند که قطعات مختلف زیرساخت را به هم متصل می‌سازند.
سال‌ها بود که توسعه‌دهندگان برای ساخت ادغام‌ها در کلاودفلر به توکن‌های API تکیه می‌کردند. اگرچه این توکن‌ها کاربردی بودند، اما مدیریت آن‌ها دشوار است و برای جریان‌های «دسترسی تفویضی» که در اپلیکیشن‌های مدرن SaaS مورد نیاز است، مناسب نیستند. استفاده از سیستمی مثل OAuth به کاربران اجازه می‌دهد دسترسی‌های محدودشده‌ای (Scoped Access) را تعریف کنند؛ به این معنا که آن‌ها می‌توانند به یک اپلیکیشن اجازه دهند فقط یک تنظیم خاص را مدیریت کند، بدون اینکه کنترل کامل حساب کاربری را در اختیار بگیرد.
زمینه و بهبودهای امنیتی
کلاودفلر با OAuth بیگانه نبود؛ این سیستم پیش‌تر توسط کاربرانی که از Wrangler استفاده می‌کردند یا در ادغام‌هایی با شرکایی مانند PlanetScale به کار گرفته شده بود. اما گسترش این قابلیت به تمام مشتریان، نیازمند یک مدل امنیتی پخته‌تر بود تا بتوان بر vektورهای بالقوه سوءاستفاده غلبه کرد و ریسک‌ها را کاهش داد.
برای مقیاس‌پذیری امن این اکوسیستم، کلاودفلر به‌روزرسانی‌های خاصی را در تجربه کاربری (UX) اجرا کرد:
- بهبود رضایت (Consent): تجربه به‌روزرسانی شده‌ی رضایت، اکنون به‌طور صریح مشخص می‌کند که کدام اپلیکیشن درخواست دسترسی داده است و دقیقاً چه مجوزهایی اعطا خواهد شد.
- ابزارهای ابطال (Revocation): ویژگی جدیدی برای ابطال دسترسی به داشبورد اضافه شد. این ابزار به توسعه‌دهندگان اجازه می‌دهد به‌راحتی کنترل کنند که کدام اپلیکیشن‌ها به داده‌های آن‌ها دسترسی دارند.
- شفافیت مالکیت: مالکیت اپلیکیشن‌ها اکنون بیشتر قابل مشاهده است تا به‌طور مشخص از حملات فیشینگ OAuth جلوگیری شود.
این تغییرات تضمین می‌کند که با افزایش تقاضا برای دسترسی‌های تفویضی توسط ابزارهای عامل‌محور، کاربران رضایت شفاف‌تری داشته باشند و ابطال مجوزها برایشان آسان‌تر شود. انتقال به OAuth خودمدیریت به این معناست که توسعه‌دهندگان می‌توانند جریان‌های استانداردی را ارائه دهند که در آن مشتریان مستقیماً دسترسی محدودشده را اعطا می‌کنند و این امر ساخت ادغام‌های SaaS و پلتفرم‌های داخلی توسعه‌دهندگان را تسهیل می‌کند.
ارتقای موتور هیدرا (Hydra)
در قلب این سامانه، هیدرا (Hydra) قرار دارد؛ یک موتور OAuth متن‌باز. کلاودفلر سال‌ها پیش هیدرا را برای تامین قدرت OAuth در لایه‌های زیرین مستقر کرد. اگرچه این موتور در دوره استفاده محدود به‌خوبی پاسخ داد، اما رشد پلتفرم توسعه‌دهندگان و ظهور جریان‌های کاری عامل‌محور، نیاز به یک ارتقای اساسی برای باز کردن قابلیت‌های جدید و بهبود عملکرد ایجاد کرد.
کلاودفلر تصمیم گرفت به‌جای یک پرش ریسکی و مستقیم، دو ارتقای متوالی را اجرا کند: ابتدا به نسخه ۱.X و سپس به ۲.X. این استراتژی به تیم اجازه داد تا تغییرات رفتاری و عملکردی را در هر مرحله ارزیابی کند. این روند تضمین کرد که فرآیند ارتقا با کمترین اختلال برای کاربر پیش برود و پایداری داده‌ها و امنیت حفظ شود.
ارتقای ۱.X مشکلات بحرانی در پایگاه‌داده را آشکار کرد. SDK هیدرا عملیات SELECT * را اجرا می‌کرد که در طول مهاجرت طرح‌واره (Schema)، باعث شکست در بازسازی داده‌ها (Deserialization) می‌شد. مهندسان کلاودفلر برای حل این مشکل، نسخه سفارشی از هیدرا ساختند که به‌جای فراخوانی تمام ستون‌ها، ستون‌های مشخصی را انتخاب می‌کرد.
آن‌ها همچنین دریافتند که ایجاد ایندکس‌های استاندارد، قفل‌های انحصاری (Exclusive Locks) روی جداول حیاتی ایجاد می‌کند و مانع از انجام عملیات‌های مهم OAuth توسط کاربران فعال می‌شود. علاوه بر این، مهاجرت نیازمند افزودن ستون‌هایی به جداول حیاتی و انتقال ستون‌های دیگر به جداول جدید بود. برای آنلاین نگه داشتن API در تمام مدت، تیم مهاجرت‌های SQL را بازنویسی کرد تا از دستور CREATE INDEX CONCURRENTLY استفاده کند.
حل معمای بلو-گرین (Blue-Green)
عبور به هیدرا ۲.X چالش بزرگ‌تری بود: تغییرات طرح‌واره برای یک ارتقای درجا (In-place) بسیار گسترده بود. کلاودفلر استراتژی بلو-گرین را انتخاب کرد؛ روشی که در آن نسخه جدید سیستم در کنار نسخه قدیمی اجرا می‌شود تا پیش از جایگزینی نهایی، تست شود. انتظار می‌رفت این فرآیند چندین ساعت طول بکشد.
در جابجایی‌های استاندارد بلو-گرین، اغلب برای جلوگیری از گم شدن داده‌ها، قابلیت نوشتن (Write) غیرفعال می‌شود. اما کلاودفلر تشخیص داد که غیرفعال کردن نوشتن، مانع از هرگونه مجوزدهی جدید می‌شود و ابطال دسترسی کاربران به اپلیکیشن‌ها را در پنجره ارتقا غیرممکن می‌کند. برای حل این难题، دو مکانیزم خاص پیاده کردند:
- تمدید توکن: آن‌ها از یک اهرم عملیاتی برای افزایش زمان انقضای توکن‌ها به چندین ساعت استفاده کردند. این کار تضمین کرد اپلیکیشن‌هایی که پیش از ارتقا توکن جدید گرفته‌اند، بدون نیاز به بازخوانی (Refresh) در طول انتقال، به کار خود ادامه دهند.
- صف‌های ابطال: با استفاده از Cloudflare Queues، سیستمی ساختند تا تک‌تک رویدادهای «ابطال دسترسی» را شکار کند. پس از هر رویداد ابطال، رکوردی حاوی اطلاعات آن ابطال در صف نوشته می‌شد.
زمانی که دیتابیس «سبز» (جدید) فعال شد، آن‌ها صف را تخلیه و تمام رویدادها را بازپخش (Replay) کردند. این اقدام حیاتی بود، زیرا در غیر این صورت، اپلیکیشن‌هایی که دسترسی‌شان قطع شده بود، ممکن بود در بازه زمانی جابجایی، به‌طور تصادفی دوباره دسترسی پیدا کنند.
اجرای نهایی انتقال به ۲.X
برای به حداقل رساندن اثر از دست رفتن نوشتن توکن‌ها، کلاودفلر پنجره ارتقا را زمانی انتخاب کرد که حجم درخواست‌های هیدرا در ثانیه در کمترین سطح بود. مهاجرت‌های محیط عملیاتی حدود سه ساعت روی یک کپی از دیتابیس تولید اجرا شد.
فراتر از جابجایی دیتابیس، تیم چندین بخش متحرک دیگر را مدیریت کرد:
- پاک‌سازی هدفمند داده‌ها: داده‌های موجود با برخی محدودیت‌های جدید که در نسخه‌های جدید معرفی شده بودند، تضاد داشتند و نیاز به پاک‌سازی داشتند تا مهاجرت‌ها با موفقیت انجام شوند.
- انتقال هم‌زمان: سرویس هیدرا و دو سیستم داخلی حیاتی دیگر به‌طور هم‌زمان منتقل شدند تا از بروز خطاهای ناهماهنگی جلوگیری شود.
- هم‌راستایی SDK: پیکربندی‌های سیستم جدید منتشر شد تا اطمینان حاصل شود که تمام بخش‌ها از نسخه جدید SDK استفاده می‌کنند.
غلبه بر باگ‌های پس از انتقال
علی‌رغم برنامه‌ریزی‌ها، ارتقای ۱.X باعث موجی از خطاهای توکن بازخوانی شد. نسخه جدید هیدرا از روش سخت‌گیرانه‌تری برای ابطال استفاده می‌کرد؛ اگر یک توکن بازخوانی مجدداً استفاده می‌شد، هیدرا کل زنجیره توکن دسترسی و بازخوانی را باطل می‌کرد. این موضوع کلاینت‌های با حجم بالای درخواست مثل Wrangler و کلاینت‌های MCP را مختل کرد، جایی که یک توکن تکراری باعث پاک شدن کل جلسه (Session) می‌شد.
کلاودفلر با افزودند یک لایه «تجمعی توکن بازخوانی» (Refresh Token Coalescing) در Workers خود، این مشکل را کاهش داد. این لایه درخواست‌های بازخوانی را برای مدت کوتاهی کش می‌کرد تا بازبینی‌های تکراری به هیدرا نرسند و باعث پاک شدن جلسه نشوند. این مشکل در هیدرا ۲.X به‌طور بومی از طریق یک «دوره اهدای توکن» (Grace Period) قابل تنظیم حل شده است که اجازه می‌دهد بازخوانی‌ها برای مدت مشخصی بدون ابطال زنجیره تکرار شوند.
در جریان انتقال به ۲.X، یک عملیات پاک‌سازی داده در سرویس مجوزدهی (که به API جلسه رضایت هیدرا متکی بود) بیش از حد تهاجمی عمل کرد و داده‌های معتبر سیاست‌های OAuth را پاک کرد. این اتفاق به‌دلیل یک خطای مهاجرتی رخ داد که وضعیت برخی جلسات معتبر را خراب کرد و آن‌ها را «نامعتبر» علامت زد. این تضاد بین هیدرا و سرویس مجوزدهی منجر به افزایش خطاهای ۴۰۳ (Forbidden) شد. تیم با بازگردانی داده‌ها و حذف وابستگی سرویس مجوزدهی به داده‌های سیاست استاتیک، این مشکل را حل کرد.
کمی‌سازی دستاوردها
به گزارش رسمی کلاودفلر، این مهاجرت منجر به بهره‌وری چشمگیری شد. مقیاس عملیات دیتابیس عظیم بود:
- ردیف‌های به‌روزرسانی شده: ۱۳۲.۵ میلیون
- ردیف‌های درج شده: ۱۱۴.۷ میلیون
- بایت‌های موقت مصرفی: ۱۳۶.۹۷ گیگابایت
- تأیید تراکنش‌ها (Commits): ۲۲.۲ هزار
تفاوت عملکرد پس از ارتقای ۲.X خیره‌کننده بود و بهبودهای مداومی را در تمام بخش‌ها نشان داد:
- تأخیر P95 در API: از ۱۸۵ میلی‌ثانیه به ۱۰۱ میلی‌ثانیه رسید (بهبود ۴۵٪).
- استفاده از CPU: از ۱.۰۷ هسته به ۰.۶۷ هسته کاهش یافت (۳۷٪ کاهش).
- حافظه (RSS): از ۸۸۸ مگابایت به ۷۶۳ مگابایت رسید (۱۴٪ کاهش).
- تخصیص Heap در Go: از ۴۴۹ مگابایت به ۲۷۱ مگابایت افت کرد (۴۰٪ کاهش).
- روال‌های Go (Goroutines): از ۴۰۱۵ به ۳۰۷۶ کاهش یافت (۲۳٪ کاهش).
این پایداری زیرساختی، پیش‌نیاز لانچ ۳ ژوئن بود. کلاودفلر با بهینه کردن موتور زیربنایی، اکنون می‌تواند اکوسیستم عظیمی از عامل‌های شخص ثالث و ادغام‌های SaaS را بدون قربانی کردن قابلیت اطمینان پشتیبانی کند. همچنین ابزارهای تکمیلی مانند Pagecast امکان تبدیل سریع خروجی‌های این عامل‌های هوش مصنوعی به صفحات وب را فراهم می‌کنند تا زنجیره تولید تا انتشار تکمیل شود.
این انتقال نشان‌دهنده چرخش از «اعتماد گزینشی» (Curated Trust) به «اعتماد مقیاس‌پذیر» است. کلاودفلر با انتقال بار مدیریت کلاینت به کاربران و توسعه‌دهندگان از طریق OAuth خودمدیریت، خود را به‌طور مؤثر به عنوان قطبی برای وب عامل‌محور معرفی می‌کند. قابلیت یک عامل هوش مصنوعی برای اقدام امن و موقت به‌نیابت از کاربر، اکنون به یک ویژگی استاندارد (Primitive) در این پلتفرم تبدیل شده است.
توسعه‌دهندگان اکنون می‌توانند اولین اپلیکیشن‌های OAuth خود را مستقیماً از طریق داشبورد کلاودفلر یا مستندات رسمی بسازند.
گام بعدی شما
- اگر اپلیکیشن SaaS توسعه می‌دهید، از داشبورد کلاودفلر برای پیاده‌سازی OAuth و جایگزینی توکن‌های استاتیک استفاده کنید.
- مستندات جدید Cloudflare OAuth را برای تنظیم دقیق دامنه دسترسی‌ها (Scopes) مطالعه کنید.
- در صورت استفاده از Wrangler، بررسی کنید که آیا آخرین نسخه SDK را برای جلوگیری از خطاهای توکن نصب کرده‌اید.
اما داستان بهینه‌سازی‌های زیرساختی کلاودفلر را می‌توان با بررسی معماری Workers آن‌ها تکمیل کرد — به تحلیل ما درباره لبه‌های پردازشی مراجعه کنید.
گفتگو