سیستم احراز هویت امن و قابل‌اعتماد، امروزه به یکی از ارکان اصلی اپلیکیشن‌ها، وب سرویس‌های احراز هویت و APIهای مدرن تبدیل شده است و هیچ سرویس معتبری را نمی‌توان یافت که بدون یک مکانیزم مجوزدهی استاندارد و اصولی فعالیت کند. افزایش تعداد کاربران، تنوع کلاینت‌ها و گسترش معماری‌های توزیع‌شده، باعث شده تا روش‌های سنتی مانند Session جای خود را به استانداردهای سبک، سریع و مقیاس‌پذیر بدهند. یکی از محبوب‌ترین این استانداردها، «JSON Web Token» یا همان JWT است که توانسته طی سال‌های اخیر به یکی از پرکاربردترین روش‌های انتقال داده، خصوصاً در فرایند احراز هویت و مجوزدهی تبدیل شود.

در این مطلب، با مفهوم JWT، ساختار آن و نحوه پیاده‌سازی و اعتبارسنجی توکن‌ها در بک‌-اند بیشتر آشنا می‌شویم و می‌آموزیم که چگونه این استاندارد را به‌صورت اصولی در پروژه خود به اجرا در بیاوریم.

JSON Web Token  (JWT) چیست؟

توکن JWT (JSON Web Token) یک استاندارد منبع‌باز و شناخته شده برای انتقال امن اطلاعات بین دو سیستم است. این استاندارد مشخص می‌کند که داده‌ها چگونه در قالب یک شیء JSON گردآوری شوند تا امکان ارسال آنها به‌صورت فشرده در بستر وب، شبکه یا API وجود داشته باشد. برخلاف بسیاری از روش‌های سنتی، JWT به‌صورت Self-contained عمل می‌کند و تمام اطلاعات مورد نیاز برای اعتبارسنجی را درون توکن جای داده است. از همین رو نیازی به مراجعه مداوم به دیتابیس یا نگهداری Session بر روی سرورها نیست و همین کاهش بار، سرعت و مقیاس‌پذیری سرویس‌ها را به طور چشمگیری افزایش می‌دهد.

یکی از ویژگی‌های کلیدی JWT، استفاده از «امضای دیجیتال» برای تضمین صحت و یکپارچگی داده‌هاست. زمانی که یک JWT امضا می‌شود، هرگونه تغییر در محتوای آن، اعتبار امضا را از بین می‌برد. این امضا می‌تواند با یک کلید مخفی مشترک یا با استفاده از جفت کلید عمومی و خصوصی ایجاد شود. از همین رو، گیرنده توکن می‌تواند صحت اطلاعات دریافتی و اعتبار منبع صادرکننده را بررسی کند و از دستکاری نشدن داده‌ها مطمئن شود.

بیشتر بخوانید: APIهای احراز هویت چگونه کار می‌کنند و چه مزایایی دارند؟

در عمل، JWT به‌عنوان ستون اصلی مکانیزم‌های احراز هویت و مجوزدهی (Authorization) در سیستم‌های مدرن شناخته می‌شود؛ به‌طوری که وقتی کاربری وارد سامانه می‌شود، سرور یک JWT برای او صادر می‌کند و کاربر در تمامی درخواست‌های بعدی از این توکن استفاده می‌کند. این رویکرد باعث می‌شود سرور بدون نیاز به نگهداری وضعیت کاربران و تنها با بررسی توکن، سطح دسترسی کاربران را تشخیص دهد. این قابلیت باعث شده تا JWT انتخابی ایده‌آل برای معماری‌های مقیاس‌پذیر و سرویس‌محور به‌حساب بیاید و در معماری‌هایی مانند RESTful API،Microservices  و Single Page Application (SPA)  مورد استفاده قرار گیرد.

JWT از چه بخش‌هایی تشکیل شده است؟

