JWT nima? — Header, Payload, Signature, qanday ishlaydi

~20 daq · .NET Backend · Autentifikatsiya va Avtorizatsiya

Muammodan boshlaylik

Foydalanuvchi login qildi — parol to'g'ri (58-dars). Endi keyingi har bir so'rovda ("mening buyurtmalarim", "savatga qo'shish") server uning kim ekanini bilishi kerak. Har safar email va parol yuborish — xavfli va noqulay.

Klassik yechim — sessiya: server xotirasida "sessiya ID → foydalanuvchi" jadvali, brauzerda cookie. Lekin:

  • Mobil ilova cookie lar bilan noqulay ishlaydi
  • 5 ta server nusxasi bo'lsa — sessiya qaysi serverda? Umumiy saqlash (Redis) kerak
  • Mikroservislar har biri foydalanuvchini tekshirish uchun markaziy sessiya xizmatiga murojaat qiladi

JWT nima?

JWT (JSON Web Token, "jot" deb o'qiladi) — foydalanuvchi haqidagi ma'lumot va imzoni o'z ichiga olgan ixcham token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsImVtYWlsIjoibG9sYUBtYWlsLnV6Iiwicm9sZSI6InVzZXIiLCJleHAiOjE3NjI2MDAwMDB9.4tJ8kXk7m2Zq_Yb5...
└──────────── header ───────────────┘ └──────────────────────────── payload ─────────────────────────────────────┘ └── signature ──┘

Uch qism, nuqta bilan ajratilgan, har biri Base64Url kodlangan.

Login: email + parol ──▶ Server tekshiradi ──▶ JWT beradi
Keyingi so'rovlar:  Authorization: Bearer <JWT>  ──▶ Server imzoni tekshiradi ──▶ kim ekanini biladi

Server foydalanuvchini aniqlash uchun bazaga yoki sessiya jadvaliga murojaat qilmaydi — hamma narsa tokenning ichida, va imzo uning soxta emasligini kafolatlaydi.


Hayotiy o'xshatma

Konsertga kirish bilagi. Kassada pasportingizni tekshirib (login), qo'lingizga muhrlangan bilaguzuk taqishadi: "VIP, 8-noyabr". Keyin har bir eshikda qo'riqchi pasport so'ramaydi — bilaguzukka va muhrga qaraydi. Muhrni soxtalashtirib bo'lmaydi (imzo), bilaguzuk ertaga yaroqsiz (muddat). Lekin bilaguzukdagi yozuvni hamma o'qiy oladi — unga maxfiy narsa yozilmaydi.


1. Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Imzo algoritmi: HS256 — bitta maxfiy kalit (HMAC-SHA256); RS256 — ochiq/yopiq kalit juftligi.

2. Payload — claims

{
  "sub": "42",
  "email": "lola@mail.uz",
  "role": "user",
  "iss": "dokon-api",
  "aud": "dokon-app",
  "iat": 1762596400,
  "exp": 1762600000
}

Claim — token ichidagi bitta da'vo (ma'lumot):

Claim Ma'nosi
sub Subject — foydalanuvchi ID si
iss Issuer — kim chiqargan
aud Audience — kim uchun mo'ljallangan
exp Expiration — qachon yaroqsiz bo'ladi (Unix vaqt)
iat Issued at — qachon chiqarilgan
nbf Not before — qachondan yaroqli
jti Token ID — noyob identifikator
role, email... O'z claim laringiz

[!WARNING] Payload shifrlanmagan — faqat Base64 da kodlangan. Uni jwt.io da yoki bir qator kod bilan istalgan odam o'qiydi. Tokenga hech qachon parol, karta raqami, pasport ma'lumotlari va boshqa maxfiy narsalarni qo'ymang. Faqat ID, rol va zarur minimal ma'lumot.

3. Signature

HMACSHA256(
  base64Url(header) + "." + base64Url(payload),
  maxfiy_kalit
)

Imzo — header va payload dan maxfiy kalit bilan hisoblanadi. Kalit faqat serverda.

Kimdir payload da "role": "user" ni "role": "admin" ga o'zgartirsa — imzo endi mos kelmaydi, va server tokenni rad etadi. Kalitsiz to'g'ri imzo yasab bo'lmaydi.


Server tokenni qanday tekshiradi

  1. Imzo — o'z kaliti bilan qayta hisoblab solishtiradi
  2. exp — muddati o'tmaganmi
  3. iss, aud — kutilgan qiymatlarmi
  4. Algoritm — kutilganmi (alg: none hujumiga qarshi)

Hammasi to'g'ri bo'lsa — claim lardan foydalanuvchi aniqlanadi (User ob'ekti, 60-dars).


Afzalliklar va kamchiliklar

✅ ⚠️
Stateless — server sessiya saqlamaydi Muddati tugaguncha bekor qilish qiyin (chiqish, bloklash)
Bir nechta server, mikroservislar — hammasi kalit bilan tekshiradi Token o'g'irlansa — muddati tugaguncha ishlaydi
Mobil ilovalar va SPA uchun qulay Rol o'zgarsa — eski token eski rol bilan yuradi
Domenlararo ishlaydi Token hajmi cookie sessiya ID sidan katta

Kamchiliklarga qarshi:

  • Qisqa muddatli access token (5–15 daqiqa) + uzoq muddatli refresh token (62-dars)
  • Muhim amallarda (to'lov, rol o'zgarishi) ma'lumotni bazadan qayta tekshirish

Token qayerda saqlanadi

Joy Xavf
localStorage (brauzer) XSS bilan o'g'irlanadi
httpOnly cookie JavaScript o'qiy olmaydi; CSRF ga ehtiyot (SameSite)
Mobil ilova — Keychain / Keystore Xavfsiz saqlash

[!TIP] Brauzer ilovalari uchun eng xavfsiz yondashuv — tokenni httpOnly; Secure; SameSite cookie da saqlash yoki "Backend for Frontend" (BFF) naqshi. Mobil ilovalarda — platformaning xavfsiz saqlash joyi. Authorization: Bearer sarlavhasi — API ga yuborishning standart usuli.


Tez-tez uchraydigan xatolar

Payload da maxfiy ma'lumot — hamma o'qiydi.

Qisqa yoki taxmin qilinadigan kalit ("secret", "12345") — kalitni tanlab topib, istalgan token yasash mumkin. HS256 uchun kamida 256 bit (32+ tasodifiy bayt).

Muddatsiz yoki juda uzoq muddatli token — o'g'irlansa, abadiy ishlaydi.


Xulosa

JWT — header.payload.signature: ma'lumot (claims) va uni maxfiy kalit bilan himoyalovchi imzo. Server sessiya saqlamaydi — imzo, exp, iss, aud ni tekshirib foydalanuvchini aniqlaydi; payload o'zgartirilsa — imzo mos kelmaydi.

Payload shifrlanmagan — faqat ID, rol, minimal ma'lumot. Asosiy claim lar: sub, exp, iss, aud, iat. Kamchiligi — bekor qilish qiyin: qisqa access token + refresh token. Kalit — uzun va tasodifiy, faqat serverda; tokenni xavfsiz joyda saqlang.


Keyingi dars

60-dars: JWT o'rnatish — JwtBearer, token yaratish, sozlash