OAuth کلادفلر به رضایت مبتنی بر وظیفه مجهز شد؛ scopeهای اختیاری رسیدند

کلادفلر در ۲۰ اوت ۲۰۲۶ قابلیت «scope اختیاری» را به سرویس OAuth خود افزود و مدل رضایت کاربر را از حالت «همه یا هیچ» به رضایت مبتنی بر وظیفه (task-based consent) تغییر داد؛ تغییری که به‌ویژه برای اکوسیستم رو به رشد agentها و سرورهای MCP اهمیت دارد.

#چه اتفاقی افتاد؟

تا پیش از این تغییر، صفحهٔ رضایت OAuth کلادفلر تجربه‌ای همه‌یا‌هیچ بود: اگر اپلیکیشنی مجموعه‌ای از scopeها را درخواست می‌کرد، کاربر یا باید همه را تأیید می‌کرد یا کلاً فرایند را لغو. از ژوئن گذشته، توسعه‌دهندگان هزاران اپلیکیشن OAuth ثالث روی کلادفلر ساخته‌اند و بیش از یک میلیون authorization ثبت شده است؛ حجمی که نشان می‌دهد ناکامی این مدل دیگر قابل‌چشم‌پوشی نبود.

با قابلیت جدید، مالک OAuth client می‌تواند هنگام پیکربندی، scopeهای خاصی را به‌عنوان «اختیاری» (optional) علامت بزند و کاربر در لحظهٔ احراز هویت، آن‌ها را به‌دلخواه حذف کند و دسترسی باریک‌تری اعطا نماید.

#جزئیات فنی

مکانیزم جدید چند قاعدهٔ دقیق دارد که درک آن‌ها برای توسعه‌دهندگان حیاتی است:

• ارزیابی در سطح جریان احراز هویت: وضعیت required/optional هر scope فقط در برابر scopeهای درخواست‌شده در همان authorization flow سنجیده می‌شود، نه کل scopeهای پیکربندی‌شدهٔ client. اگر client چهار scope داشته باشد ولی در یک جریان فقط دو تای آن‌ها را درخواست کند، فقط همان دو مورد ارزیابی و نمایش داده می‌شوند.
• پیکربندی از طریق API: هنگام ساخت client با POST /client/v4/accounts/$ACCOUNT_ID/oauth_clients، آرایهٔ optional_scopes در کنار scopes ارسال می‌شود.
• رفتار پیش‌فرض بدون تغییر: اگر client به optional scopeها opt-in نکند، جریان رضایت دقیقاً مثل قبل عمل می‌کند.
• نکتهٔ مهم برای کد شما: توکن صادرشده فقط شامل scopeهایی است که کاربر واقعاً تأیید کرده. توسعه‌دهنده باید پس از تبادل authorization code، مجموعهٔ scope اعطاشده را بررسی کند و دیگر نمی‌تواند فرض کند «همهٔ چیزی که خواسته‌ام، گرفته‌ام».

این طراحی دقیقاً همان انعطافی است که مشخصات OAuth از ابتدا اجازه می‌داد — سرور مجوز می‌تواند مجموعهٔ باریک‌تری از scope درخواستی را اعطا کند — اما کلادفلر آن را به تجربهٔ کاربری واقعی تبدیل کرده است.

توکن صادرشده فقط شامل scopeهایی است که کاربر تأیید کرده است — Cloudflare Blog

#چرا مهم است؟

این تغییر در ظاهر یک بهبود UX است، اما در عمق یک بهبود امنیتی است. اصل حداقل دسترسی (least privilege) سال‌هاست که شعار داده می‌شود؛ اما وقتی رابط کاربری فقط دو دکمهٔ «قبول همه / رد همه» دارد، آن اصل در عمل شکسته می‌شود. نمونهٔ برجسته، سرورهای MCP و agentهای هوش مصنوعی هستند: یک MCP server ممکن است «در تئوری» به طیف وسیعی از مجوزها نیاز داشته باشد، اما کاربر نباید مجبور شود همهٔ آن طیف را به یک agent اعطا کند. حالا می‌تواند scopeهای حساس — مثل workers-kv-storage.write یا zone.read — را بردارد و فقط حداقل لازم برای «وظیفهٔ همین لحظه» را بدهد.

پیامد عملی برای توسعه‌دهندگان دوگانه است: نخست، صفحهٔ رضایت اپلیکیشن‌های خود را با scopeهای اختیاری بازطراحی کنید؛ دوم — و مهم‌تر — کد خود را برای «گرانت ناقص» (partial grant) آماده کنید. اپلیکیشنی که با مجموعهٔ باریک‌تر مجوز هم به‌خوبی کار کند، اپلیکیشنی است که کاربران با خیال راحت authorize می‌کنند.

#اعداد و ارقام

• ۲۰ اوت ۲۰۲۶: عرضهٔ قابلیت optional scopes در Cloudflare OAuth
• هزاران اپلیکیشن OAuth ثالث ساخته‌شده از ژوئن ۲۰۲۶
• بیش از ۱ میلیون authorization ثبت‌شده تاکنون

#پیشینهٔ OAuth در کلادفلر

کلادفلر در ژوئن ۲۰۲۶ با عرضهٔ Self-Managed OAuth برای همهٔ توسعه‌دهندگان، دروازهٔ اکوسیستم اپلیکیشن‌های ثالث را گشود و موتور مرکزی OAuth خود را با مهاجرت بدون توقف بازسازی کرد. قابلیت scope اختیاری، حلقهٔ دوم این زنجیره است: ابتدا ساخت اپلیکیشن آسان شد، حالا اعطای دسترسی امن‌تر می‌شود. کلادفلر همچنین اعلام کرده در هفته‌های آینده پوشش نقش‌ها و scopeها را تقریباً به تمام محصولاتش گسترش می‌دهد؛ یعنی توسعه‌دهندگانی که امروز مدل partial grant را پیاده کنند، فردا روی موج گسترش scopeها سوار خواهند شد.

#منابع

• Cloudflare Blog — From all-or-nothing to task-based OAuth consent
• Cloudflare Developers