برای آموزش JWT و آشنایی با چگونگی کارکرد آن، ابتدا می‌بایست با ساختار این توکن آشنا شویم. JWT در ساده‌ترین و فشرده‌ترین حالت خود از سه بخش مجزا تشکیل می‌شود که با نقطه ( . ) از یکدیگر جدا می‌شوند. این ساختار علاوه‌بر سادگی پردازش، باعث می‌شود توکن‌ها بتوانند به شیوه‌ای امن در شبکه انتقال پیدا کنند.

به طور کلی، یک JWT از سه بخش تشکیل شده است:

• Header
• Payload
• Signature

و این سه بخش به شکل زیر به نمایش در می‌آیند:

در ادامه، هر یک از بخش‌های تشکیل‌دهنده JWT را به‌صورت مجزا بررسی می‌کنیم.

1. Header (هدر)

Header، اولین بخش در ساختار JWT است و معمولاً شامل دو نوع اطلاعات اصلی می‌شود:

· نوع توکن (که در اینجا JWT است.)

· الگوریتمی که برای امضای توکن استفاده شده است (مانند HMAC SHA256 یا RSA.)

نمونه‌ای از محتوای هدر:

این داده‌ها ابتدا به فرمت JSON نوشته و سپس با روش Base64 Url Encode  رمزگذاری می‌شوند. در ساختار JWT، header نقش اطلاع‌رسانی را دارد و به سیستم گیرنده می‌گوید که چگونه باید امضای توکن را بررسی کند.

2.    Payload (پیلود)

دومین بخش JWT، Payload یا بدنه توکن است. این بخش شامل اطلاعات اصلی توکن است و تمامی داده‌ها در قالب Claim ذخیره‌سازی می‌شوند. Claim ها در واقع گزاره‌هایی هستند که اطلاعات تکمیلی مرتبط با یک موجودیت (معمولاً کاربر) را در دل خود جای داده‌اند.

Claim ها به سه دسته کلی تقسیم‌بندی می‌شوند: 

• Registered Claims

مجموعه‌ای از Claim های استاندارد و پیشنهادی که برای انتقال اطلاعات پایه و قابل‌سازگاری مثل صادرکننده توکن یا زمان انقضا استفاده می‌شوند و به یکپارچگی بین سیستم‌های مختلف کمک می‌کنند. 

• Public Claims

Claimهایی هستند که توسط توسعه‌دهندگان و به‌صورت آزادانه تعریف می‌شوند. Public Claimها برای جلوگیری از تداخل نام‌ها باید به‌صورت استاندارد یا با یک فضای نام مشخص (مثل URI) ارائه شوند.

• Private Claims

Claimهای سفارشی و اختصاصی‌اند که فقط بین سیستم‌ها یا سرویس‌هایی استفاده می‌شوند که از قبل روی معنا و کاربرد آن‌ها توافق کرده‌اند.

نمونه‌ای از ساختار یک Payload:

. Signature  (امضا)

بخش سوم و حیاتی JWT، Signature یا همان امضا است که وظیفه آن حفظ امنیت توکن است. این امضا با ترکیب موارد زیر ساخته می‌شود:

· Header رمزگذاری شده

· Payload رمزگذاری شده

· Secret Key یا کلید خصوصی

· الگوریتم مشخص‌شده در Headerاین ترکیب با الگوریتمی مانند HMAC SHA256 امضا می‌شود و از این طریق، امکان بررسی صحت اطلاعات و عدم تغییر توکن را فراهم کند. در ساختار امضا، حتی اگر یک کاراکتر از Header یا Payload تغییر کند هم امضا دیگر معتبر نخواهد بود. به‌طور مثال، اگر الگوریتم HMAC SHA256  استفاده شود، امضای ساخته شده به‌صورت زیر خواهد بود:

 ترکیب اجزاء

خروجی نهایی شامل سه رشته متنی Base64-URL است که با نقطه از هم جدا شده‌اند. این ساختار به‌راحتی در محیط‌های HTML  و HTTP قابل انتقال است و در مقایسه با استانداردهای مبتنی بر XML مانند SAML، حجم بسیار کم‌تری دارد.

