JWT: bu nima, JSON Web Token tuzilishi va qo'llanilishi

JWT nima?

JSON Web Token (JWT) — bu tomonlar o‘rtasida ma’lumotlarni JSON obyekti shaklida uzatishning ixcham va o‘zini-o‘zi ta’minlovchi usulini belgilaydigan ochiq standartdir (RFC 7519). JWT dagi ma’lumot claims deb ataladi — subyekt (foydalanuvchi) va qo‘shimcha atributlar haqidagi tasdiqlar. Har bir claim kalit-qiymat juftidir: foydalanuvchi identifikatori, rol, amal qilish muddati, chiqaruvchi.

JWT o‘zini-o‘zi ta’minlovchi deb ataladi, chunki tekshirish uchun barcha ma’lumotlar tokenning o‘zida joylashgan. Server tokenning haqiqiyligiga ishonch hosil qilish uchun ma’lumotlar bazasiga yoki tashqi xotiraga murojaat qilishi shart emas — imzoni tekshirish kifoya. Bu xususiyat JWT ni taqsimlangan tizimlar va bir nechta xizmatlar umumiy sessiya xotirasiz so‘rovlarni autentifikatsiya qilishi kerak bo‘lgan mikroxizmat arxitekturasi uchun ideal qiladi.

Auth0, 2025 ma’lumotlariga ko‘ra, mobil va veb ilovalarning 65% dan ortig‘i API autentifikatsiyasi uchun asosiy token formati sifatida JWT dan foydalanadi, opaque tokenlar va sessiya identifikatorlaridan o‘zib ketadi.

JWT tuzilishi: header, payload va signature

JWT nuqtalar bilan ajratilgan uch qismdan iborat: header.payload.signature. Har bir qism Base64url kodlangan JSON dir. Keling, har bir qismni batafsil ko‘rib chiqaylik.

Header — algoritm va token turi

Header ikkita majburiy maydonni o‘z ichiga oladi: alg (algorithm — imzo algoritmi) va typ (type — token turi, har doim “JWT”). Algoritm simmetrik (HS256 — HMAC SHA-256 bilan) yoki asimmetrik (RS256 — RSA SHA-256 bilan, ES256 — ECDSA P-256 bilan) bo‘lishi mumkin. Asimmetrik algoritmlar afzalroq, chunki ular mijozga maxfiy kalitga ega bo‘lmasdan imzoni tekshirishga imkon beradi.

Dekodlangan header namunasi:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims va ma’lumotlar

Payload claims — subyekt haqidagi tasdiqlarni o‘z ichiga oladi. Claims uch turga bo‘linadi: ro‘yxatdan o‘tgan (iss, sub, aud, exp, nbf, iat, jti), ommaviy (dasturchi tomonidan IANA Registry da belgilangan) va xususiy (tomonlar o‘rtasida kelishilgan). sub (subject) — foydalanuvchining noyob identifikatori. exp (expiration) — tokenning amal qilish muddati. iss (issuer) — token chiqaruvchisi.

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — yaxlitlikni tekshirish

Signature maxfiy yoki xususiy kalit yordamida header va payload birikmasiga imzo algoritmini qo‘llash orqali yaratiladi. Formula: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) HMAC uchun, yoki RSASHA256(...) asimmetrik algoritm uchun. Qabul qiluvchi imzoni xuddi shu usulda hisoblaydi va olingan bilan solishtiradi — agar mos kelsa, ma’lumotlar o‘zgartirilmagan.

JWT qanday ishlaydi: yaratish va tekshirish

Ishlash jarayoni JWT ikki bosqichdan iborat: autentifikatsiya serveri tomonidan token yaratish (chiqarish) va mijoz yoki resurs serveri tomonidan tokenni tekshirish. Autentifikatsiya serveri foydalanuvchi ma’lumotlarini oladi, claims bilan payload yaratadi va uni imzolaydi. Hosil bo‘lgan JWT mijozga kirish so‘roviga javoban yoki OAuth 2.0 / OpenID Connect javobining tanasida yuboriladi.

Mobil autentifikatsiyada JWT

Mobil ilovalarda JWT quyidagi tarzda ishlatiladi: muvaffaqiyatli kirishdan so‘ng, foydalanuvchi JWT formatida access token oladi. Ilova uni xavfsiz xotirada saqlaydi (iOS da Keychain, Android da EncryptedSharedPreferences). Har bir API so‘rovida ilova Authorization: Bearer <token> sarlavhasini qo‘shadi. API serveri JWT imzosini tekshiradi, claims ni chiqaradi va ular asosida kirish qarorini qabul qiladi — ma’lumotlar bazasiga murojaat qilmasdan.

