امنیت یک سیستم احراز هویت، همیشه به اندازه ضعیفترین حلقهاش است. JSON Web Token یا همان JWT، در سالهای اخیر به یکی از پرکاربردترین مکانیزمهای انتقال اطلاعات هویتی تبدیل شده — اما همین محبوبیت، آن را به یکی از پرخطاترین نقاط در معماریهای احراز هویت نیز کرده است.
بهترین شیوههای استفاده امن از JWT تنها یک سری توصیه عمومی نیستند. هر کدام پاسخ مستقیمی به یک آسیبپذیری شناختهشدهاند که در گذشته موجب نقض امنیتی واقعی شده. اگر JWT را در سیستم خود استفاده میکنید — چه برای API authentication، چه برای SSO، چه برای مبادله اطلاعات بین سرویسها — این مقاله چارچوبی عملیاتی برای کاهش ریسک ارائه میدهد.
حتما بخوانید
برای درک عمیقتر رابطه JWT با استانداردهای احراز هویت و معماری کلی سیستمهای مدیریت هویت، راهنمای جامع مدیریت هویت و دسترسی (IAM) میتواند بسیار مفید باشد — این مرجع، تصویر کاملی از اکوسیستم IAM و جایگاه هر ابزار در آن ارائه میدهد.
JWT چیست و چرا اینقدر رایج شد؟
JWT یک استاندارد باز (RFC 7519) است که روشی فشرده و قابل حمل برای انتقال claims بین طرفین تعریف میکند. این توکنها میل یک رشته قده (JWS) یا رمزگذاریشده (JWE) باشند و اطلاعات را به شکل یک رشته قابل بررسی حمل کنند.
دلیل محبوبیت JWT در چند خصوصیت ساختاری خلاصه میشود: stateless است، نیازی به نگهداری session در سمت سرور ندارد، بهراحتی در هدر HTTP جا میشود و میتوان آن را بین دامنههای مختلف منتقل کرد. این ویژگیها برای معماریهای microservice و اپلیکیشنهای Single Page Application (SPA) بسیار جذاب بودند.
اما همین خصوصیات، یک سری چالش امنیتی جدی هم ایجاد میکنند که در ادامه به تفصیل بررسی میشوند.
ساختار سهبخشی JWT
یک JWT از سه بخش با نقطه جدا میشود: Header، Payload و Signature.
بخش Header الگوریتم امضا و نوع توکن را مشخص میکند. بخش Payload شامل claims است — اطلاعاتی مانند شناسه کاربر، نقشها، تاریخ انقضا و هر داده سفارشی دیگری. بخش Signature نتیجه اعمال الگوریتم رمزنگاری روی دو بخش قبل با استفاده از یک کلید مخفی یا کلید خصوصی است.
نکته مهمی که اغلب اشتباه فهمیده میشود: JWT بهصورت پیشفرض رمزگذاری نیست، فقط امضاشده است. هر کسی میتواند payload یک JWT را بخواند — فقط نمیتواند آن را بدون شناسایی تغییر دهد. این تفاوت اساسی است.
انواع Claims
Claims در JWT به سه دسته تقسیم میشوند. Registered Claims مانند iss (صادرکننده)، sub (موضوع)، exp (انقضا) و aud (مخاطب) استانداردشده هستند. Public Claims باید در IANA JWT Claims Registry ثبت شوند تا از تداخل جلوگیری شود. Private Claims توافقی بین طرفین هستند و ساختار آزادتری دارند.
ریسکهای امنیتی شناختهشده JWT
درک ریسکها پیش از بررسی راهکارها، ضروری است. بسیاری از آسیبپذیریهای JWT نه از ضعف در استاندارد، بلکه از پیادهسازی نادرست ناشی میشوند.
حمله Algorithm Confusion (None Algorithm Attack)
یکی از خطرناکترین آسیبپذیریهای تاریخی JWT، امکان تنظیم مقدار alg در header به none بود. در کتابخانههای قدیمیتر، برخی پیادهسازیها این توکن را بدون هیچ بررسی امضایی میپذیرفتند — به این معنا که مهاجم میتوانست claims دلخواهی مانند “role”: “admin” بنویسد و سیستم آن را معتبر تلقی کند.
حمله RS256 به HS256
این حمله ظریفتر اما به همان اندازه خطرناک است. اگر سرور هم RS256 و هم HS256 را بپذیرد، مهاجم میتواند کلید عمومی سرور (که معمولاً در دسترس عموم است) را بهعنوان secret کلید HS256 استفاده کند. سیستمهایی که الگوریتم را از توکن میخوانند و نه از پیکربندی خود، در معرض این آسیبپذیری هستند.
JWT Leakage و ذخیرهسازی ناامن
اگر JWT در localStorage مرورگر ذخیره شود، در معرض حملات XSS قرار میگیرد. هر اسکریپت مخرب میتواند مستقیماً به توکن دسترسی پیدا کند. این اشتباه در پیادهسازیهای SPA بسیار رایج است.
عدم بررسی Claims ضروری
بسیاری از پیادهسازیها تنها امضای توکن را بررسی میکنند و از اعتبارسنجی claims مانند aud، iss و exp غافل میمانند. یک توکن معتبر که برای سرویس A صادر شده، میتواند در سرویس B نیز پذیرفته شود — در حالی که نباید.
بهترین شیوههای امنیتی JWT
این بخش هسته اصلی مقاله است. هر یک از این توصیهها پاسخ مستقیمی به یک یا چند ریسک بالا هستند.
انتخاب الگوریتم امضای مناسب
الگوریتم امضا، پایه امنیت JWT است. دو دسته اصلی وجود دارد: الگوریتمهای متقارن مانند HS256، HS384 و HS512 که یک secret مشترک بین صادرکننده و گیرنده استفاده میکنند، و الگوریتمهای نامتقارن مانند RS256، RS384، ES256 و ES384 که از کلید خصوصی برای امضا و کلید عمومی برای تأیید استفاده میکنند.
برای سیستمهایی که یک سرویس هم توکن صادر میکند هم آن را تأیید میکند، HS256 قابل قبول است — مشروط بر اینکه secret بهدرستی مدیریت شود. اما در معماریهای توزیعشده، microservice یا هر جایی که سرویسهای مختلف باید توکن را تأیید کنند، RS256 یا ES256 انتخاب درست است. دلیل این است که تنها سرویس صادرکننده به کلید خصوصی دسترسی دارد، در حالی که هر سرویسی میتواند با کلید عمومی تأیید کند.
یکی از مهمترین قوانین: الگوریتم را هرگز از توکن نخوانید. الگوریتم قابل قبول باید در پیکربندی سرویس سختکدشده باشد. کتابخانهای که اجازه میدهد client الگوریتم را تعیین کند، یک ریسک امنیتی جدی است.
مقایسه الگوریتمهای رایج JWT
الگوریتم HS256 با یک کلید مشترک کار میکند، پردازش سبکی دارد و برای سیستمهای single-server مناسب است. الگوریتم RS256 از جفت کلید عمومی/خصوصی استفاده میکند، قابلیت توزیع اعتبارسنجی دارد و برای معماریهای microservice ایدهآل است. الگوریتم ES256 مبتنی بر منحنیهای بیضوی است، امنیت بالاتری در برابر طول کلید کمتر ارائه میدهد و در محیطهای با منابع محدود ترجیح داده میشود.
تنظیم صحیح Expiration Time
توکنهای JWT ذاتاً stateless هستند — این یعنی بعد از صدور، سرور هیچ کنترلی روی آنها ندارد مگر اینکه یک مکانیزم revocation اضافه کند. به همین دلیل، تنظیم مدت انقضای کوتاه یکی از مهمترین دفاعهای موجود است.
برای Access Tokenها، مدت انقضای ۱۵ دقیقه تا یک ساعت توصیه میشود. این بازه به این معنا است که حتی اگر یک توکن دزدیده شود، پنجره زمانی برای سوءاستفاده محدود است. برای Refresh Tokenها که عمر طولانیتری دارند، باید مکانیزمهای امنیتی اضافی مانند rotation، binding به device و ذخیرهسازی امن در سمت سرور در نظر گرفته شود.
فیلدهای زمانی که باید همیشه در JWT وجود داشته باشند عبارتند از: exp برای زمان انقضا، iat برای زمان صدور و nbf برای زمانی که توکن قبل از آن قابل استفاده نیست. بررسی هر سه این فیلدها در سمت سرور الزامی است.
استراتژی Access Token و Refresh Token
یک پیادهسازی امن معمولاً از دو توکن موازی استفاده میکند. Access Token کوتاهعمر برای دسترسی به منابع استفاده میشود و Refresh Token طولانیعمر برای دریافت Access Token جدید بدون نیاز به login مجدد. Refresh Token باید در یک HttpOnly cookie ذخیره شود، قابلیت تکبار استفاده داشته باشد (Refresh Token Rotation) و در سمت سرور نگهداری شود تا در صورت نیاز revoke شود.
اعتبارسنجی کامل Claims
امضا را بررسی کردید — خوب. اما کافی نیست. هر سرویس باید تمام claims مرتبط را نیز اعتبارسنجی کند.
فیلد iss (Issuer) باید با identity provider مورد اعتماد مطابقت داشته باشد. فیلد aud (Audience) باید دقیقاً با شناسه سرویس دریافتکننده برابر باشد — این از حملات token relay جلوگیری میکند. فیلد sub (Subject) باید در پایگاه داده کاربران سیستم وجود داشته باشد. فیلدهای exp، iat و nbf باید در محدوده معقول باشند.
یک اشتباه رایج این است که تیمهای توسعه فقط exp را بررسی میکنند و از aud غافل میشوند. در یک معماری multi-service، این میتواند یک توکن صادرشده برای سرویس مدیریت پروفایل را به سرویس پرداخت هم قابل استفاده کند.
ذخیرهسازی امن توکن در کلاینت
این یکی از پرچالشترین بخشهای پیادهسازی JWT است چون هیچ راه حل کاملی وجود ندارد — فقط مصالحههای مختلف.
localStorage در معرض XSS است. sessionStorage هم همین مشکل را دارد. HttpOnly Cookie در برابر XSS مقاوم است چون JavaScript نمیتواند آن را بخواند، اما در برابر CSRF آسیبپذیر است که با تنظیم صحیح SameSite=Strict یا استفاده از CSRF token میتوان آن را مدیریت کرد.
برای اپلیکیشنهای وب، ترکیب HttpOnly Cookie با SameSite=Strict و Secure flag بهترین گزینه موجود است. Access Token کوتاهعمر میتواند در حافظه JavaScript (in-memory) ذخیره شود — این در برابر XSS مقاومتر است اما با بستن تب از بین میرود.
مدیریت Revocation
یکی از نقاط ضعف ذاتی JWT این است که تا قبل از انقضا، بهطور پیشفرض قابل ابطال نیست. اگر کاربری logout کند یا اعتبارنامهاش به خطر بیفتد، چه اتفاقی میافتد؟
چند رویکرد برای مدیریت revocation وجود دارد. Token Blacklist سادهترین روش است — یک لیست از JTI (JWT ID)های ابطالشده در Redis یا سیستم مشابه نگه میدارید. ایراد: نقطه مرکزی failure ایجاد میکند و overhead دارد. Short Expiry با Refresh Token Rotation عملیترین راهحل برای اکثر سیستمهاست — Access Token آنقدر کوتاه است که revocation چندان ضروری نمیشود. Stateful Token که در سمت سرور نگهداری میشود، revocation را ساده میکند اما مزیت stateless بودن JWT را از بین میبرد.
WT در معماریهای پیچیده
JWT در محیطهای Microservice
در معماری microservice، JWT میتواند بهعنوان یک مکانیزم delegation عمل کند. یک API Gateway توکن را از کاربر دریافت کرده، تأیید میکند و میتواند اطلاعات مرتبط را در یک token داخلی به سرویسهای downstream منتقل کند.
در این معماری چند نکته حیاتی وجود دارد. هر microservice باید مستقلاً توکن را تأیید کند و به تأیید gateway اعتماد نکند — اگر gateway مورد نفوذ قرار بگیرد. Claimهای حساس مانند permissions باید از منبع معتبر بارگذاری شوند نه صرفاً از توکن. و در نهایت، شبکه داخلی هم باید با mutual TLS ایمن شود.
Token Chaining و Service-to-Service Auth
وقتی سرویس A باید از طرف کاربر با سرویس B صحبت کند، چند الگو وجود دارد. Token Passthrough که توکن اصلی کاربر را به سرویس B میفرستد ساده است اما اگر scope توکن خیلی گسترده باشد، اصل least privilege را نقض میکند. Token Exchange که در RFC 8693 تعریف شده، اجازه میدهد سرویس A توکن کاربر را با یک توکن محدودتر مخصوص سرویس B جابجا کند.
JWT و OAuth 2.0 / OIDC
JWT اغلب در چارچوب OAuth 2.0 و OpenID Connect (OIDC) استفاده میشود. در OIDC، ID Token یک JWT است که اطلاعات هویتی کاربر را حمل میکند. Access Token ممکن است JWT باشد یا نباشد — این به پیادهسازی authorization server بستگی دارد.
یک اشتباه رایج: استفاده از ID Token بهعنوان Access Token. این دو مفهوم متفاوتند. ID Token برای تأیید هویت کاربر است و باید توسط client خوانده شود. Access Token برای دسترسی به resource server است و نباید توسط client تفسیر شود.
JWT و FIDO: دو رویکرد مکمل در احراز هویت مدرن
آشنایی با بهترین شیوههای JWT کافی نیست اگر بدانیم که JWT اساساً یک مکانیزم انتقال اطلاعات پس از احراز هویت است، نه یک روش احراز هویت. سوال اصلی این است: قبل از صدور JWT، چگونه کاربر را احراز هویت میکنیم؟
اینجا است که FIDO وارد میشود و تحول اساسی ایجاد میکند.
محدودیتهای رمز عبور در زنجیره JWT
بیشتر سیستمهای مبتنی بر JWT از این الگو استفاده میکنند: کاربر نام کاربری و رمز عبور میفرستد، سرور اعتبارسنجی میکند و یک JWT صادر میکند. اما اگر رمز عبور ضعیف، لیکشده یا فیششده باشد، JWT صادرشده کاملاً معتبر به نظر میرسد — حتی در دست مهاجم.
امنیت JWT تا حد زیادی به امنیت مرحله قبل از صدور توکن وابسته است. یک JWT با الگوریتم ES256، expiry پانزده دقیقهای و claim validation کامل، اگر بر پایه یک رمز عبور ۱۲۳۴۵۶ صادر شده باشد، امنیت واقعی ندارد.
FIDO: حذف ریشه مشکل
استاندارد FIDO2 با معرفی احراز هویت مبتنی بر رمزنگاری نامتقارن، مشکل را از ریشه حل میکند. در FIDO، هیچ secret مشترکی بین کاربر و سرور وجود ندارد. کاربر یک کلید خصوصی دارد که در دستگاه سختافزاری یا authenticator امن ذخیره میشود و سرور فقط کلید عمومی متناظر را میشناسد.
احراز هویت با FIDO یک challenge-response رمزنگاریشده است. حتی اگر سرور مورد نفوذ قرار بگیرد، هیچ اعتبارنامهای برای دزدیدن وجود ندارد. حتی اگر ترافیک شبکه رهگیری شود، اطلاعات قابل بازپخش نیست. حتی اگر کاربر فریب بخورد و روی لینک جعلی کلیک کند، کلید به domain خاصی bind است و برای سایت دیگری کار نمیکند.
ترکیب FIDO با JWT: بهترین هر دو دنیا
یک معماری بالغ این دو استاندارد را کنار هم قرار میدهد. FIDO مرحله احراز هویت را با بالاترین سطح امنیت انجام میدهد و JWT اطلاعات جلسه کاربر را بهصورت stateless و قابل حمل در معماری توزیعشده منتقل میکند.
در این معماری، کاربر با FIDO احراز هویت میشود — بدون رمز عبور، بدون OTP، بدون phishing. سرور پس از تأیید FIDO assertion، یک JWT امضاشده صادر میکند که حاوی اطلاعات هویت، سطح اعتماد احراز هویت (Authentication Assurance Level) و دیگر claims لازم است. این JWT در سرویسهای downstream استفاده میشود.
نتیجه این ترکیب هم امنیت بالاتر است هم تجربه کاربری بهتر — بدون رمز عبور، بدون پیچیدگی اضافه.
راهکار نشانه: پیادهسازی FIDO با مدیریت کامل توکن
نشانه، محصول IAM شرکت رهسا، این معماری را بهصورت یکپارچه پیادهسازی میکند. این راهکار احراز هویت بدون رمز عبور مبتنی بر FIDO را با مدیریت کامل چرخه عمر توکن ترکیب میکند.
با نشانه، دستگاههای مختلف — از کلیدهای امنیتی سختافزاری تا گوشی تلفن همراه و کارتهای RFID/NFC — به authenticator تبدیل میشوند. کاربر با همین دستگاهها احراز هویت میکند، سیستم توکن مناسب صادر میکند و دسترسی به منابع با کمترین اصطکاک ممکن فراهم میشود.
علاوه بر FIDO، نشانه از احراز هویت دو عاملی با دستگاههای رمزیاب سختافزاری، توکنهای امضای دیجیتال و نشانه موبایل نیز پشتیبانی میکند. این یعنی سازمانها میتوانند مسیر مهاجرت تدریجی از سیستمهای قدیمیتر به احراز هویت کاملاً بدون رمز عبور را طی کنند.
یکپارچگی با SSO و معماری IAM کامل به این معنا است که توکنهای صادرشده توسط نشانه با استانداردهای OAuth 2.0، OIDC و SAML کاملاً سازگارند و میتوانند در اکوسیستم موجود سازمان بدون بازنویسی سرویسها ادغام شوند. برای اطلاعات بیشتر، میتوانید به neshane.co مراجعه کنید.
اشتباهات رایج در پیادهسازی JWT
این بخش مروری بر اشتباهاتی است که در audit کدهای واقعی بارها دیده میشوند.
اشتباهات در سطح کد
الگوریتم HS256 با secret کوتاه: اگر از HS256 استفاده میکنید، secret باید حداقل ۲۵۶ بیت و کاملاً تصادفی باشد. استفاده از کلمات معنادار، شناسههای قابل حدس یا کلیدهای کوتاه، امنیت رمزنگاری را بهطور جدی تضعیف میکند.
کپی کردن مثالهای آموزشی: بسیاری از آموزشهای آنلاین JWT از secret مانند “secret” یا “mysecretkey” در مثالهایشان استفاده میکنند. اینها در production کد دیده شدهاند — که نشاندهنده پیادهسازی ناامن است.
عدم بررسی نسخه کتابخانه: کتابخانههای JWT تاریخچهای از آسیبپذیریهای جدی دارند. استفاده از نسخههای قدیمی بدون بررسی changelog امنیتی، یک ریسک جدی است.
اشتباهات در سطح معماری
اعتماد به JWT بدون تأیید در لایههای داخلی: در معماری microservice، اگر سرویسهای داخلی JWT را بدون تأیید مجدد میپذیرند به این دلیل که “از gateway رد شده”، یک نقطه failure جدی وجود دارد.
استفاده از JWT برای session مدیریتشده: JWT برای stateless authentication طراحی شده. اگر به revocation فوری، single active session، یا audit trail دقیق نیاز دارید، یک session مدیریتشده در سمت سرور ممکن است انتخاب بهتری باشد.
قرار دادن اطلاعات حساس در Payload: JWT payload رمزگذاری نیست — فقط Base64url شده است. اطلاعاتی مانند شماره کارت بانکی، رمزهای موقت یا دادههای سلامت نباید در JWT قرار بگیرند مگر از JWE (JWT Encrypted) استفاده شود.
چکلیست امنیتی JWT
برای مرور سریع وضعیت پیادهسازی خود، این چکلیست را بررسی کنید.
در بخش الگوریتم و کلید: الگوریتم در پیکربندی سرور تعیین میشود نه از توکن دریافتی، الگوریتم none کاملاً غیرفعال است، کلید HS256 حداقل ۲۵۶ بیت تصادفی است، کلیدها در secret manager ذخیره میشوند نه در کد یا environment variable ساده.
در بخش Claimها: فیلدهای exp، iat، iss، aud و sub همیشه بررسی میشوند، aud بهطور مشخص با شناسه سرویس مطابقت میدهد، JTI برای جلوگیری از replay attack در صورت لزوم استفاده میشود.
در بخش ذخیرهسازی و انتقال: Access Token در in-memory یا HttpOnly cookie ذخیره میشود، انتقال فقط از طریق HTTPS انجام میشود، Refresh Token در HttpOnly cookie با SameSite=Strict قرار دارد.
در بخش مدیریت چرخه عمر: Access Token عمر کوتاه دارد (زیر یک ساعت)، مکانیزم Refresh Token Rotation پیادهسازی شده، مکانیزمی برای revocation در موارد اضطراری وجود دارد.
پرسشهای متداول
س: آیا باید اطلاعات نقش کاربر را در JWT قرار دهم؟
ج: بله، میتوانید نقشها را در JWT قرار دهید، اما با احتیاط. اگر نقش کاربر در طول عمر توکن تغییر کند، این تغییر تا انقضای توکن منعکس نمیشود. برای سیستمهایی که تغییر نقش فوری اهمیت دارد، یا از Access Tokenهای بسیار کوتاهعمر استفاده کنید یا نقش را در هر request از پایگاه داده بخوانید.
س: JWT بهتر است یا Session Token؟
ج: هیچکدام ذاتاً بهتر نیستند — به نیاز شما بستگی دارد. JWT برای معماریهای توزیعشده، APIهای عمومی و mobile backend مزیت دارد. Session token برای اپلیکیشنهای web سنتی که نیاز به revocation فوری یا single active session دارند مناسبتر است.
س: آیا میتوانم JWT را برای احراز هویت دستگاههای IoT استفاده کنم؟
ج: بله، اما باید محدودیتهای سختافزاری را در نظر بگیرید. برای دستگاههای با منابع محدود، الگوریتم ES256 نسبت به RS256 ترجیح دارد. مدیریت چرخه عمر کلید و revocation در محیط IoT چالشهای خاص خود را دارد.
س: چطور میتوانم JWT را در برابر حملات replay محافظت کنم؟
ج: استفاده از فیلد jti (JWT ID) به همراه یک blacklist کوتاهمدت در Redis میتواند از replay attack جلوگیری کند. عمر کوتاه توکن هم پنجره زمانی حمله را بهشدت محدود میکند.
س: آیا باید payload JWT را رمزگذاری کنم؟
ج: اگر payload حاوی اطلاعات حساس است، بله. JWE (JSON Web Encryption) برای این منظور تعریف شده. اما در بیشتر موارد، اطلاعات حساس اصلاً نباید در توکن قرار بگیرند.
س: چه تفاوتی بین FIDO و JWT وجود دارد؟
ج: این دو مکمل هم هستند نه رقیب. FIDO یک پروتکل احراز هویت قوی بدون رمز عبور است. JWT یک فرمت انتقال اطلاعات هویتی پس از احراز هویت است. بهترین معماری FIDO را برای احراز هویت اولیه و JWT را برای مدیریت جلسه ترکیب میکند.
کسب اطلاعات بیشتر
نشانه موبایل و نشانه توکن دو راهکار احراز هویت بدون گذرواژه هستند که بر پایه استاندارد FIDO طراحی شدهاند. این راهکارها هم امنیت دیجیتال سازمانها را ارتقا میدهند هم تجربه کاربری روانتری برای کاربران نهایی فراهم میکنند. برای آغاز مسیر حرکت به دنیای احراز هویت بدون رمز عبور و دریافت راهنمایی تخصصی، با متخصصان تیم نشانه در تماس باشید.
امنیت JWT شما کجا ایستاده است؟
متخصصان نشانه آمادهاند پیادهسازی فعلی شما را بررسی کنند و مسیر ارتقا به احراز هویت FIDO را طراحی کنند.
مشاوره امنیتی رایگان دریافت کنید:
📞 ۰۲۱-۹۱۰۹۶۵۵۱
کلیک کنید: نشانه موبایل و نشانه توکن
جمعبندی
JWT یک ابزار قدرتمند است که اگر درست استفاده شود، میتواند معماری احراز هویت توزیعشده را سادهتر کند. اما همان انعطافی که JWT را جذاب میکند، فضای زیادی برای اشتباه هم باقی میگذارد.
بهترین شیوههای استفاده امن از JWT را میتوان در چند اصل خلاصه کرد: الگوریتم را سختکد کنید نه از توکن بخوانید، عمر توکن را کوتاه نگه دارید، تمام claims را اعتبارسنجی کنید، secret را در حافظه امن ذخیره کنید و برای احراز هویت اولیه از مکانیزمهای قویتری مانند FIDO استفاده کنید.
در نهایت، JWT امنیت مرحله احراز هویت را جایگزین نمیکند — فقط اطلاعات آن را منتقل میکند. اگر پایه احراز هویت ضعیف باشد، هیچ پیادهسازی مثالی JWT نمیتواند آن را جبران کند.