استاندارد JWT چگونه کار می‌کند؟

تا به اینجا با اجزاء توکن JWT آشنا شدیم و ساختار یک توکن استاندارد را شناختیم. در این بخش، چگونگی کارکرد JWT را به‌صورت گام‌به‌گام بررسی می‌کنیم و جریان کلی این استاندارد را می‌آموزیم.

مراحل کلی فعالیت JWT؛ از ورود کاربر تا دسترسی به منابع

1. کاربر با استفاده از نام کاربری، رمز عبور و یا جریان‌های دیگر احراز هویت (مانند OAuth 2.0) به سرویس وارد می‌شود.

2. در صورت تأیید اعتبار، سرور احراز هویت یک JWT برای کلاینت صادر می‌کند. توکن صادر شده معمولاً شامل چندین Claim (مانند شناسه کاربر، زمان انقضا و…) است که توسط کلید سرور امضا می‌شوند.

3. کلاینت (SPA، اپ موبایل و…) توکن را نگه می‌دارد و در درخواست‌های بعدی برای دسترسی به مسیرها یا APIهای محافظت‌شده از آنها استفاده می‌کند.

4. سرورهایی که درخواست‌ها را دریافت می‌کنند، امضای توکن را مورد بررسی قرار می‌دهند و در صورت معتبر بودن، امکان دسترسی کلاینت به سرور را فراهم می‌‌کند.

بیشتر بخوانید: استراتژی Zero Trust چیست و چگونه امنیت وب‌سرویس‌ها را تأمین می‌کند؟

تمام این فرایند می‌تواند به‌صورت «Stateless» دنبال شود؛ به آن معنا که سرور نیاز به ذخیره‌سازی Sessionها برای هر کاربر ندارد و تنها به اعتبار توکن اکتفا می‌کند. رایج‌ترین و امن‌ترین روش ارسال JWT، قرار دادن آن در هدر Authorization به شیوه Bearer است. این روش باعث می‌شود تا از مشکلات مرتبط با کوکی (مثل CSRF) تا حد زیادی اجتناب شود و مسائل CORS به شیوه ساده‌تری مدیریت شوند.

نکات ایمنی که هنگام استفاده از JWT باید رعایت شود

 توکن‌های JWT از نظر امنیتی نقشی مشابه کلیدهای دسترسی (Access Credentials) دارند و در صورت افشا شدن، می‌توانند برای ارسال درخواست از طرف کاربر مورد سوءاستفاده قرار بگیرند. از همین رو، نگه‌داشتن طولانی‌مدت توکن‌ها، خطرات امنیتی را به شدت افزایش می‌دهد و ریسک لو رفتن داده‌ها را بالا می‌برد. بهترین رویکرد برای رفع این چالش، درنظر گرفتن زمان انقضای محدود و کوتاه برای توکن‌ها است. علاوه‌براین، در سناریوهای حساس‌تر از رفرش توکن‌های جداگانه و امن استفاده می‌شود تا در صورت افشا شدن توکن اصلی، محدوده آسیب به حداقل برسد.

نکته مهم دیگری که باید مورد ملاحظه قرار بگیرد، اندازه و محل ذخیره‌سازی توکن در سمت کلاینت است. ذخیره JWT در مکان‌هایی مانند localStorage یا sessionStorage می‌تواند در برابر حملاتی مثل XSS آسیب‌پذیر باشد و مهاجم با اجرای اسکریپت‌های مخرب، به توکن دسترسی پیدا می‌کند. به همین دلیل، بسیاری از سیستم‌های امن به استفاده از Cookie های HttpOnly  یا راهکارهای ترکیبی روی آورده‌اند. از سوی دیگر، نباید payload توکن بیش از حد بزرگ شود؛ زیرا JWT معمولاً در هدرهای HTTP ارسال می‌شود و این مسئله در سرورهایی که محدودیت حجمی (مثلاً حدود ۸ کیلوبایت) دارند، مسئله‌ساز خواهد بود. 

