کلودفلر اکنون امکان تعیین اسکوپهای OAuth بهصورت اختیاری را فراهم کرده تا کاربران در صفحهٔ رضایت بتوانند مجوزهای هر بخش را جداگانه لغو کنند، نه اینکه همهٔ درخواستهای یک برنامه را بهصورت کامل قبول یا رد نمایند.
تغییر چیست؟
مالکین کلاینتهای OAuth میتوانند هنگام پیکربندی کلاینت، فهرستی به نام optional_scopes تعریف کنند. اسکوپهایی که در این فهرست قرار میگیرند در صفحهٔ رضایت بهعنوان مجوزهای قابل حذف نشان داده میشوند و کاربر میتواند آنها را نپذیرد. نمونهٔ پیکربندی:
{
"scopes": [
"user-details.read",
"workers-scripts.write",
"workers-kv-storage.write",
"zone.read"
],
"optional_scopes": [
"workers-kv-storage.write",
"zone.read"
]
}
نکتهٔ کلیدی این است که بررسی لازم یا اختیاری بودن اسکوپها در سطح هر جریان مجوز (authorization flow) انجام میشود، نه صرفاً بر اساس مجموعهای که روی کلاینت پیکربندی شده است. اگر کلاینتی با چهار اسکوپ پیکربندی شده اما فقط دو اسکوپ را درخواست کند، کاربر تنها همان دو اسکوپ را در صفحهٔ رضایت مشاهده میکند.
مسئله برای عاملها (agents)
این تغییر بهویژه برای یکپارچگیهایی که از «عاملها» یا agentها استفاده میکنند اهمیت دارد. عوامل معمولاً به مجموعهٔ گستردهای از مجوزها بهصورت نظری نیاز دارند تا توانایی انجام وظایف مختلف را داشته باشند، اما کاربران بهندرت مایلاند همهٔ این دسترسیها را یکجا اعطا کنند. نمایش همهٔ مجوزها در یک صفحه باعث میشود کاربر یا همه را قبول کند یا همه را رد کند، در نتیجه نرخ ریزش افزایش مییابد.
نمونهٔ عملی: عاملی که فقط وضعیت سفارش را میخواند نیازی به مجوز صدور بازپرداخت ندارد؛ عاملی که برای مقایسهٔ موجودی داده میخواند، نیازی به تغییر قیمتها ندارد. تقسیم مجوزها به اختیاری و ضروری از سردرگمی کاربر میکاهد و احتمال تایید انتخابی را افزایش میدهد.
پیشینه و نمونههای مشابه
مفهوم «رضایت جزئی» جدید نیست. مستندات GitHub توضیح میدهند که کاربران میتوانند اسکوپها را ویرایش کنند (GitHub)، گوگل در رابط رضایت برای برخی اسکوپها چکباکسهای انتخابی نشان میدهد (Google OAuth) و مایکروسافت Entra از رضایت افزایشی پشتیبانی میکند (Microsoft Entra). از نظر پروتکلی نیز RFC 6749 اجازه میدهد سرور مجوز توکنی با اسکوپ باریکتر از درخواستشده صادر کند (RFC 6749).
پیامد برای توسعهدهندگان
پیامد فنی اصلی این است که دیگر نباید فرض شود موفقیت فرایند احراز هویت بهمعنای اعطای تمام اسکوپهای درخواستشده است. وقتی کاربری یک اسکوپ اختیاری را لغو کند، توکن دسترسی فقط شامل اسکوپهای اعطاشده خواهد بود. بنابراین برنامهها باید پس از تبادل کدِ مجوز، مقدار پارامتر scope در پاسخ را بررسی کنند و بر اساس آن عمل نمایند.
اقدامات لازم پس از دریافت توکن
- همیشه مقدار
scopeدر پاسخ توکن را بخوانید و مجوزهای اعطاشده را استخراج کنید. - در فراخوانیهای حساس، وجود مجوز لازم را قبل از انجام عملیات بررسی کنید و در صورت فقدان، مسیر جایگزین ارائه دهید.
- بهجای نمایش خطای جامع، تجربهٔ تدریجی تنزل را پیادهسازی کنید: قابلیتهای فاقد مجوز را غیرفعال کرده و پیام روشنی به کاربر نشان دهید.
الگوی پیشنهادی برای طراحی عاملها
- خواندن را ضروری، نوشتن را اختیاری کنید — عملیاتِ صرفاً خواندنی را با اسکوپ ضروری اجرا کنید و دسترسیهای تغییردهنده را اختیاری قرار دهید.
- قبل از هر اقدام، مجموعهٔ اعطاشده را بررسی کنید — همیشه پارامتر
scopeتوکن را کنترل کنید و از وجود مجوز مناسب اطمینان حاصل کنید. - رفتار تدریجی در مواجهه با کمبود مجوز — قابلیتهای حساس یا نوشتنی را در طراحی طوری قرار دهید که قابل خاموش شدن باشند و به کاربر دلیل محدودیتها گزارش شود.
- لاگ و مانیتورینگ — تغییر در اسکوپهای اعطاشده را لاگ کنید تا الگوهای ریزش یا سوءاستفاده را ردیابی کنید.
جنبهٔ پروتکلی و حقوقی
این قابلیت نیازی به تغییر در پروتکل OAuth نداشت؛ مطابق RFC 6749، سرور مجوز میتواند توکنی با اسکوپ محدودتر از درخواست صادر کند. تغییر مهم، نمایش واضح این امکان در رابطهای رضایت و فراهمسازی کنترلی است که توسعهدهنده میتواند تعیین کند کدام مجوزها "قابل حذف" باشند.
تمهیدات عملی برای تیمهای توسعه
- کلاینتها را بازنگری کنید و اسکوپهایی که الزامی نیستند را به
optional_scopesمنتقل کنید. - در فرآیند تبادل کد به توکن، همیشه مقدار
scopeرا بررسی کنید و مسیرهای جایگزین آماده داشته باشید. - رابطهای کاربری و پیامهای کاربری را طوری طراحی کنید که محدودیتهای عملکردی و دلیل آنها برای کاربر روشن باشد.
- برای یکپارچگیهای مبتنی بر عامل، سناریوهای کاهش مجوز را در تستهای خود لحاظ کنید.
چشمانداز
اعمال اسکوپهای اختیاری توسط کلودفلر، همگرایی تجربهٔ کاربری بهتر و امنیت را تسریع میکند. این قابلیت طراحی سرویسها را به سمت انعطافپذیری و حداقل امتیازدهی سوق میدهد، اما مسئولیت بررسی و مدیریت مجوزها در زمان اجرا را بر دوش توسعهدهندگان میگذارد. تیمها باید این تغییر را فرصتی برای بازطراحی بخشهایی ببینند که پیشتر بر فرض اعطای کامل اسکوپها متکی بودهاند و آمادهٔ پیادهسازی الگوهای مقاومتر و کاربرمحور باشند.
