توکن JWT، مخفف JSON Web Token، قالبی فشرده برای انتقال ادعاها بین دو طرف است. برنامهها معمولاً پس از ورود به سیستم از JWT استفاده میکنند: سرور توکنی صادر میکند، کلاینت آن را با درخواستهای بعدی ارسال میکند و API قبل از اعطای دسترسی، توکن را تأیید میکند. JWT یک توکن ارز دیجیتال نیست و محتوای آن به طور خودکار مخفی نمیماند.
سیستمهای حساب کاربری در امور مالی، صرافیها و خدمات Web3 ممکن است در پشت صحنه از احراز هویت مبتنی بر توکن استفاده کنند. خوانندگانی که در حال کاوش پلتفرمهای دارایی دیجیتال هستند میتوانند یک حساب Tapbit ایجاد کنند، در حالی که توسعهدهندگان باید هر توکن احراز هویت را به عنوان یک مدرک حساس امنیتی در نظر بگیرند.
توکن JWT چیست؟
استاندارد JWT، RFC 7519، قالبی فشرده برای ادعاها را تعریف میکند که برای انتقال به عنوان یک شیء JSON طراحی شده است. ادعا بیانیهای مانند شناسه کاربر، صادرکننده توکن، مخاطب مورد نظر یا زمان انقضا است. JWTها اغلب به عنوان توکنهای دسترسی، توکنهای هویت یا پیامهای کوتاهمدت بین سرویسها استفاده میشوند.
اغلب افراد میگویند «توکن JWT»، اگرچه «T» پایانی به معنای توکن است. این تکرار رایج و بیضرر است. آنچه مهم است درک این نکته است که JWT فرمتی را توصیف میکند، نه یک سیستم ورود کامل. احراز هویت امن همچنین نیازمند سیاستهای صحیح صدور، اعتبارسنجی، ذخیرهسازی، انقضا و ابطال است.
JSON Web Token چگونه کار میکند؟
یک جریان ورود معمول زمانی شروع میشود که کاربر اعتبارنامههای معتبر را ارسال میکند. سرور احراز هویت یک JWT حاوی ادعاهای انتخاب شده ایجاد کرده و آن را با یک امضای دیجیتال یا کد احراز هویت پیام محافظت میکند. سپس کلاینت JWT را به یک API ارائه میدهد، اغلب در هدر Authorization HTTP با استفاده از طرح Bearer.
API امضا را تأیید کرده و ادعاهای مورد نیاز را قبل از اعتماد به درخواست بررسی میکند. بررسیهای مهم میتواند شامل صادرکننده، مخاطب، زمان انقضا و الگوریتم مورد انتظار برنامه باشد. اگر تأیید موفقیتآمیز باشد، API از ادعاها برای تصمیمگیری مجوز استفاده میکند. اگر ناموفق باشد، درخواست باید رد شود.
سه بخش یک JWT
یک JWT امضا شده که معمولاً دیده میشود، دارای سه بخش رمزگذاری شده با Base64url است که با نقطه از هم جدا شدهاند:
header.payload.signature
- Header: نوع توکن و الگوریتم امضا را مشخص میکند.
- Payload: حاوی ادعاها، مانند
subبرای موضوع،issبرای صادرکننده،audبرای مخاطب وexpبرای انقضا است. - Signature: به گیرنده اجازه میدهد تا تغییرات غیرمجاز را تشخیص دهد و در صورت استفاده از کلید صحیح، امضاکننده را تأیید کند.
رمزگذاری Base64url رمزگذاری نیست. هر کسی که یک JWT امضا شده معمولی را به دست آورد، معمولاً میتواند هدر و پیلود آن را رمزگشایی کند. بنابراین، اطلاعات حساس نباید در پیلود قرار گیرند مگر اینکه سیستم از فرمت رمزگذاری شده مناسب استفاده کند و نیاز واضحی به آن داشته باشد.
مثال JWT برای مبتدیان
یک API را در نظر بگیرید که پس از ورود آلیس، توکنی صادر میکند. پیلود آن ممکن است آلیس را به عنوان موضوع شناسایی کند، صادرکننده را نام ببرد، مخاطب API را مشخص کند و در 15 دقیقه منقضی شود. هنگامی که آلیس درخواست پروفایل خود را میدهد، API توکن را تأیید کرده و از ادعای موضوع برای یافتن حساب صحیح استفاده میکند.
اگر کسی پیلود را از شناسه آلیس به شناسه یک مدیر تغییر دهد، امضا دیگر مطابقت نخواهد داشت. این مزیت اصلی یک JWT امضا شده است: دستکاری قابل تشخیص میشود. با این حال، یک امضای معتبر اثبات نمیکند که هر ادعا مناسب است. API همچنان باید تأیید کند که توکن از صادرکننده مورد انتظار آمده و برای آن API در نظر گرفته شده است.
JWT در مقابل کوکیهای نشست در مقابل کلیدهای API
| روش | هدف معمول | وضعیت در کجا قرار دارد | ملاحظه اصلی |
|---|---|---|---|
| JWT | ادعاها و مجوز API | توکن ادعاها را حمل میکند؛ سرورها ممکن است همچنان وضعیت را حفظ کنند | طراحی اعتبارسنجی و ابطال |
| کوکی نشست | نشست ورود مرورگر | معمولاً فروشگاه وضعیت نشست سمت سرور | محافظت از کوکی و CSRF |
| کلید API | شناسایی یک برنامه یا پروژه | سرور کلید را با مجوزها نگاشت میکند | کلیدها اسرار طولانیمدت هستند مگر اینکه چرخش داده شوند |
JWTها به طور خودکار بهتر از نشستها نیستند. نشستها میتوانند ابطال فوری را ساده کنند، در حالی که JWTها میتوانند جستجوهای مکرر پایگاه داده را کاهش دهند و در سرویسهای توزیع شده به خوبی کار کنند. بسیاری از سیستمها هر دو رویکرد را ترکیب میکنند، مانند یک JWT کوتاهمدت با یک رکورد توکن بازپرداخت که توسط سرور مدیریت میشود.
آیا JWTها رمزگذاری شدهاند؟
معمولاً نه. JWT سه قسمتی آشنا معمولاً یک شیء امضا شده JSON Web Signature است. امضا در صورت پیادهسازی صحیح، یکپارچگی و اصالت را فراهم میکند، اما پیلود را پنهان نمیکند. JSON Web Encryption یک استاندارد مرتبط است که میتواند محرمانگی را فراهم کند، اگرچه از ساختار متفاوتی استفاده میکند و پیچیدگی مدیریت کلید را اضافه میکند.
این تمایز مهم است زیرا توسعهدهندگان گاهی اوقات یک JWT را در یک رمزگشا قرار میدهند و از دیدن دادههای قابل خواندن شگفتزده میشوند. رمزگشایی با تأیید موفقیتآمیز امضا یکسان نیست. برنامهها هرگز نباید فقط بر اساس ادعاهای رمزگشایی شده دسترسی اعطا کنند.
خطرات امنیتی رایج JWT
IETF’s بهترین شیوههای JWT، RFC 8725، به شکستهای پیادهسازی که در سیستمهای واقعی ظاهر شدهاند، میپردازد. بزرگترین مشکلات معمولاً ناشی از اعتبارسنجی نادرست است تا فرمت پایه.
- سردرگمی الگوریتم: پذیرش الگوریتم غیرمنتظره یا ناامن.
- بررسیهای ادعای گمشده: نادیده گرفتن صادرکننده، مخاطب، انقضا یا سایر الزامات برنامه.
- سرقت توکن: افشای توکن حامل از طریق لاگها، اسکریپتها، ذخیرهسازی ناامن یا حمل و نقل محافظت نشده.
- کلیدهای ضعیف: استفاده از اسرار قابل حدس یا عدم چرخش کلیدهای امضای به خطر افتاده.
- انقضای طولانی: باقی گذاشتن توکنهای دزدیده شده برای مدت طولانی مفید.
- ابطال ضعیف: فرض اینکه یک توکن امضا شده هرگز نیازی به ابطال زودهنگام ندارد.
بهترین شیوههای JWT
برنامهها باید به صراحت فقط الگوریتمهایی را که پشتیبانی میکنند مجاز کنند، هر ادعای مورد نیاز را تأیید کنند و از قوانین اعتبارسنجی جداگانه برای انواع مختلف JWT استفاده کنند. توکنها باید کوتاهمدت باشند، فقط از طریق HTTPS منتقل شوند و از URLها و لاگهای معمول حذف شوند. کلیدهای امضا نیاز به ذخیرهسازی امن، چرخش و مالکیت واضح دارند.
ذخیرهسازی به برنامه بستگی دارد. سیستمهای مرورگر ممکن است از کوکیهای امن، HttpOnly و SameSite استفاده کنند، در حالی که کلاینتهای موبایل یا بکاند از ذخیرهسازی محافظت شده مناسب پلتفرم استفاده میکنند. هیچ انتخاب ذخیرهسازی تمام تهدیدها را از بین نمیبرد، بنابراین توسعهدهندگان باید اسکریپت بین سایتی، جعل درخواست بین سایتی، پخش مجدد توکن و سازش دستگاه را با هم در نظر بگیرند.
نتیجهگیری
JWT راهی فشرده برای حمل ادعاهای قابل تأیید بین سیستمها است. هدر آن نحوه محافظت از آن را توصیف میکند، پیلود آن حاوی ادعاها است و امضای آن به گیرندگان در تشخیص دستکاری کمک میکند. JWTها میتوانند احراز هویت API را ساده کنند، اما تنها زمانی که گیرنده الگوریتم، صادرکننده، مخاطب، ادعاهای زمانبندی و امضای صحیح را تأیید کند. برای مبتدیان، قانون کلیدی ساده است: JWT یک فرمت مدرک است، نه اثباتی که کل طراحی احراز هویت امن است.
سوالات متداول
JWT مخفف چیست؟
JWT مخفف JSON Web Token است، یک فرمت فشرده استاندارد شده برای انتقال ادعاها به صورت JSON.
آیا هر کسی میتواند JWT را رمزگشایی کند؟
هر کسی که یک JWT امضا شده معمولی را دارد، معمولاً میتواند هدر و پیلود آن را رمزگشایی کند. رمزگشایی امضا را تأیید نمیکند و ادعاها را قابل اعتماد نمیسازد.
آیا JWT همان توکن دسترسی است؟
خیر. توکن دسترسی یک هدف را توصیف میکند، در حالی که JWT یک فرمت را توصیف میکند. برخی از توکنهای دسترسی JWT هستند و برخی دیگر رشتههای مبهم هستند.
یک JWT چقدر باید دوام بیاورد؟
مدت زمان جهانی وجود ندارد. توکنهای دسترسی معمولاً کوتاهمدت هستند و عمر دقیق آنها بر اساس ریسک سیستم، ابطال و الزامات قابلیت استفاده تعیین میشود.
آیا JWT قابل ابطال است؟
بله، اما ابطال نیازمند طراحی اضافی است، مانند لیست سیاه، چرخش کلید، نسخهبندی توکن یا سیستمی که توکن بازپرداخت توسط سرور مدیریت میشود.
