IAM - Identity and Access Management

Bugungi mavzu: IAM. IAM (identity and access management) - bu keng tushuncha hisoblanadi, unga password hashing, JWT, RBAC/ABAC (rbac va abac haqida oldingi postga yozgandim, pastda link qoldiraman) hammasi IAMga kiradi. IAM - bu 4 katta savolga javob beradi ular authentication, authorization, session/token management, provision/sso.

Authentication - foydalanuvchini tasdiqlash, password hashing, JWT. Bunda password hashing qilinadi va jwt tokenlar yaratiladi.

Authorization - foydalanuvchining huquqlari, RBAC, ABAC

Session / Token: kirish holatlarini saqlash, access va refresh token. Bunda foydalanuvchi login qilganidan keyin uning holati qanday saqlanishi haqida. Bu yerda bir nechta muhim savollar bo'ladi:

  • Access token qancha yashaydi ? (15 daqiqa)
  • Refresh token qanday ishlaydi - uni yo'qotib (revoke) qo'yish mumkinmi ?
  • Bir nechta qurilmadan login qilgan userni qanday kuzatib boorish kerak ? Endi shu qismda savol paydo bo'ladi nega bizda 2 ta token bittasi yetmaydimi ?

Tasavvur qiling, sizda faqat bitta JWT bor va u 7 kun amal qiladi ( yani foydalanuvchi 7 kun login bo'lgan bo'lib turadi). Xo'sh bunda muammo nimada ?

Muammo: agarda token o'g'irlansa (ex: XSS orqali tarmoq orqali ushlab qolinsa) - attacker 7 kun davomida sizning nomingizdan harakat qila oladi.

Yechim: 2 ta token ishlatilishi: access_token - qisqa (15 daqiqa) va har bir so'rovda yuboriladi. refresh_token - uzoq (7-30kun) va faqatt yangi access token olish uchun ishlatiladi. Bu ikkalasining orasidagi asosiy farq: access token — bu stateless (server hech narsani eslamaydi, faqat imzo orqali ishonadi). Refresh token esa odatda stateful — uni siz o'zingiz Postgres yoki Redis'da saqlaysiz (masalan refresh_tokens jadvalida: user_id, token_hash, expires_at, device_info).

Reshresh token uzoq yashasa ham xavsiz sababi: u kamroq marta tarmoq orqali yuboriladi (faqat yangilash surovida). Server reshresh tkenni istalgan payt DBdan o'chirib bekor qila oladi - bu access tokenda imkonsiz hisoblanadi.

Shu qismda yana savol tug'iladi unda logout qanday ishlaydi ? Logout - refresh tokenni DB'dan o'chirishdir. Access token hali 15 daqiqagacha "texnik jihatdan" amal qiladi (buni toxtaib bo'lmaydi), lekin foydalanuvchi endi yangi access token ololmaydi, chunki refresh token endi mavjud emas.

Endi savol agar biz logout qilsak va access token attacker tomonidan o'g'irlansa va u 15 daqiqa davomida bizning nomimizdan harakatlarni bajara olsa buni oldini olishning yoki butunlay yo'q qilish mumkinmi ? (bu savolga javobni commentda kutib qolaman)

Provisioning va SSO: user yaratish, google/telegram/linkedin bilan login. Bu qismda yangi user qanday yaratildi ? tashqi provider (google/tg/linkedin) orqalimi ? SSO (Single Sign-On) - bitta login bilan bir nechta tizimga kirish qanday amalga oshiriladi ? Bitta odam ham email, ham Telegram bilan login qilsa - ular bitta userga qanday bog'lanadi (Accounting linking) ?

Provisioning - bu foydalanuvchi birinchi marta tizimga kirganda, uning uchun avtomatik ravishda account yaratish jarayoni hisoblanadi.

Oddiy misol bilan solishtiraylik: bizda register uchun shunaqa case bor RegisterUseCaseda — user o'zi email va parol kiritadi, siz User entity yaratasiz. Bu manual provisioning.

Lekin Google orqali login qilganda, user hech qachon "Register" tugmasini bosmaydi — u faqat "Google bilan kirish" tugmasini bosadi, va agar bu uning birinchi marta kirishi bo'lsa, tizim avtomatik ravishda uning uchun user yaratishi kerak. Bu — JIT (Just-In-Time) Provisioning.

SSO - Single Sign-On bu foydalanuvchi bitta joyda (ex: google acc) login qilib, keyin boshqa ko'plab tizimlardan qayta parol kiritmasdan kira olishi.

Ijtimoiy login (Social Login) — faqat "Google orqali kim ekaningni tasdiqlayman" — bu ko'proq tarqalgan, sizning holingizga mos Haqiqiy SSO — korporativ muhitda, masalan bitta kompaniya Okta/Azure AD orqali barcha ichki tizimlarga (Slack, Jira, Gmail) bitta login bilan kiradi