قابلیت را نام‌گذاری کنید
Scope باید روشن کند کلاینت چه دسترسی‌ای می‌خواهد. نام قابلیت قابل فهم را به نام وابسته به جزئیات اتفاقی پیاده‌سازی ترجیح دهید. مشخص کنید معنای هر scope در مالکیت کدام API است.
صرفاً به دلیل نیاز اولین کلاینت، یک scope نامحدود برای همه‌چیز نسازید. این تصمیم تفکیک دسترسی در آینده را دشوار می‌کند.
Scope را از قانون کسب‌وکار جدا کنید
اجازه فراخوانی API سفارش، اجازه خواندن سفارش همه مشتریان نیست. API همچنان باید مالکیت، نقش یا قانون مرتبط با همان منبع را بررسی کند.
مخاطب توکن را هم از scope جدا کنید. اولی گیرنده مورد نظر را مشخص می‌کند و دومی نوع دسترسی واگذارشده را.
کل قرارداد را بازبینی کنید
برای هر کلاینت، عملیات لازم و حداقل دسترسی مورد نیاز را بنویسید. ثبت سرویس هویت باید با سیاست مجوز API هماهنگ باشد.
نبود scope، مخاطب نادرست و دسترسی به منبع شخص دیگر را تست کنید. مستند بودن scope زمانی مفید است که API دریافت‌کننده مرز آن را اعمال کند.
منبع برای مطالعه بیشتر
مستندات و استاندارد مرجع