Stateless vs. Stateful: JWT-ni Necə Düzgün İdarə Etməli?

Müasir proqram təminatı arxitekturasında autentifikasiya modelinin seçimi sadəcə bir proqramlaşdırma üstünlüyü deyil, həm də kritik bir təhlükəsizlik qərarıdır. Bu yazıda JSON Web Token (JWT) texnologiyasının mühəndislik kompromislərini (trade-offs) və müasir standartlara (RFC 7519, OAuth 2.1) əsaslanan idarəetmə prinsiplərini təhlil edəcəyik.

1. Autentifikasiyanın Fizikası: Reference vs. Value

Autentifikasiya mexanizmlərini iki fundamental kateqoriyaya bölmək olar:

• Stateful (Reference): Bu modeldə token sadəcə bir "istinad" (pointer) rolunu oynayır. Server sessiya məlumatlarını mərkəzi bir yaddaşda (Database/Redis) saxlayır və hər sorğuda bu məlumatı yoxlayır. Nəzarət tamamilə server tərəfdədir.
• Stateless (Value): JWT bu kateqoriyaya aiddir. Məlumat (Claims) tokenin daxilində daşınır. Server sessiya vəziyyətini (state) yaddaşda saxlamır, sadəcə gələn məlumatın kriptoqrafik imzasını yoxlayır.

1. Stateless Paradoksu və Ləğvetmə (Revocation) Problemi

JWT-nin ən böyük üstünlüyü olan "Stateless" təbiəti, eyni zamanda onun ən zəif nöqtəsidir. Bir token imzalanıb müştəriyə verildikdən sonra, onun server tərəfindən dərhal ləğv edilməsi (revocation) texniki olaraq mümkün deyil.

Əgər tətbiqinizdə hər sorğu zamanı "Blacklist" yoxlanışı aparılırsa, bu artıq tam stateless model deyil. Bu halda sistem hibrid vəziyyətə keçir: autentifikasiya üçün JWT, avtorizasiya və ləğvetmə üçün isə stateful mühit istifadə olunur. Banking və FinTech kimi dərhal bloklamanın kritik olduğu sahələrdə sessiya əsaslı (Stateful) model hələ də daha etibarlı sayılır.

1. Müasir Standartlar: OAuth 2.1 və PKCE

Təhlükəsizlik standartları son illərdə ciddi şəkildə yenilənmişdir. Slaydlarda da qeyd olunduğu kimi, köhnə metodlar artıq təhlükəsizlik riski hesab olunur:

• Implicit Grant (Deprecated): Tokenin URL vasitəsilə ötürülməsi brauzer tarixçəsində sızma riskini artırdığı üçün artıq istifadə edilməməlidir.
• PKCE (Proof Key for Code Exchange): Əvvəllər yalnız mobil tətbiqlər üçün nəzərdə tutulsa da, OAuth 2.1 ilə artıq bütün "public" və "confidential" müştərilər üçün məcburidir. Bu, Code Injection hücumlarının qarşısını alan təməl müdafiə mexanizmidir.

1. Təhlükəsizlik Arxitekturası: Refresh Token Rotation

Access Token-lərin ömrü (exp) riskləri azaltmaq üçün qısa tutulmalıdır (məsələn, 10 dəqiqə). Lakin Refresh Token-lərin oğurlanması daha böyük təhlükə yaradır. Bunun qarşısını almaq üçün Refresh Token Rotation tətbiq edilməlidir.

Hər dəfə yeni Access Token tələb olunduqda, köhnə Refresh Token ləğv edilməli və müştəriyə yeni bir Refresh Token verilməlidir. Əgər sistem eyni Refresh Token-in iki dəfə istifadə olunmağa çalışıldığını görərsə, bu bir anomaliya (oğurluq cəhdi) kimi qiymətləndirilməli və həmin istifadəçinin bütün aktiv seansları dərhal ləğv edilməlidir.

Checklist:

Layihənizi canlı mühitə buraxmazdan əvvəl bu kritik təhlükəsizlik nöqtələrini yoxlayın:

1. Alqoritm Bloklanması: alg: none başlığı server tərəfində qəti şəkildə bloklanıbmı?
2. Payload Məxfiliyi: Payload hissəsində şifrələnməmiş PII (fərdi məlumatlar) və ya həssas informasiya varmı?
3. Signature Verification: İstifadə olunan kitabxana hər sorğuda imzanı (signature) dürüst şəkildə yoxlayırmı?
4. Redirect URI Match: OAuth 2.1-ə əsasən, redirect URI-lar üçün "exact match" (tam uyğunluq) tələb olunurmu?
5. Secure Transmission: Tokenlər yalnız HTTPS üzərindən və HttpOnly cookie-lər daxilində ötürülürmü?

Nəticə

JWT bir arxitektura həlli deyil, bir məlumat ötürmə formatıdır. Onun "Stateless" olması miqyaslanma üçün böyük üstünlükdür, lakin təhlükəsizlik idarəetməsi mühəndis tərəfindən düzgün dizayn edilməlidir. Layihənizin ehtiyaclarına uyğun olaraq sessiya idarəetməsini seçin və müasir OAuth 2.1 protokollarından kənara çıxmayın.