JWT: bu nədir, JSON Web Token strukturu və istifadəsi

JWT nədir?

JSON Web Token (JWT) — bu, tərəflər arasında məlumatların JSON obyekti şəklində ötürülməsi üçün kompakt və özünü təmin edən üsulu müəyyən edən açıq standartdır (RFC 7519). JWT-də olan məlumat claims adlanır — subyekt (istifadəçi) və əlavə atributlar haqqında təsdiqlər. Hər claim açar-dəyər cütüdür: istifadəçi identifikatoru, rol, bitmə müddəti, verən.

JWT özünü təmin edən adlanır, çünki yoxlama üçün bütün məlumat tokenin öz daxilindədir. Server tokenin etibarlılığına əmin olmaq üçün verilənlər bazasına və ya xarici yaddaşa müraciət etməli deyil — imzanı yoxlamaq kifayətdir. Bu xüsusiyyət JWT-ni paylanmış sistemlər və bir neçə xidmətin ümumi sessiya yaddaşı olmadan sorğuları autentifikasiya etməli olduğu mikroxidmət arxitekturası üçün ideal edir.

Auth0, 2025 məlumatlarına görə, mobil və veb tətbiqlərin 65%-dən çoxu API autentifikasiyası üçün əsas token formatı kimi JWT-dən istifadə edir, qeyri-şəffaf tokenləri (opaque tokens) və sessiya identifikatorlarını qabaqlayır.

JWT strukturu: header, payload və signature

JWT nöqtələrlə ayrılmış üç hissədən ibarətdir: header.payload.signature. Hər hissə Base64url ilə kodlanmış JSON-dur. Hər hissəyə ətraflı baxaq.

Header — alqoritm və token növü

Header iki məcburi sahə ehtiva edir: alg (algorithm — imza alqoritmi) və typ (type — token növü, həmişə “JWT”). Alqoritm simmetrik (HS256 — HMAC SHA-256 ilə) və ya asimmetrik (RS256 — RSA SHA-256 ilə, ES256 — ECDSA P-256 ilə) ola bilər. Asimmetrik alqoritmlər daha üstündür, çünki müştəriyə gizli açarı bilmədən imzanı yoxlamağa imkan verir.

Dekodlanmış header nümunəsi:

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

Payload — claims və məlumatlar

Payload claims — subyekt haqqında təsdiqləri ehtiva edir. Claims üç növə bölünür: qeydiyyatdan keçmiş (iss, sub, aud, exp, nbf, iat, jti), ictimai (IANA Registry-də tərtibatçı tərəfindən müəyyən edilən) və özəl (tərəflər arasında razılaşdırılmış). sub (subject) — istifadəçinin unikal identifikatoru. exp (expiration) — tokenin bitmə vaxtı. iss (issuer) — tokeni verən.

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

Signature — bütövlüyün yoxlanması

Signature gizli və ya özəl açardan istifadə edərək header və payload-ın birləşməsinə imza alqoritminin tətbiqi ilə yaradılır. Formula: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) HMAC üçün, və ya RSASHA256(...) asimmetrik alqoritm üçün. Qəbul edən eyni üsulla imzanı hesablayır və alınanla müqayisə edir — uyğun gələrsə, məlumatlar dəyişdirilməyib.

JWT necə işləyir: yaradılma və yoxlama

İşləmə prosesi JWT iki mərhələdən ibarətdir: autentifikasiya serveri tərəfindən tokenin yaradılması (buraxılması) və müştəri və ya resurs serveri tərəfindən tokenin yoxlanması. Autentifikasiya serveri istifadəçinin məlumatlarını alır, claims ilə payload yaradır və imzalayır. Yaranan JWT müştəriyə giriş sorğusuna cavab olaraq və ya OAuth 2.0 / OpenID Connect cavabının gövdəsində göndərilir.

Mobil autentifikasiyada JWT

Mobil tətbiqlərdə JWT aşağıdakı şəkildə istifadə olunur: uğurlu girişdən sonra istifadəçi JWT formatında access token alır. Tətbiq onu təhlükəsiz yaddaşda saxlayır (iOS-da Keychain, Android-də EncryptedSharedPreferences). Hər API sorğusunda tətbiq Authorization: Bearer <token> başlığını əlavə edir. API serveri JWT imzasını yoxlayır, claims çıxarır və onların əsasında giriş qərarı verir — verilənlər bazasına müraciət etmədən.