مزایا و معایب استفاده از  JWT

JSON Web Token طی سال‌های اخیر به‌عنوان یکی از محبوب‌ترین استانداردهای احراز هویت، راه خود را به انواع سرویس‌های APIهای مدرن باز کرده است. اما دلایل این محبوبیت چیست و چرا این استاندارد به انتخاب اول بسیاری از توسعه‌دهنده‌ها تبدیل شده است. در این بخش، علاوه بر بررسی مزایای JWT، برخی معایب آن را هم شرح می‌دهیم تا دولوپرها با نگاهی همه‌جانبه به استفاده از این توکن‌ها بپردازند.

مزایای استفاده از JWT

1.  معماری سبک و فشرده

JWT  بر پایه JSON ساخته شده است و در مقایسه با استانداردهایی مانند SAML که مبتنی بر XML هستند، حجم بسیار کم‌تری دارد. همین فشرده بودن باعث می‌شود JWT به‌راحتی در هدرهای HTTP یا محیط‌های HTML منتقل شود و برای ارتباطات پرتعداد و سریع، انتخاب مناسبی باشد.

2. امنیت بالا در عین پیاده‌سازی ساده

برخلاف SWT که تنها از امضای متقارن (HMAC) استفاده می‌کند،JWT  امکان استفاده از الگوریتم‌های نامتقارن مانند RSA یا ECDSA را نیز فراهم می‌کند و همین قابلیت، دست توسعه‌دهنده‌ها را برای طراحی معماری‌های امن‌تر باز می‌گذارد. از طرفی، امضاهای دیجیتالی که بر پایه JSON انتقال پیدا می‌کنند، در مقایسه با استاندارد‌های دیگری مانند XML Signature از امنیت بالاتری برخوردارند و فرایند اجرای ساده‌تری دارند.

3. سازگاری با انواع پلتفرم‌ها و زبان‌های برنامه‌نویسی

JSON در اغلب زبان‌های برنامه‌نویسی به‌صورت مستقیم به آبجکت تبدیل می‌شود، اما XML چنین مزیتی ندارد. همین سادگی باعث می‌شود پردازش JWT چه در سمت کلاینت و چه در سمت سرور سریع‌تر و بهینه‌تر انجام شود. به همین خاطر،JWT  توانسته جایگاه ویژه‌ای نزد دولوپرها پیدا کند و به انتخابی محبوب برای اپلیکیشن‌های وب، موبایل و معماری‌های مبتنی بر Microservices  تبدیل شود.

4. عدم نیاز به نگهداری Session در سرور (Stateless)

JWT امکان طراحی سیستم‌های Stateless را فراهم می‌کند تا دیگر نیازی به نگهداری وضعیت کاربران بر روی سرور نباشد. نتیجه این فرایند را می‌توان در مقیاس‌پذیری بالاتر، مصرف منابع کمتر و کاهش چشمگیر فشار روی دیتابیس و حافظه سرور به‌وضوح مشاهده کرد.

معایب استفاده از JWT

1. قابلیت ابطال دشوار

از آنجا که JWT به‌صورت مستقل اعتبارسنجی می‌شود، لغو اعتبار توکن‌ها پیش از زمان انقضا چالش‌برانگیز است. برای این کار معمولاً باید از راهکارهای مکمل مانند blacklist یا کاهش شدید زمان انقضا استفاده شود.

2. افشای اطلاعات Payload

از آنجایی که JWT امضاشده رمزنگاری نمی‌شود، هر کسی که به توکن دسترسی داشته باشد می‌تواند محتوای payload را بخواند. این موضوع باعث می‌شود استفاده نادرست از JWT و قراردادن اطلاعات حساس در آن، ریسک امنیتی ایجاد کند.

3. چالش اندازه توکن

اگر حجم اطلاعات داخل JWT زیاد باشد، اندازه هدرهای HTTP افزایش پیدا می‌کند و این موضوع می‌تواند باعث کاهش کارایی یا حتی بروز محدودیت در سمت سرور شود. این چالش به‌خصوص در سیستم‌هایی با سطوح دسترسی و  permissionهای پیچیده بیشتر خودش را نشان می‌دهد.

