JWT Nədir?
Veb layihələrimizi hazırlayarkən istifadəçinin identifikasiyası/avtorizasiyası çox vacibdir. Tətbiqimizi icazəsi olmayan şəxslərdən qorumaq və yalnız səlahiyyətli istifadəçilərin daxil olmasını təmin etmək təhlükəsizliyin ilkin şərtlərdəndir. Bunu təmin etməyin həll yollarından ən geniş yayılanı token istifadəsidir. Bugunki yazıda biz JSON Web Tokens ilə Avtorizasiya prosesi haqqda danışacağıq. Bu, Authentication ilə qarışdırılmamalıdır. İstifadəçinin təsdiqlənmə prosesi autentifikasiyadır. Avtorizasiya isə sistemə daxil olmaq üçün icazə nəzarətidir. Doğrulama aparıldıqdan sonra edilən hər sorğuda avtorizasiya prosesi həyata keçirilir. Təbii ki, bu, hazırladığınız tətbiqdən asılı olaraq dəyişə bilər. JSON Web Tokens(bundan sonra JWT) bir RFC7519 sənaye standartıdır. JWT istifadəçi autentifikasiyası, veb xidmət təhlükəsizliyi, informasiya təhlükəsizliyi kimi bir çox məsələlərdə istifadə edilə bilər. JWT çox məşhur və ən çox üstünlük verilən təhlükəsizlik həllərindən biridir. Əvvəlcə JWT-nin nə olduğu və hansı hissələrdən ibarət olduğu ilə bağlı məsələlərə aydınlıq gətirəcəyik. Daha sonra JWT tokenlərin yaradılması, yoxlanması kimi hissələri və nəhayət onun üstünlükləri və mənfi cəhətləri haqqında danışacağıq.
RFC7519 Nədir?
RFC 7519 "JSON Web Token (JWT)" adlı sənəddir və JSON formatında məlumatların ötürülməsi üçün standartları müəyyən edir. Bu sənəd ümumi fərziyyələri və ən yaxşı təcrübələri müəyyən edərək JWT-nin təhlükəsizliyi və istifadəsini təmin etmək üçün nəzərdə tutulmuşdur. RFC 7519-un əsas məqsədləri: JWT strukturu və formatı: Sənəd JWT-nin üç əsas komponentdən ibarət olduğunu izah edir: Header, Payload və Signature. Hər bir komponentin formatı və məzmunu ətraflı şəkildə müəyyən edilir. JWT Kodlaşdırma və Emal Qaydaları: JWT-nin Base64 URL təhlükəsiz kodlaşdırması ilə necə kodlandığı və deşifrə əməliyyatlarının necə həyata keçirildiyi bildirilir. Bundan əlavə, JWT-nin alqoritm və müddət məlumatlarını necə emal edəcəyi müəyyən edilir. JWT Təhlükəsizlik Riskləri və Tövsiyələri: Sənəddə JWT-lərin təhlükəsizlik riskləri və onlardan qorunma üsulları haqqında tövsiyələr verilir. Xüsusilə, token müddətini necə təyin etmək və JWT-də həssas məlumatların saxlanması kimi məsələlər vurğulanır.
Authorization Prosesi
Server request göndərən istifadəçinin icra etmək istədiyi əməliyyat üçün icazəsi olub-olmadığını təsdiqləməlidir. Bunun üçün login zamanı istifadəçidən gələn username və şifrənin doğruluğu databazadakı məlumatlara əsasən yoxlanılır. Əgər məlumatların doğruluğu təsdiqlənməzsə "401 Unauthorized" xətası qaytarılır. Yox, əgər təsdiqlənərsə server bizim üçün unikal bir Token generasiya edir. Yaradılmış token müvafiq istifadəçi adı altında verilənlər bazasında saxlanıla bilər. Bu, JWT-nin işləmə prinsipinə təsir göstərmir. İstifadəçi məlumatları şifrələnərək gizlədilən JWT Token Header-da Client-a qaytarılır. *Əgər parol məlumat bazasında şifrələnərək(hash) saxlanılırsa bu zaman daxil edilmiş parol da eyni hash alqoritmi ilə hashing edilir. Verilənlər bazasında saxlanılan hash daxil edilmiş parolun heşlənmiş versiyası ilə müqayisə edilir. Adətən SHA-256 və ya oxşar təhlükəsiz hash alqoritmlərindən istifadə edilir.
JWT Quruluşu
JWT ilə istehsal olunan token Base64-də kodlanmış 3 əsas hissədən ibarətdir. Bunlar Header, Payload və Signature bölmələridir. Gəlin bu hissələrə daha yaxından nəzər salaq. Aşağıdakı token nümunəsinə nəzər yetirək
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1laWRlbnRpZmllciI6ImFlMDZmN2E3LTk3ZWItNDEyYS1iZGU0LTgxNzhkYTVmYzc5MyIsIm5iZiI6MTcwOTM3NjE4NSwiZXhwIjoxNzA5NDYyNTg1LCJpc3MiOiJodHRwczovL2xvY2FsaG9zdCIsImF1ZCI6Imh0dHBzOi8vbG9jYWxob3N0In0.u43NhlXpXTI0y3O6d3Y7eZuWed8gVB7SoUN8crcdk4w
Header
JWT-nin Header hissəsi tokeni şifrələmək əməliyyatını müəyyən edən məlumatları ehtiva edir. Bu başlıqların nə olduğu və nə etdikləri haqqında daha ətraflı: - alg (Alqoritm): Bu, JWT-ni şifrələmək üçün istifadə olunan alqoritmi təyin edir. "HS256" alqoritmi HMAC-SHA256 alqoritminə istinad edir. Digər məşhur alqoritmlərə "RS256" (SHA-256 ilə RSA), "ES256" (SHA-256 ilə ECDSA) daxildir. Bu hissə JWT-nin təhlükəsizliyi üçün vacibdir; çünki düzgün alqoritmin seçilməsi tokenin təhlükəsizliyini təmin edir. - typ (Növ): Bu, JWT növünü təyin edir. Növü adətən "JWT" kimi göstərilir və onun JWT olduğunu bildirir. Bu hissə JWT-nin struktur tərəfini təmin edir. - cty (Məzmun növü): Bu, JWT məzmununun növünü təyin edir. JWT məzmunu JSON formatında olduğundan ona çox vaxt "JWT" deyilir. Bu hissə JWT məzmununun düzgün işlənməsini təmin edir. Bu başlıqlar JWT-nin düzgün yaradılması, işlənməsi və təsdiqlənməsi üçün vacibdir. Məsələn, yoxlama prosesi zamanı göstərilən alqoritmdən istifadə edilməli və başlıqlar yoxlanılmalıdır. Bu yolla, tokenin təhlükəsizliyi təmin edilir və etibarlı autentifikasiya mexanizmi yaradılır.
{
"alg": "HS256",
"typ": "JWT",
"cty": "JWT"
}
Payload
Bu hissə ilə bağlı məlumat geniş ola bilər. Ancaq ən vacib hissənin da bu olduğunu qeyd etməyimdə fayda var. Aşağıda gördüyünüz məlumatlar JWT-nin Payload hissəsini təmsil edir. Payload JWT hissələrinin nə olduğu və nə etdikləri haqqında daha çox daşınan məlumatı özündə saxlayır. Bu bölmədə "claim"-lar var. Client və server arasında daşınan bu məlumatlar və token unikal olur. Claim məlumatları da bu unikallığı təmin edir.
{
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "ae06f7a7-97eb-412a-bde4-8178da5fc793",
"nbf": 1709376185,
"exp": 1709462585,
"iss": "https://example",
"aud": "https://example"
}
Payload məlumatları
Bu məlumatlar üç kateqoriyada qruplaşdırıla bilər: Registered Claims: Bunlar məcburi olmayan, lakin tövsiyə olunan əvvəlcədən təyin edilmiş claim-lardır. Adətən müəyyən mənaya malik 3 hərf uzunluğunda (və ya daha qısa) olur. Onlardan bəziləri : iss (emitent), exp (bitmə vaxtı), sub (mövzu), aud (auditoriya) . Bu sahələr JWT-nin xüsusi funksiyalarını yerinə yetirmək üçün istifadə olunur və digər claim-larda eyni adla istifadə edilə bilməz. Public Claims: JWT daxilində daşınan məlumatların könüllü və açıq şəkildə dərc edilən claim-lardır. Məsələn, "name", "mail", "rol". Bu hissə JWT-nin məzmununu zənginləşdirmək və ya xüsusi sorğulara cavab olaraq əlavə məlumat vermək üçün istifadə edilə bilər. Private Claims: JWT daxilində daşınan və yalnız müəyyən tərəflər arasında şəxsi məlumatların ötürülməsi üçün istifadə edilən məxfi claim-lardır. Bu cür məlumat JWT-ni yaradan və ya istifadə edəcək tərəflər arasında şəxsi məlumat mübadiləsi üçün istifadə olunur.
Registered Claims
- nbf (Başlama vaxtı): JWT-nin nə vaxt etibarlı olacağını müəyyənləşdirir. Bununla belə, bu vaxt adətən tarix və vaxt formatı deyil, UNIX vaxt damğası kimi ifadə edilir.Bu, UNIX zaman damğasında (epox) dəyərdir. Token bu tarixdən əvvəl istifadə edilə bilməz. Məsələn, nbf sahəsinin 1709376185 kimi dəyəri varsa, bu, UNIX vaxt damğasında xüsusi tarix və saat qurşağını təmsil edir. UNIX vaxt damgası 1970-01-01 00:00:00 UTC (Koordinasiya edilmiş Universal Saat) tarixindən bu yana keçən saniyələrin sayını təmsil edir. Bu, zamanın ədədi təmsilidir və adətən saniyələrlə ifadə edilir. UNIX vaxt damğası kompüter sistemlərində vaxtı təmsil etmək üçün geniş istifadə olunur, çünki o, UTC-yə nisbətən sabit istinad nöqtəsidir və saat qurşağından təsirlənmir. Buna görə də, hətta müxtəlif vaxt qurşaqlarında eyni vaxt damğası eyni vaxtda baş vermiş vaxta uyğun gəlir. - exp (Bitmə vaxtı): Expiration Time JWT-nin nə vaxt etibarsız olduğunu müəyyən edir. Bu sahə nişanın nə vaxt bitəcəyini göstərir və vaxt qurşaqlarından müstəqil və UTC vaxt qurşağına nisbətən sabit olan UNIX vaxt damğası formatında dəyərdir."exp" Hissəsində 1709462585 kimi bir dəyər varsa, bu, UNIX vaxt damğasında xüsusi tarix və saat qurşağını təmsil edir və tokenin müəyyən bir tarixdən sonra istifadə edilə bilməyəcəyini müəyyən edərək JWT-nin təhlükəsizliyini artırır. Bu, tokenin ömrünü məhdudlaşdırır və arzuolunmaz girişdən qoruyur. Məsələn, JWT-nin müddəti bitdikdə, bu o deməkdir ki, token artıq istifadə oluna bilməz və sistem həmin tokeni rədd edir. - sub (Mövzu): Bu sahə JWT tərəfindən ötürülən məlumatın mövzusunu təmsil edir. Tipik olaraq, bu sahə JWT sahibinin unikal ID və ya identifikatorunu ehtiva edir. Məsələn, bu istifadəçinin identifikatoru və ya obyektin unikal identifikatoru ola bilər. "sub" (Subject) adətəm "Public (Açıq)" və ya "Private (Gizli)" claim növündə istifadə oluna bilər - iss (Emitent): Emitent sahəsi JWT-ni kimin yaratdığını (imzaladığını) göstərir. Beləliklə, bu hissə JWT-nin mənbəyini göstərir. JWT-ni yoxlamaq istəyən sistem və ya clien JWT-ni hansı emitentin yaratdığını yoxlamaq üçün bu hissədən istifadə edir. Bu sahənin istifadəsi JWT-nin etibarlılığını təmin etmək üçün vacibdir, çünki JWT-ni yaradan tərəfin etibarlılığı tokenin etibarlılığı üçün əsasdır. Məsələn, veb proqram tərəfindən yaradılan JWT-lərin "isp" sahəsində həmin proqramın URL-i ola bilər. Bu, JWT-dən istifadə etməyə cəhd edən müştərinin JWT-nin düzgün qurulduğuna əmin olmasını təmin edir. JWT-ni yaradan tərəf xüsusi ID-ni təmsil edirsə, "isp" sahəsində ID də ola bilər. Məsələn, OAuth 2.0 provayderi tərəfindən yaradılan JWT-lərdə "isp" sahəsi adətən provayderin ID-sini (provayderin URL-i) ehtiva edir. Nəticə etibarilə, "isp" sahəsi JWT-nin etibarlılığını təmin etmək üçün istifadə olunur və JWT-ni yaradan tərəfin kimliyini və yaxud mənbəyini göstərir. Bu, JWT-nin təsdiqində və təhlükəsizliyində mühüm rol oynayır. - aud (Audience): Bu sahə JWT-nin hədəf auditoriyasını müəyyən edir. Yəni hansı sistem və ya xidmətin bu tokendən istifadə edəcəyini göstərərək hədəf alıcısını təyin edir. Bu hissə JWT üçün müəyyən bir məqsədə xidmət etmək üçün nəzərdə tutulmuşdur. Məsələn, JWT xüsusi veb xidməti tərəfindən istifadə edilməlidirsə, "aud" sahəsində həmin veb xidmətin URL və ya ID-si ola bilər. Bu, JWT-nin yalnız xüsusi xidmət və ya sistem tərəfindən qəbul edilməsini təmin edir və onun digər xidmətlər və ya sistemlər tərəfindən rədd edilməsinin qarşısını alır. JWT-nin həmin istifadəçi və ya qrup tərəfindən istifadə edilməsi nəzərdə tutulursa, "aud" sahəsində konkret istifadəçi və ya qrupun ID-si də ola bilər. Məsələn, OAuth 2.0-da, əgər JWT müəyyən bir müştəri tərəfindən istifadə edilməlidirsə, "aud" sahəsində adətən müştərinin ID-si olur. Nəticədə, "aud" sahəsi JWT-dən hansı sistemin və ya xidmətin istifadə edəcəyini müəyyənləşdirir və JWT-nin düzgün hədəflənməsini təmin edir. Bu, JWT-nin təhlükəsizliyini artırır və sui-istifadənin qarşısını alır.
Public Claims
JWT-nin məqsədinin müəyyən edilməsi, autentifikasiya, icazənin verilməsi və ya profil məlumatı kimi ümumi istifadə edilən məlumatlar barəsində daha ətraflı danışaq. name: Bu, istifadəçinin adını ehtiva edən claim ola bilər. Məsələn, "Khanim Gurbanli". email: Bu, istifadəçinin e-poçt ünvanını ehtiva edən claim ola bilər. Məsələn, "info@khanimgurbanli.com". rol: Bu istifadəçinin rolunu və ya səlahiyyətlərini göstərən claim ola bilər. Məsələn, "admin", "istifadəçi". username: Bu, istifadəçinin istifadəçi adını ehtiva edən claim ola bilər. Məsələn, "johndoe". picture: Bu, istifadəçinin profil şəklini ehtiva edən claim ola bilər. Məsələn, bir URL. locale: Bu, istifadəçinin üstünlük verdiyi dil və region parametrlərini ehtiva edən claim ola bilər. Məsələn, "en-US". birthdate: Bu, istifadəçinin doğum tarixini ehtiva edən claim ola bilər. phone_number: Bu istifadəçinin telefon nömrəsini ehtiva edən claim ola bilər. Bu nümunələr JWT daxilində həyata keçirilə bilən "Public Claims"ın ümumi nümunələrini göstərir. Bu cür məlumatlar fərdiləşdirilə bilər və JWT-nin istifadə olunacağı ssenari və tələblərə əsasən əlavə məlumatlar da əlavə edilə bilər.
Private Claims
company_role: Bu, istifadəçinin şirkətdəki rolunu göstərən claim ola bilər. Məsələn, "menecer", "işçi". user_preferences: Bu, istifadəçinin seçimlərini ehtiva edən claim ola bilər. Məsələn, mövzu rəngi, bildiriş seçimləri və s. session_data: İstifadəçinin sessiyası ilə əlaqəli şəxsi məlumatları ehtiva edən claim ola bilər. Məsələn, sessiya müddəti, sessiya ID və s. subscription_status: Bu, istifadəçinin abunə statusunu ehtiva edən claim ola bilər. Məsələn, "aktiv", "müddəti bitmiş". user_settings: Bu, istifadəçinin proqram parametrlərini ehtiva edən claim ola bilər. Məsələn, dil seçimi, saat qurşağı parametrləri və s. Bu nümunələr JWT daxilində həyata keçirilə bilən "Private Claim" nümunələrini göstərir. Bu tip məlumat JWT-ni xüsusi proqram və ya ssenari üçün fərdiləşdirməyə imkan verir və JWT-nin müəyyən bir məqsədə xidmət etməsinə imkan verir.
Signature
JWT-nin imzalanmış hissəsi tokenin bütövlüyünü və həqiqiliyini təmin etmək üçün istifadə olunur. İmza xüsusi açar və imzalama alqoritmindən istifadə edərək Header və Payload hissələrinin işlənməsi ilə yaradılır. İmza HMAC və ya rəqəmsal Signature alqoritmindən istifadə edərək Header və Payload məlumatlarını birləşdirərək və sonra onu xüsusi açarla emal etməklə əldə edilir. Bu proses JWT yaratmaq üçün istifadə olunan alqoritmi müəyyən edir. Məsələn, HS256 alqoritmi HMAC-SHA256-dan, RS256 alqoritmi isə SHA-256 ilə RSA-dan istifadə edir.
JWT Doğrulama
JWT yoxlama prosesi olduqca sadədir və aşağıdakı addımlardan ibarətdir: Token qəbulu: Client adətən autentifikasiya sorğusuna cavab olaraq JWT alır. Bu JWT istifadəçinin sessiyasını yoxlamaq üçün sübut kimi istifadə olunur. Header və Payload Signature : Server təhlükəsiz açardan istifadə edərək aldığı JWT-ni imzalayır. İmzalanma prosesi JWT-nin bütövlüyünü və etibarlılığını təmin edir. Header və Payload bölmələri məlumatların məzmununu daşısa da, Signature məlumatların dəyişdirilməməsini təmin edir. Signature Doğrulaması: Server Signature alqoritmi ilə eyni açardan istifadə edərək Header və Payload məlumatlarını emal edir və sonra bu işlənmiş məlumatları müqayisə edir. Müqayisə uğurlu olarsa, JWT-nin düzgünlüyü, dəyişdirilmədiyi və etibarlı mənbədən gəldiyi təsdiqlənir. İstifadə müddətinin yoxlanması: Server JWT-nin bitmə tarixini (exp) yoxlayır. Bu tarix keçibsə, JWT etibarsız sayılır və girişə icazə verilmir. Bu, JWT-nin müəyyən bir müddət üçün məhdudlaşdırılmasını təmin edir və təhlükəsizliyi artırır. Access: JWT-nin imzası təsdiqlənibsə və onun son istifadə müddəti bitməyibsə, client-a giriş icazəsi verilir. Client JWT-ni yoxlayır və autentifikasiya prosesini tamamlanır.
JWT Üstünlükləri
Təhlükəsizlik: JWT daşıdığı məlumatı imzalayaraq təhlükəsizliyi təmin edir. Beləliklə, məlumatların bütövlüyü qorunur və məlumatların düzgünlüyünə zəmanət verilir. Əlavə olaraq, JWT-lər HTTPS protokolu ilə göndərildikdə, rabitə kanalı da təhlükəsizdir. Stateless: Server və ya client tərəfində sessiya izləmir. Bu, server tərəfində sessiyanın idarə edilməsi üçün tələb olunan resursları azaldır və miqyaslılığı artırır. Tokendə sadəcə lazımi məlumatları daşıdığı üçün server performansını artırır. Portativ Əməliyyat: JWT birdən çox backend ilə işləməyə uyğundur və təkcə veb proqramlar arasında deyil, həm də mobil proqramlar və digər sistemlərlə inteqrasiya etmək asandır. Bu, müxtəlif platformalar və fərqli texnologiyalar arasında məlumat mübadiləsinə imkan verir. JSON Format: JWT JSON (JavaScript Object Notation) formatından istifadə edir ki, bu da məlumatları oxunaqlı və asanlıqla manipulyasiya etməyə imkan verir. JSON formatı müasir veb proqramlar üçün standart məlumat mübadiləsi formatıdır. Sürətli Doğrulama: JWT-lər ehtiva etdikləri məlumatlarla birlikdə imzalandığı üçün yoxlama prosesi sürətlidir. Digər avtorizasiya üsulları ilə müqayisədə verilənlər bazası sorğularına və ya xarici resurslara girişə ehtiyac yoxdur, bu da yoxlama prosesini sürətləndirir. Cookie istifadə etməyə ehtiyac yoxdur: JWT brauzer kukilərindən istifadə etmir, ona görə də kuki ölçüsündə məhdudiyyətlər və ya kukilərin təhlükəsizlik riskləri kimi problemlər yoxdur. Bu xüsusiyyət JWT-dən mobil proqramlar üçün də istifadə etməyi asanlaşdırır və brauzer əsaslı olmayan proqramlarda da istifadə edilə bilər. Fərdiləşdiriləşdirmə: JWT istifadəçilərin və ya tətbiqlərin ehtiyaclarına uyğun olaraq fərdiləşdirilə bilər. İstədiyiniz məlumatı əlavə etmək və ya silməklə müxtəlif ssenarilərə uyğunlaşdırıla bilİr.
Saxlanması
JWT-ləri harada saxlamağımız istifadə ssenarinizdən və təhlükəsizlik tələblərimizdən asılıdır. Daha ətraflı: HTTP Başlık (HTTP Headers): JWT-ni HTTP sorğularının Header hissəsində daşıya bilərsiniz (məsələn, Avtorizasiya başlığı altında). Bu, JWT-nin hər sorğu ilə göndərilməsini təmin edir və təhlükəsiz əlaqəni təmin edir. Browser Memory: JWT-ni brauzer yaddaşında saxlaya bilərsiniz. Bu, JWT-nin brauzerin yaddaşında təhlükəsiz saxlanmasını təmin edir. Bununla belə, bu üsul saytlararası skript (XSS) hücumlarına qarşı həssas ola bilər. Browser Storage: JWT-ni localstorage və ya Session kimi brauzer saxlama mexanizmlərində saxlaya bilərsiniz. Bununla belə, bu üsul kuki əsaslı avtorizasiya ilə eyni təhlükəsizlik risklərini daşıyır və saytlararası sorğu saxtakarlığı (CSRF) hücumlarına qarşı həssasdır. HTTP Only Cookies: JWT-ni yalnız HTTP kukiləri vasitəsilə saxlaya bilərsiniz. Bu, XSS hücumlarına qarşı daha çox qorunur, çünki JavaScript kodu bu kukilərə daxil ola bilmir. Bununla belə, hələ də CSRF hücumlarına qarşı həssas sayılır. Server Memory: JWT-ni server yaddaşında saxlamaq da bir seçimdir. Bununla belə, bu, Scalability(miqyaslanma) problemlərinə səbəb ola bilər və server yenidən işə salındıqda JWT-lər itirilə bilər. Verilənlər bazası: JWT-nin verilənlər bazasında saxlanması tutarlı bir həll təklif edə bilər. Bununla belə, bu, hər sorğuda verilənlər bazasına giriş tələb edir və performansa təsir edə bilər. Seçdiyiniz saxlama mexanizmi təhlükəsizlik, performans və istifadə rahatlığı kimi amillərdən asılı olmalıdır. Əhəmiyyətli olan odur ki, JWT avtorizasiya prosesində təhlükəsiz şəkildə istifadə edilsin və lazımi təhlükəsizlik tədbirləri görülsün.
Diqqət
Algortim: Server və client arasında istifadə olunan alqoritm JWT-nin doğrulanması üçün uyğun şəkildə imzalanmalıdır. Fərqli algoritlər istifadə edildikdə doğrulama uğursuz ola bilər. Vaxt Sinxronizasiyası: JWT-də müəyyən vaxt ştampları server və client arasında düzgün sinxronlaşdırılmalıdır. Saatlar arasındakı kiçik fərqlər JWT-nin etibarlılığını şübhə altına ala bilər. Məlumatların Bütövlüyü: JWT-nin Payload və ya Header bölmələrinə edilən düzəlişlər imzanın yoxlanılmasında uğursuzluğa səbəb ola bilər və ya məlumatların bütövlüyünü poza bilər. Bu səbəbdən JWT-ni təhlükəsiz ötürmək üçün HTTPS kimi təhlükəsiz protokollardan istifadə edilməlidir. Yoxlama və Avtorizasiya: JWT-nin yoxlama və icazə proseslərinin uyğunsuzluğu sistemdə icazə və ya etibarsızlıq problemləri ilə nəticələnə bilər. Bu səbəbdən, JWT əsaslı sistemlərdə yoxlama və icazə prosesləri diqqətlə dizayn edilməlidir.