Authorization

Authorization — foydalanuvchi yoki tizimning qaysi resurslarga kirishi va qaysi amallarni bajarishi mumkinligini belgilaydigan jarayon. Authorization authenticationdan keyin ishlaydi va foydalanuvchining huquqlarini tekshiradi.

Authentication foydalanuvchi kimligini aniqlasa, authorization shu foydalanuvchiga nima qilish mumkinligini belgilaydi.

Vazifasi

Authorization tizim ichidagi ruxsatlarni boshqarish uchun ishlatiladi.

Authorization quyidagi vazifalarni bajaradi:

foydalanuvchi huquqlarini tekshirish;
admin, moderator va oddiy user rollarini ajratish;
sahifa yoki API endpointlarga kirishni cheklash;
ma’lumotlarni ko‘rish, yaratish, tahrirlash yoki o‘chirish huquqini nazorat qilish;
role va permission asosida ruxsat berish;
maxfiy resurslarni himoyalash;
tashkilot yoki guruh ichidagi huquqlarni boshqarish;
audit va xavfsizlik siyosatini qo‘llash.

Masalan, foydalanuvchi login qilgan bo‘lishi mumkin, lekin admin panelga kirish huquqi bo‘lmasligi mumkin. Bu authorization orqali aniqlanadi.

Authorization qanday ishlaydi?

Authorization jarayonida tizim foydalanuvchining role, permission yoki boshqa ruxsat ma’lumotlarini tekshiradi.

Oddiy jarayon:

foydalanuvchi tizimga kiradi;
authentication orqali kimligi aniqlanadi;
foydalanuvchi ma’lum sahifa yoki API’ga murojaat qiladi;
tizim foydalanuvchining role yoki permissionlarini tekshiradi;
ruxsat bo‘lsa, amal bajariladi;
ruxsat bo‘lmasa, xatolik qaytariladi.

Masalan, DELETE /api/users/15 endpointi faqat admin role’iga ega foydalanuvchilar uchun ochiq bo‘lishi mumkin.

Authentication va authorization farqi

Authentication va authorization bir-biriga bog‘liq, lekin alohida tushunchalardir.

Authentication — foydalanuvchi kimligini tekshiradi;
Authorization — foydalanuvchi nima qila olishini tekshiradi;
authentication login jarayonida ishlaydi;
authorization login qilingandan keyin resurslarga kirishda ishlaydi;
authentication “Siz kimsiz?” savoliga javob beradi;
authorization “Sizga nima qilish mumkin?” savoliga javob beradi.

Masalan, foydalanuvchi tizimga parol bilan kirsa, bu authentication. U faqat o‘z profilini tahrirlay olsa, bu authorization.

Role

Role — foydalanuvchining tizimdagi maqomi yoki vazifasi. Role authorization tizimida keng ishlatiladi.

Role misollari:

admin;
moderator;
user;
guest;
editor;
manager;
owner;
support;
developer.

Masalan, blog platformasida editor maqola yozishi mumkin, admin esa foydalanuvchilarni boshqarishi mumkin.

Permission

Permission — foydalanuvchiga berilgan aniq ruxsat. Permission role’dan ko‘ra maydaroq va aniqroq bo‘ladi.

Permission misollari:

maqola yaratish;
maqolani tahrirlash;
maqolani o‘chirish;
foydalanuvchilar ro‘yxatini ko‘rish;
buyurtmani tasdiqlash;
to‘lov ma’lumotini ko‘rish;
fayl yuklash;
admin panelga kirish.

Masalan, article.create permissioni foydalanuvchiga maqola yaratish huquqini bildirishi mumkin.

Role-based access control

Role-based access control yoki RBAC — foydalanuvchilarga role berish va ruxsatlarni shu role orqali boshqarish modeli.

RBAC jarayonida:

role yaratiladi;
role’ga permissionlar biriktiriladi;
foydalanuvchiga role beriladi;
tizim foydalanuvchi role’i orqali ruxsatni tekshiradi.

Masalan:

admin — barcha huquqlarga ega;
editor — maqola yaratadi va tahrirlaydi;
user — faqat o‘z profilini ko‘radi;
guest — faqat ochiq sahifalarni ko‘radi.

RBAC ko‘plab web ilova va admin panellarda ishlatiladi.

Permission-based access control

Permission-based access control — har bir foydalanuvchi yoki role uchun aniq permissionlar asosida ruxsat berish modeli.

Bu yondashuvda tizim role nomiga emas, aniq permissionga qaraydi.

Masalan:

user.view;
user.create;
user.update;
user.delete;
article.publish;
order.refund.

Bunday model katta tizimlarda ruxsatlarni mayda darajada boshqarishga yordam beradi.

Attribute-based access control

Attribute-based access control yoki ABAC — ruxsatni foydalanuvchi, resurs, muhit va boshqa atributlar asosida belgilaydigan model.

ABAC’da quyidagi atributlar ishlatilishi mumkin:

foydalanuvchi role’i;
foydalanuvchi bo‘limi;
resurs egasi;
tashkilot ID’si;
vaqt;
IP manzil;
qurilma turi;
so‘rov turi.

Masalan, foydalanuvchi faqat o‘z tashkilotiga tegishli hujjatlarni ko‘ra olishi mumkin.

Access control list

Access control list yoki ACL — resursga kimlar qanday huquq bilan kira olishini belgilaydigan ro‘yxat.

ACL ichida quyidagilar bo‘lishi mumkin:

foydalanuvchi ID’si;
guruh nomi;
role;
o‘qish huquqi;
yozish huquqi;
o‘chirish huquqi;
boshqarish huquqi.

Masalan, fayl tizimida bitta hujjatni faqat ma’lum foydalanuvchilar o‘qishi yoki tahrirlashi mumkin.

Resource

Resource — tizim ichidagi himoyalangan obyekt yoki ma’lumot. Authorization aynan shu resurslarga kirishni boshqaradi.

Resource misollari:

foydalanuvchi profili;
maqola;
komment;
buyurtma;
to‘lov ma’lumoti;
fayl;
loyiha;
admin sahifa;
API endpoint;
database yozuvi.

Masalan, Order resursini faqat buyurtma egasi yoki admin ko‘rishi mumkin.

Action

Action — foydalanuvchi resurs ustida bajarmoqchi bo‘lgan amal.

Action misollari:

view;
create;
update;
delete;
publish;
approve;
reject;
export;
import;
manage.

Authorization tizimi foydalanuvchi muayyan resursda muayyan action bajara olishini tekshiradi.

Owner

Owner — ma’lum resurs egasi. Ko‘p tizimlarda foydalanuvchi faqat o‘ziga tegishli resurslarni ko‘rishi yoki tahrirlashi mumkin.

Owner asosidagi authorization misollari:

foydalanuvchi faqat o‘z profilini tahrirlaydi;
muallif faqat o‘z maqolasini o‘zgartiradi;
mijoz faqat o‘z buyurtmalarini ko‘radi;
kompaniya a’zosi faqat o‘z tashkiloti ma’lumotlarini ko‘radi.

Bunday tekshiruvlar row-level yoki object-level authorization bilan bog‘liq.

Object-level authorization

Object-level authorization — ruxsatni alohida obyekt darajasida tekshirish jarayoni.

Masalan:

foydalanuvchi maqolani tahrirlay oladi, lekin faqat o‘zi yozgan maqolani;
admin barcha buyurtmalarni ko‘radi, oddiy user faqat o‘z buyurtmalarini;
manager faqat o‘z filialiga tegishli xodimlarni ko‘radi.

Bu authorization turi API va backend tizimlarda muhim hisoblanadi.

Route protection

Route protection — sahifa yoki route’ga kirishni ruxsat asosida cheklash jarayoni.

Frontend route protection quyidagi holatlarda ishlatiladi:

login qilmagan foydalanuvchini profil sahifasiga kiritmaslik;
oddiy userni admin paneldan cheklash;
role asosida menyularni yashirish;
token bo‘lmasa login sahifasiga yo‘naltirish.