4. نامناسب برای تمامی سناریوها

هرچند که JWT برای بسیاری از سناریوها انتخابی مناسب به‌حساب می‌آید؛ اما در سیستم‌های سازمانی پیچیده یا مواردی که نیاز به کنترل لحظه‌ای سطح دسترسی دارند، استانداردهایی مانند SAML یا راهکارهای مبتنی بر Session همچنان گزینه‌های منطقی‌تر و قابل‌اعتماد‌تری محسوب می‌شوند.

JWT  ابزاری قدرتمند، ساده و مقیاس‌پذیر برای احراز هویت در سیستم‌های مدرن، مخصوصاً در محیط‌های مبتنی بر API و اپلیکیشن‌های موبایل است. با این حال، استفاده از آن بدون شناخت محدودیت‌ها و رعایت اصول امنیتی می‌تواند چالش‌برانگیز باشد. به‌طورکلی، اگر از JWT در سناریو درست و با طراحی مناسب استفاده کنید، بدون شک می‌تواند به یکی از بهترین انتخاب‌ها در معماری نرم‌افزار شما تبدیل شود.

ساخت JWT Token در بک‌اند

 نحوه ساخت JWT در بک‌اند از یک منطق کلی پیروی می‌کند و فارغ از زبان برنامه‌نویسی یا فریم‌ورک، تقریباً در تمامی پلتفرم‌ها یکسان است. در این بخش، چگونگی ساخت JWT در سمت سرور (Back-end) را می‌آموزیم و مراحل اصلی آن را بررسی می‌کنیم:

1. انتخاب کتابخانه مناسب

برای هر زبان برنامه‌نویسی، کتابخانه‌های متعددی برای ایجاد و اعتبارسنجی JWT وجود دارند. به‌عنوان مثال:

· کتابخانه jsonwebtoken در Node.js

· کتابخانه PyJWT در Python

· کتابخانه jjwt در Java

این کتابخانه‌ها نقش مؤثری در روند ساخت، امضا و اعتبارسنجی توکن‌ها ایفا می‌کنند.

2. تعریف Payload و Claim

پس از انتخاب کتابخانه، گام بعدی تعیین اطلاعاتی است که می‌خواهید در توکن ذخیره کنید. این اطلاعات معمولاً شامل شناسه کاربر، نقش‌ها، تاریخ صدور و انقضا و هر داده اختصاصی دیگری است که برای احراز هویت و مجوزدهی لازم دارید.

نمونه‌ای از Payload در Node.js:

3. انتخاب الگوریتم امضا

برای آنکه اعتبار JWT تضمین شود، می‌بایست این توکن توسط امضایی معتبر تأیید شود. انتخاب الگوریتم مناسب و کلید امن، مهم‌ترین بخش امنیت JWT است. معمولاً از HMAC SHA256 برای سناریوهای ساده و از RSA یا ECDSA برای سناریوهای حساس‌تر استفاده می‌شود.

به طور مثال در Node.js با الگوریتم  HMAC SHA256شاهد ساختاری زیر هستیم:

4. ارسال توکن به کلاینت

بعد از ساخته‌شدن توکن، معمولاً آن را به‌عنوان بخشی از پاسخ درخواست ورود (Login) به کلاینت ارسال می‌کنند. رایج‌ترین روش ارسال توکن، قراردادن آن در هدر پاسخ HTTP یا در Body پاسخ JSON است.به‌طور مثال، این توکن در JSON به شکل زیر به نمایش در می‌آید:

5. ذخیره و استفاده در کلاینت

کلاینت، توکن دریافتی را ذخیره کرده و آن را در درخواست‌های بعدی به هدر Authorization اضافه می‌کند. در هر درخواست محافظت‌شده (Protected Route)، سرور مراحل زیر را انجام می‌دهد:

1. دریافت JWT از هدر Authorization
2. بررسی ساختار توکن
3. اعتبارسنجی امضا با کلید مربوطه
4. بررسی Claimهایی مانند زمان انقضا
5. استخراج اطلاعات کاربر از  Payload

در صورت معتبر بودن توکن، درخواست پردازش می‌شود؛ در غیر این صورت، پاسخ خطای Unauthorized (401) یا Forbidden (403)  به کلاینت برگردانده می‌شود.

بیشتر بخوانید: چطور امنیت داده را در APIهای هوش مصنوعی تضمین کنیم؟ 

در انتها، هر درخواستی که به مسیرهای محافظت‌شده ارسال می‌شود، توسط کلید مخفی و الگوریتم تعریف شده سیستم مورد بررسی قرار می‌گیرد و در صورت معتبر بودن، دسترسی کاربر را مجاز در نظر می‌گیرد

نکات مهم در پیاده‌سازی JWT در بک-اند

هنگام پیاده‌سازی JWT در بک-اند، حتماً به نکات زیر توجه داشته باشید تا از بروز مشکلات احتمالی جلوگیری کنید:

• Secret Key  را هرگز در کد «هاردکد» نکنید
  کلید امضا باید از طریق متغیرهای محیطی (Environment Variables) مدیریت شود.
• زمان انقضای توکن را کوتاه‌مدت در نظر بگیرید
  توکن‌های Access به‌منظور حفظ امنیت، معمولاً عمر کوتاهی دارند و به‌طور میانگین حدود 15 دقیقه در نظر گرفته می‌شوند.
• از Refresh Token استفاده کنید
  برای تمدید دسترسی کاربر بدون لاگین مجدد، از Refresh Token جداگانه و امن استفاده کنید.
• اطلاعات حساس را در Payload قرار ندهید
  JWT  رمزنگاری نمی‌شود و جهت تأمین امنیت، فقط از امضا استفاده می‌کند؛ از آنجایی که هر کسی می‌تواند Payload  را Decode کند، در نتیجه پیشنهاد می‌شود از قراردادن اطلاعات حساس در این بخش پرهیز کنید.

نگاهی به فرایند اعتبارسنجی در  JWT Token

پس از صدور JWT توسط سرور و ارسال آن از سمت کلاینت، مرحله‌ی حیاتی اعتبارسنجی توکن (JWT Verification)  آغاز می‌شود. در این مرحله، سرور ابتدا توکن را از هدر Authorization استخراج کرده و ساختار آن را بررسی می‌کند تا از وجود هر سه بخش Header، Payload و Signature مطمئن شود. سپس Header و Payload از حالت Base64Url Decode  خارج می‌شوند تا الگوریتم امضا و Claimهای تعریف‌شده در توکن قابل بررسی باشند.

این فرایند دو هدف کلی دارد:

· تشخیص الگوریتم امضا

· دسترسی به Claimها (مانند  exp،iss،sub  و…)

این فرایند به سرور اجازه می‌دهد پیش از هر تصمیم‌گیری، اطلاعات پایه‌ای مانند صادرکننده توکن، مخاطب و زمان انقضا را مورد بررسی قرار دهند.

مهم‌ترین بخش اعتبارسنجیJWT، بررسی امضای دیجیتال است؛ جایی که سرور با استفاده از الگوریتم مشخص‌شده و کلید مربوطه (Secret Key یا Public Key) امضای جدیدی از Header و Payload تولید کرده و آن را با امضای موجود در توکن مقایسه می‌کند. اگر کوچک‌ترین تغییری در داده‌های توکن رخ داده باشد، این امضا نامعتبر خواهد شد و درخواست رد می‌شود.

پس از معتبر بودن امضا، نوبت به بررسی Claimهای مهم می‌رسد. در این فرایند، موارد زیر مورد بررسی قرار می‌گیرند.

• exp  : آیا توکن منقضی شده است؟
• nbf  : آیا هنوز اجازه استفاده از توکن صادر نشده است؟
• iss  : آیا صادرکننده توکن معتبر است؟
• aud  : آیا توکن برای این سرویس صادر شده است؟