Google Codelabs, 2025 məlumatlarına görə, Firebase Authentication-da JWT istifadəsi sessiya tokenləri ilə müqayisədə autentifikasiya serverinə sorğuların sayını 40–60% azaldır, çünki məlumatlar hər mikroxidmətdə lokal olaraq yoxlanılır. Bu, xüsusilə yüksək yüklü arxitekturalarda vacibdir, burada hər millisaniyə gecikmə istifadəçi təcrübəsinə təsir edir. Dəqiqədə 50 000 sorğuda JWT-yə keçid introspection sorğularını emal edən 10 server instansiyasına qədər qənaət edə bilər.

JWT vs Session Token

JWT və Session Token eyni vəzifəni həll edir — sorğuların autentifikasiyası — lakin arxitektura baxımından prinsipial fərqlənir. Session Token serverdə saxlanılan sessiya məlumatlarına istinad edən təsadüfi identifikator sətridir (stateful). JWT — bütün məlumatları özündə saxlayan özünü təmin edən tokendir (stateless).

JWT-nin üstünlükləri və çatışmazlıqları

JWT paylanmış sistemlərdə üstündür: mikroxidmətlər tokeni ortaq yaddaş olmadan lokal olaraq yoxlaya bilər. Məsələn, beş mikroxidmətli arxitekturada hər xidmət JWT-ni 1–2 ms-də şəbəkə çağırışı olmadan yoxlayır, halbuki session token hər sorğuda mərkəzləşdirilmiş Redis-ə müraciət tələb edir, 10–30 ms gecikmə əlavə edir. Lakin JWT-ni ləğv etmək çətindir — token artıq buraxılıbsa, bitmə müddətinə qədər etibarlıdır. Session Token-i DB və ya Redis-dən qeydi silməklə asanlıqla ləğv etmək olar.

Mobil tətbiqlər üçün kombinə edilmiş yanaşma — qısa ömürlü (15–30 dəqiqə) JWT və Refresh Token — performans və təhlükəsizlik arasında tarazlıq verir. JWT API-ə giriş üçün istifadə olunur, refresh token (adətən opaque) isə yeni JWT-lər əldə etmək üçün. JWT kompromizasiyası halında təcavüzkarın 15–30 dəqiqə girişi olur; refresh token kompromizasiyası halında sessiya rotation və təkrar istifadə aşkarlanması vasitəsilə bloklanır.

JWT təhlükəsizliyi

Təhlükəsizlik JWT düzgün tətbiqdən asılıdır. Ən geniş yayılmış zəiflik “alg none” hücumudur: təcavüzkar tokenin header-ni “alg”: “none” olaraq dəyişir və server alqoritmi yoxlamadan saxta tokeni qəbul edir. Qorunma: header-dəki alqoritmin gözlənilənə (RS256, ES256) uyğun olduğunu həmişə yoxlamaq və alg: none olan tokenləri rədd etmək.

Tipik zəifliklər

Zəifliklər JWT həmçinin daxildir: HMAC üçün zəif gizli açar (dəqiqələr ərzində sındırma), özəl açarın sızması (server adından istənilən məlumatı imzalamaq), payload-da həssas məlumatların saxlanması (JWT şifrələmir, yalnız imzalayır), JWK header injection hücumu (öz ictimai açarının daxil edilməsi). Etibarlı kitabxanaların istifadəsi — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — bu zəifliklərin istismar riskini azaldır.

Əlavə qorunma tədbiri — JWK Thumbprint (RFC 7638): header-də barmaq izi (thumbprint) vasitəsilə ictimai açarın tokenə bağlanması. Server hər müştəri üçün gözlənilən thumbprint saxlayırsa, JWK header injection hücumu qeyri-mümkün olur — server qeydiyyatdan keçmişlə uyğun gəlməyən istənilən açarı rədd edir. OAuth Security Workshop 2025, maliyyə və tibbi tətbiqlərdə istifadə olunan bütün JWT-lər üçün JWK Thumbprint-i məcburi qorunma kimi tövsiyə edir.

Kod nümunəsi: Kotlin-də JWT ilə iş

jjwt kitabxanası (auth0/java-jwt) Android tətbiqində bir neçə sətirdə JWT yaratmağa və yoxlamağa imkan verir. Aşağıdakı nümunədə server sub və role ilə token yaradır, müştəri isə imzanı yoxlayır. Serverdə gizli açarın təhlükəsiz saxlanması üçün mühit dəyişənləri və ya HSM (Hardware Security Module) istifadə edin — açarın kodda və ya konfiqurasiya faylında saxlanması kobud təhlükəsizlik səhvdir.

JWT generasiyası

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))

// Tokenin müştəriyə göndərilməsi
println("JWT: $token")

JWT yoxlanması

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // İmza düzgündür, claims çıxarıldı
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}