Backend route protection esa API endpoint darajasida ruxsatlarni tekshiradi.

Protected endpoint

Protected endpoint — authentication yoki authorization talab qiladigan API endpoint.

Protected endpoint misollari:

GET /api/profile;
POST /api/articles;
PUT /api/users/15;
DELETE /api/comments/20;
GET /api/admin/stats.

Bunday endpointlarga faqat ruxsatga ega foydalanuvchilar murojaat qila oladi.

Public endpoint

Public endpoint — authentication talab qilmaydigan ochiq API endpoint.

Public endpoint misollari:

ro‘yxatdan o‘tish;
login;
ochiq maqolalar ro‘yxati;
mahsulotlar ro‘yxati;
public sahifa ma’lumotlari;
contact form;
health check.

Public endpoint ochiq bo‘lsa ham, rate limiting va input validation kabi xavfsizlik qatlamlari bo‘lishi mumkin.

Admin panel

Admin panel authorization ko‘p ishlatiladigan joylardan biridir. Bu yerda foydalanuvchi role va permissionlari asosida turli bo‘limlarga kiradi.

Admin panelda authorization quyidagilarni boshqaradi:

foydalanuvchilarni ko‘rish;
maqolalarni boshqarish;
buyurtmalarni tahrirlash;
to‘lovlarni ko‘rish;
sozlamalarni o‘zgartirish;
statistika ko‘rish;
role va permissionlarni boshqarish.

Masalan, moderator faqat kommentlarni boshqarishi, admin esa barcha bo‘limlarga kirishi mumkin.

Frontenddagi o‘rni

Frontend authorization foydalanuvchiga qaysi sahifa, tugma yoki component ko‘rinishini boshqaradi.

Frontend’da authorization quyidagilarda ishlatiladi:

protected route;
admin menyu;
tahrirlash tugmasi;
o‘chirish tugmasi;
role asosidagi dashboard;
permission asosidagi UI;
login qilmagan foydalanuvchini redirect qilish;
foydalanuvchi statusiga qarab sahifa chiqarish.

Frontend authorization ko‘rinishni boshqaradi, lekin asosiy ruxsat tekshiruvi backendda bajariladi.

Backenddagi o‘rni

Backend authorization tizim xavfsizligining asosiy qismidir. Backend har bir muhim API so‘rovda foydalanuvchi ruxsatini tekshiradi.

Backend’da authorization quyidagilar bilan ishlaydi:

middleware;
decorator;
guard;
policy;
permission class;
role checker;
ownership check;
database query filter;
token claimlari.

Masalan, backend foydalanuvchi tokenidan user ID va role’ni olib, so‘rov bajarilishidan oldin ruxsatni tekshiradi.

Middleware

Authorization middleware so‘rov backend endpointga yetib borishidan oldin ruxsatni tekshiradi.

Middleware quyidagilarni bajarishi mumkin:

tokenni tekshirish;
foydalanuvchini aniqlash;
role’ni tekshirish;
permission mavjudligini tekshirish;
ruxsat bo‘lmasa xatolik qaytarish;
ruxsat bo‘lsa so‘rovni davom ettirish.

Middleware authorization jarayonini markazlashtirishda ishlatiladi.

Policy

Policy — foydalanuvchi muayyan resurs ustida amal bajara olishini belgilaydigan ruxsat qoidasi.

Policy misollari:

foydalanuvchi o‘z maqolasini tahrirlay oladi;
admin barcha foydalanuvchilarni o‘chira oladi;
editor maqola publish qila oladi;
manager faqat o‘z bo‘limi hisobotlarini ko‘ra oladi.

Policy authorization logikasini alohida va tartibli saqlash uchun ishlatiladi.

Guard

Guard — ayrim frameworklarda route yoki endpointga kirishdan oldin ruxsatni tekshiradigan qatlam. Guard authentication va authorization tekshiruvlarini bajarishi mumkin.

Guard quyidagilarni tekshiradi:

foydalanuvchi login qilinganmi;
token yaroqlimi;
role mosmi;
permission bormi;
route yopiqmi yoki ochiqmi.