اگر تمام مراحل بالا با موفقیت انجام شود، اطلاعات کاربر از Payload استخراج شده و به درخواست تزریق می‌شود (مثلاً در req.user). از این لحظه به بعد، سرور می‌تواند بر اساس نقش‌ها و سطح دسترسی، تصمیم‌گیری‌های لازم را انجام دهد.

تفاوت Access Token و Refresh Token چیست؟

درک تفاوت میان Access Token و Refresh Token نقش مهمی در طراحی امن و اصولی این توکن‌ها دارد. در ادامه به توضیح این دو توکن کاربردی می‌پردازیم و تفاوت آنها را بررسی می‌کنیم:

Access Token چیست؟

 Access Token از جمله توکن‌های کوتاه‌مدتی است که پس از فرایند لاگین توسط سرور صادر می‌شود و کلاینت از آن برای دسترسی به  API های محافظت‌شده استفاده می‌کند. این توکن معمولاً شامل اطلاعاتی مانند شناسه کاربر، نقش‌ها و زمان انقضا است و از طریق هدر Authorization ارسال می‌شود. کوتاه‌بودن عمر Access Token باعث می‌شود حتی در صورت افشا شدن، محدوده‌ آسیب امنیتی به حداقل برسد و از این نظر، یکی از امن‌ترین توکن‌‌‌ها به حساب می‌آید.

Refresh Token چیست؟

Refresh Token را می‌توان توکنی با عمر طولانی‌تر به‌حساب آورد که صرفاً برای دریافت Access Token جدید استفاده می‌شود. زمانی که Access Token منقضی می‌شود، کلاینت بدون نیاز به ورود مجدد کاربر، Refresh Token را برای سرور ارسال می‌کند و در صورت معتبر بودن آن، یک Access Token جدید دریافت می‌کند. برخلاف Access Token، Refresh Token  نباید به‌صورت مداوم در درخواست‌های عادی به API ارسال شود و معمولاً در Cookie های HttpOnly یا مخازن امن سمت کلاینت نگهداری می‌شود.

بیشتر بخوانید: پروتکل OAuth 2.0 چیست؟ بررسی نقش آن در مجوزدهی به اپ‌های وب

در پیاده‌سازی استاندارد JWT، هر دو توکن معمولاً بر اساس الگوریتم‌هایی مانند تولید و اعتبارسنجی توکن با الگوریتم HS256  امضا و صادر می‌شوند. در اصل، Access Token مانند کلید موقت در دست کاربر است که به او اجازه دسترسی به یک سرور را می‌دهد. از طرفی، Refresh Token را می‌‌توان مانند یک کارت جایگزین یا کلید پشتیبان در نظر گرفت که وقتی Access Token منقضی شد، بدون نیاز به ورود مجدد کاربر، امکان دریافت یک Access Token جدید را فراهم می‌کند.

جمع‌بندی

JWT (JSON Web Token)  یک استاندارد امن و سبک برای احراز هویت و مجوزدهی در سیستم‌های مدرن است که امکان انتقال اطلاعات به‌صورت خودکفا (Self-contained) بین کلاینت و سرور را فراهم می‌کند. این توکن از سه بخش Header، Payload و امضا تشکیل شده و با استفاده از امضای دیجیتال از صحت و یکپارچگی داده‌ها محافظت می‌کند.

استاندارد JWT طی سال‌های اخیر توانسته جایگاه خود را در میان سیستم‌های مدرن، به‌ویژه در معماری‌های مبتنی بر API، Microservices و SPA تثبیت کند. این توکن توانسته با رعایت اصول (مانند محدود کردن زمان انقضا، نگهداری امن کلیدها و عدم ذخیره اطلاعات حساس در Payload)، استانداردی قدرتمند، سبک و قابل اعتماد را در دسترس توسعه‌دهندگان قرار دهد و راه جعل و سرقت داده‌ها را بر روی مهاجمان ببندد.