Scope — token yoki delegatsiya qilingan ruxsat qaysi resurslar va amallar bilan cheklanishini ifodalovchi nomlangan vakolat doirasi. OAuth 2.0da client authorization so‘rovida kerakli scope’larni bildiradi, foydalanuvchi yoki siyosat ularning bir qismini tasdiqlaydi, authorization server esa berilgan vakolatni access token bilan bog‘laydi. Scope foydalanuvchining barcha huquqlarini aynan ko‘chirmaydi; u clientga delegatsiya qilingan, odatda torroq imkoniyatni belgilaydi.
Ifodalash shakli
OAuth so‘rovlarida scope ko‘pincha bo‘sh joy bilan ajratilgan, katta-kichik harfi ahamiyatli satrlar to‘plamidir:
scope=profile invoices.read invoices.write
Nomlarning ma’nosi protokol tomonidan umumiy tarzda belgilanmaydi. profile OpenID Connectda standart claimlar guruhini anglatishi mumkin, invoices.read esa muayyan API ishlab chiquvchisi belgilagan vakolatdir. Authorization server, resource server va client bir xil katalog hamda semantikadan foydalanishi kerak. Noaniq full_access kabi scope audit va rozilik oynasida aniq ma’no bermaydi.
Scope amalga yo‘naltirilgan (orders.read), resursga yo‘naltirilgan yoki ikkalasini birlashtirgan bo‘lishi mumkin. Har bir obyekt identifikatorini alohida scope qilish tokenni haddan tashqari kattalashtiradi. Muayyan invoice ayni foydalanuvchiga tegishlimi, degan obyekt darajasidagi tekshiruv API avtorizatsiyasida bajariladi; invoices.read scope’ining o‘zi barcha invoice’larni ko‘rishga avtomatik ruxsat emas.
So‘ralgan va berilgan vakolat
Client ko‘p scope so‘rashi server ularning barchasini berishini anglatmaydi. Authorization server foydalanuvchi roli, client turi, oldingi rozilik va tashkilot siyosatiga ko‘ra to‘plamni qisqartirishi mumkin. Client javobdagi haqiqiy scope’ni tekshirishi va berilmagan imkoniyatni mavjud deb hisoblamasligi kerak. Authorization server ba’zan scope qiymatini token javobida qaytaradi.
Incremental authorization dasturga barcha vakolatni birinchi login paytida so‘ramasdan, funksiya kerak bo‘lganda qo‘shimcha scope talab qilish imkonini beradi. Bu foydalanuvchi roziligini tushunarli qiladi va buzilgan clientning boshlang‘ich vakolatini kamaytiradi. Refresh token orqali olingan yangi access token dastlabki delegatsiyadan keng scope ololmaydi.
Tekshiruv va siyosat
Resource server tokendagi scope to‘plamini endpoint talabi bilan solishtiradi. O‘qish endpointi orders.read, o‘zgartirish esa orders.write talab qilishi mumkin. Matn ichidan qisman moslik izlash xato: read satri bread ichida uchrashi mumkin. Scope qiymatlari alohida tokenlar sifatida parse qilinib, aniq tenglik yoki hujjatlashtirilgan ierarxiya bo‘yicha tekshiriladi.
Scope va role bir xil tushuncha emas. Role foydalanuvchining tashkilotdagi vazifasini, scope esa muayyan token orqali clientga berilgan delegatsiyani ifodalaydi. Server avval foydalanuvchi va client siyosatidan ruxsatni hisoblab, keyin token scope’i bilan cheklashi mumkin. Eng yakuniy huquq ko‘pincha foydalanuvchi vakolati, client vakolati, scope va resursga egalik shartlarining kesishmasidir.
Loyihalash xususiyatlari
Scope katalogi versiyalanadi va qaysi endpoint qaysi qiymatni talab qilishi hujjatlashtiriladi. Eski clientlarni buzmasdan scope ma’nosini kengaytirish xavfli, chunki avval berilgan token kutilmagan yangi amalni bajarishi mumkin. Yangi vakolat uchun yangi scope yaratiladi. Loglarda tokenning o‘zi emas, tekshiruvda ishlatilgan scope va rad etish sababi qayd etilishi auditni osonlashtiradi.
Consent ekranidagi ko‘rinish
Texnik scope nomi foydalanuvchiga tushunarli matnga xaritalanadi. “Hisob-fakturalarni o‘qish” va “hisob-fakturalarni o‘zgartirish” alohida ko‘rsatilsa, foydalanuvchi delegatsiya oqibatini anglaydi. Tarjima yoki tavsif o‘zgarsa, uning ortidagi vakolat semantikasi yashirin kengaymasligi kerak. Sensitive scope administrator tasdig‘i yoki qayta autentifikatsiya talab qilishi mumkin. Consent yozuvi qaysi client, subyekt, scope to‘plami va siyosat versiyasi tasdiqlanganini saqlaydi.
Bog‘liq tushunchalar
OAuth 2.0, Access token, Authorization, Consent, Least privilege, Role, Resource server