Masalan, NestJS’da guard endpointga kirishdan oldin foydalanuvchi huquqini tekshiradi.

Token claim

Token claim — token ichidagi foydalanuvchi yoki ruxsat haqida ma’lumot. JWT tokenlarda claimlar authorization uchun ishlatilishi mumkin.

Claim misollari:

user ID;
role;
permissions;
organization ID;
token muddati;
issuer;
audience.

Backend token claimlarini o‘qib, foydalanuvchining ruxsatlarini tekshirishi mumkin.

Scope

Scope — OAuth va API authorization tizimlarida ruxsat doirasini bildiradigan tushuncha.

Scope misollari:

read:profile;
write:profile;
read:orders;
manage:users;
repo;
email.

Masalan, tashqi ilovaga faqat foydalanuvchi emailini o‘qish scope’i berilishi mumkin, lekin profilni o‘zgartirish huquqi berilmasligi mumkin.

API authorization

API authorization har bir so‘rov qaysi foydalanuvchi yoki service tomonidan yuborilganini va u qanday amal bajara olishini tekshiradi.

API authorization quyidagilarga asoslanishi mumkin:

Masalan, POST /api/products endpointi faqat product.create permissioniga ega foydalanuvchilar uchun ochiq bo‘lishi mumkin.

Service-to-service authorization

Service-to-service authorization — bir service boshqa service’ga murojaat qilganda ruxsatni tekshirish jarayoni.

Bu jarayonda quyidagilar ishlatilishi mumkin:

API key;
mTLS;
service account;
internal token;
signed request;
private network;
OAuth client credentials.

Masalan, payment service order service’dan buyurtma ma’lumotini olish uchun maxsus service token bilan murojaat qilishi mumkin.

Deny by default

Deny by default — ruxsat berilmagan barcha amallarni avtomatik rad etish yondashuvi. Bu xavfsizlikda keng ishlatiladigan prinsip.

Bu yondashuvda:

ochiq ruxsat berilmagan resurs yopiq hisoblanadi;
permission aniq ko‘rsatilmasa, amal bajarilmaydi;
yangi endpointlar default yopiq bo‘lishi mumkin;
admin huquqlari alohida belgilanadi.

Deny by default authorization tizimida xavfsizlik qatlamini kuchaytiradi.

Least privilege

Least privilege — foydalanuvchiga faqat kerakli minimal ruxsatlarni berish prinsipi.

Least privilege quyidagi holatlarda ishlatiladi:

oddiy userga admin huquqi bermaslik;
service accountga faqat kerakli API ruxsatini berish;
moderator huquqlarini aniq cheklash;
database foydalanuvchisiga minimal permission berish;
CI/CD tokenlarini cheklash.

Bu prinsip ruxsatlar ortiqcha kengayib ketmasligini ta’minlaydi.

Authorization xatoliklari

Authorization jarayonida foydalanuvchiga ruxsat bo‘lmasa, tizim xatolik qaytaradi.

Ko‘p uchraydigan status codelar:

401 Unauthorized — foydalanuvchi authenticationdan o‘tmagan;
403 Forbidden — foydalanuvchi authenticationdan o‘tgan, lekin ruxsati yo‘q;
404 Not Found — ayrim tizimlarda mavjud resursni yashirish uchun ishlatilishi mumkin.

Masalan, login qilmagan foydalanuvchi profil sahifasiga kirsa 401, oddiy user admin sahifaga kirsa 403 qaytishi mumkin.

Authorization va database

Authorization database bilan ham bog‘liq bo‘lishi mumkin. Role, permission, user group va resurs egaligi ko‘pincha database’da saqlanadi.

Database’da quyidagi jadvallar bo‘lishi mumkin:

users;
roles;
permissions;
user_roles;
role_permissions;
groups;
organization_members;
resource_permissions.

Masalan, foydalanuvchi qaysi organization a’zosi ekaniga qarab unga ma’lumotlar ko‘rsatiladi.

Row-level security

Row-level security — database jadvalidagi qatorlar darajasida ruxsatlarni cheklash mexanizmi.