Google Codelabs, 2025 ma’lumotlariga ko‘ra, Firebase Authentication da JWT dan foydalanish sessiya tokenlari bilan solishtirganda autentifikatsiya serveriga so‘rovlar sonini 40–60% ga kamaytiradi, chunki ma’lumotlar har bir mikroxizmatda mahalliy tekshiriladi. Bu, ayniqsa, yuqori yuklamali arxitekturalarda muhim, bu erda har bir millisekund kechikish foydalanuvchi tajribasiga ta’sir qiladi. Daqiqada 50 000 so‘rovda JWT ga o‘tish introspection so‘rovlarini qayta ishlaydigan 10 tagacha server instansiyasini tejashi mumkin.

JWT vs Session Token

JWT va Session Token bir xil vazifani hal qiladi — so‘rovlarni autentifikatsiya qilish — lekin arxitektura jihatidan tubdan farq qiladi. Session Token serverda saqlanadigan sessiya ma’lumotlariga havola qiluvchi tasodifiy identifikator satridir (stateful). JWT — barcha ma’lumotlarni o‘zida saqlaydigan o‘zini-o‘zi ta’minlovchi token (stateless).

JWT ning afzalliklari va kamchiliklari

JWT taqsimlangan tizimlarda ustunlik qiladi: mikroxizmatlar tokenni umumiy xotirasiz mahalliy tekshirishi mumkin. Masalan, beshta mikroxizmatli arxitekturada har bir xizmat JWT ni 1–2 ms da tarmoq chaqiruvisiz tekshiradi, session token esa har bir so‘rovda markazlashtirilgan Redis ga murojaat qilishni talab qiladi, 10–30 ms kechikish qo‘shadi. Biroq, JWT ni bekor qilish qiyin — agar token allaqachon chiqarilgan bo‘lsa, amal qilish muddati tugaguncha haqiqiydir. Session Token DB yoki Redis dan yozuvni o‘chirish orqali osonlikcha bekor qilinadi.

Mobil ilovalar uchun kombinatsiyalangan yondashuv — qisqa umrli (15–30 daqiqa) JWT va Refresh Token — ishlash va xavfsizlik o‘rtasida muvozanatni ta’minlaydi. JWT API ga kirish uchun ishlatiladi, refresh token (odatda opaque) esa yangi JWT larni olish uchun. JWT buzilgan taqdirda, tajovuzkor 15–30 daqiqa davomida kirish imkoniga ega; refresh token buzilgan taqdirda, sessiya rotatsiya va qayta foydalanishni aniqlash orqali bloklanadi.

JWT xavfsizligi

Xavfsizlik JWT to‘g‘ri amalga oshirishga bog‘liq. Eng keng tarqalgan zaiflik “alg none” hujumidir: tajovuzkor token headerini “alg”: “none” ga o‘zgartiradi va server algoritmni tekshirmasdan soxta tokenni qabul qiladi. Himoya: headerdagi algoritm kutilganiga (RS256, ES256) mos kelishini doimo tekshirish va alg: none bilan tokenlarni rad etish.

Odatiy zaifliklar

Zaifliklar JWT shuningdek o‘z ichiga oladi: HMAC uchun kuchsiz maxfiy kalit (daqiqalar ichida buzish), xususiy kalitning sizib chiqishi (server nomidan istalgan ma’lumotlarni imzolash), payload da maxfiy ma’lumotlarni saqlash (JWT shifrlamaydi, faqat imzolaydi), JWK header injection hujumi (o‘z ochiq kalitini kiritish). Tasdiqlangan kutubxonalardan foydalanish — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — bu zaifliklardan foydalanish xavfini kamaytiradi.

Qo‘shimcha himoya chorasi — JWK Thumbprint (RFC 7638): headerda barmoq izi (thumbprint) orqali ochiq kalitni tokenga bog‘lash. Agar server har bir mijoz uchun kutilgan thumbprint ni saqlasa, JWK header injection hujumi imkonsiz bo‘ladi — server ro‘yxatdan o‘tganga mos kelmaydigan istalgan kalitni rad etadi. OAuth Security Workshop 2025 moliyaviy va tibbiy ilovalarda ishlatiladigan barcha JWT lar uchun JWK Thumbprint ni majburiy himoya sifatida tavsiya qiladi.

Kod namunasi: Kotlin da JWT bilan ishlash

jjwt kutubxonasi (auth0/java-jwt) Android ilovasida bir necha qatorda JWT yaratish va tekshirish imkonini beradi. Quyidagi misolda server sub va role bilan token yaratadi, mijoz esa imzoni tekshiradi. Serverda maxfiy kalitni xavfsiz saqlash uchun muhit o‘zgaruvchilari yoki HSM (Hardware Security Module) dan foydalaning — kalitni kodda yoki konfiguratsiya faylida saqlash qo‘pol xavfsizlik xatosidir.

JWT yaratish

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// Tokenni mijozga yuborish
println("JWT: $token")

JWT tekshirish

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Imzo to‘g‘ri, claims chiqarildi
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}