JWT nima? — Header, Payload, Signature, qanday ishlaydi
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
- Imzo — o'z kaliti bilan qayta hisoblab solishtiradi
exp— muddati o'tmaganmiiss,aud— kutilgan qiymatlarmi- Algoritm — kutilganmi (
alg: nonehujumiga 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; SameSitecookie da saqlash yoki "Backend for Frontend" (BFF) naqshi. Mobil ilovalarda — platformaning xavfsiz saqlash joyi.Authorization: Bearersarlavhasi — 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