Masalan:

foydalanuvchi faqat o‘z buyurtmalarini ko‘radi;
kompaniya faqat o‘z xodimlarini ko‘radi;
filial rahbari faqat o‘z filialiga tegishli ma’lumotlarni ko‘radi.

Bu yondashuv authorizationni database darajasida ham qo‘llash imkonini beradi.

Multi-tenant authorization

Multi-tenant authorization — bitta tizim ichida bir nechta tashkilot, kompaniya yoki mijoz ma’lumotlarini ajratib boshqarish jarayoni.

Multi-tenant tizimlarda authorization quyidagilarni tekshiradi:

foydalanuvchi qaysi tenantga tegishli;
so‘ralgan resurs qaysi tenantga tegishli;
foydalanuvchi shu tenantda qanday role’ga ega;
tenantlar orasida ma’lumot aralashib ketmasligi.

Masalan, SaaS tizimida har bir kompaniya faqat o‘z ma’lumotlarini ko‘radi.

Authorization va audit

Authorization audit jarayonida kim qaysi resursga kirgani yoki qanday amal bajargani yozib borilishi mumkin.

Audit log ichida quyidagilar bo‘lishi mumkin:

foydalanuvchi ID;
bajarilgan amal;
resurs turi;
resurs ID;
vaqt;
IP manzil;
natija;
ruxsat rad etilgan holatlar.

Audit xavfsizlik, tekshiruv va qonuniy talablar uchun ishlatilishi mumkin.

Authorization xavfsizligi

Authorization noto‘g‘ri tuzilsa, foydalanuvchi o‘ziga tegishli bo‘lmagan ma’lumotlarga kira olishi mumkin.

Authorization xavfsizligida quyidagi tushunchalar uchraydi:

broken access control;
privilege escalation;
IDOR;
role bypass;
permission misconfiguration;
token claim manipulation;
insecure direct object reference;
missing ownership check.

Bu muammolar backend ruxsat tekshiruvlari bilan bevosita bog‘liq.

IDOR

IDOR — Insecure Direct Object Reference, ya’ni foydalanuvchi obyekt ID’sini o‘zgartirib, o‘ziga tegishli bo‘lmagan ma’lumotga kira oladigan xavfsizlik muammosi.

Masalan:

/api/orders/100

Agar foydalanuvchi 100 o‘rniga 101 yozib, boshqa foydalanuvchi buyurtmasini ko‘ra olsa, bu IDOR bo‘lishi mumkin.

IDOR object-level authorization yetarli tekshirilmaganda yuzaga keladi.

Privilege escalation

Privilege escalation — foydalanuvchi o‘z huquqidan yuqoriroq imkoniyatga ega bo‘lib qoladigan holat.

Privilege escalation misollari:

oddiy user admin endpointdan foydalanishi;
moderator admin permission olishi;
token ichidagi role qiymatini o‘zgartirish;
URL yoki API orqali yashirin amal bajarish;
noto‘g‘ri permission sozlamasi sababli ortiqcha huquq olish.

Bu authorization tizimidagi jiddiy xavfsizlik muammolaridan biridir.

Dasturlashdagi o‘rni

Authorization foydalanuvchi akkaunti, role, permission va resurslar mavjud bo‘lgan deyarli barcha tizimlarda ishlatiladi. U tizim ichidagi huquqlarni boshqaradi va ma’lumotlarni ruxsatsiz kirishdan himoya qiladi.

Authorization quyidagi loyihalarda uchraydi:

web saytlar;
admin panellar;
SaaS platformalar;
CRM tizimlar;
internet do‘konlar;
mobile ilovalar;
banking tizimlari;
korporativ portallar;
API service’lar;
multi-tenant platformalar.

Authorization authenticationdan keyin foydalanuvchining tizimdagi huquqlarini nazorat qiladigan asosiy xavfsizlik qatlamidir.

Bog‘liq tushunchalar

Authentication, Role, Permission, RBAC, ABAC, ACL, API, Token, JWT, Middleware, Backend, Security