در سیستم‌های احراز هویت مبتنی بر JWT (JSON Web Token)، دو نوع توکن اصلی وجود دارد: Access Token (توکن دسترسی) و Refresh Token (توکن بازخوانی). هر کدام از این توکن‌ها نقش مهمی در حفظ امنیت و تجربه کاربری ایفا می‌کنند.

Access Token:

• نقش: توکن دسترسی، همانطور که از نامش پیداست، برای دسترسی به منابع محافظت‌شده در یک برنامه یا API استفاده می‌شود. این توکن مانند یک کلید دیجیتال عمل می‌کند که به کاربر اجازه می‌دهد تا به بخش‌های مختلف برنامه دسترسی داشته باشد. در این نوع از توکن اطلاعات حساس کاربر چون، userId، email، name و... ذخیره خواهد شد. (جهت مطالعه دقیق و چگونگی پیاده سازی این مدل از توکن به مقاله  «توکن وب و یا JWT چیست؟ کلید امن و کارآمد برای مجوزدهی» (کلیک کنید) مراجعه کنید)
• طول عمر: توکن‌های دسترسی معمولاً طول عمر کوتاهی دارند (مثلاً 15 دقیقه تا چند ساعت). این طول عمر کوتاه به دلایل امنیتی است. اگر یک توکن دسترسی به سرقت رود، مدت زمان سوءاستفاده از آن محدود خواهد بود.
• نحوه ذخیره‌سازی: توکن‌های دسترسی معمولاً در سمت کلاینت (مثلاً در حافظه یا کوکی‌های مرورگر) ذخیره می‌شوند.

Refresh Token:

• نقش: توکن بازخوانی برای دریافت توکن‌های دسترسی جدید بدون نیاز به ورود مجدد کاربر استفاده می‌شود. وقتی طول عمر یک توکن دسترسی به پایان می‌رسد، برنامه می‌تواند از توکن بازخوانی برای دریافت یک توکن دسترسی جدید استفاده کند.
• طول عمر: توکن‌های بازخوانی معمولاً طول عمر بسیار بیشتری نسبت به توکن‌های دسترسی دارند (مثلاً چند روز یا چند هفته).
• نحوه ذخیره‌سازی: به دلیل طول عمر بالا و اهمیت امنیتی، توکن‌های بازخوانی باید به صورت امن در سمت سرور ذخیره شوند (مثلاً در پایگاه داده). ذخیره توکن بازخوانی در سمت کلاینت (به خصوص در localStorage) به شدت ناامن است و توصیه نمی‌شود.

تفاوت‌های کلیدی بین Access Token و Refresh Token:

افزایش امنیت Refresh Token با استفاده از IP و User-Agent:

برای افزایش امنیت توکن‌های بازخوانی، می‌توان اطلاعات مربوط به IP آدرس و User-Agent کاربر را هنگام صدور توکن ذخیره کرد. سپس، هر بار که از توکن بازخوانی برای دریافت توکن دسترسی جدید استفاده می‌شود، سرور می‌تواند این اطلاعات را با اطلاعات فعلی درخواست‌کننده مقایسه کند.

• بررسی IP Address: اگر IP آدرس درخواست‌کننده برای دریافت توکن دسترسی جدید با IP آدرسی که هنگام صدور توکن بازخوانی ثبت شده است متفاوت باشد، می‌تواند نشانه‌ای از سرقت توکن باشد و سرور می‌تواند از صدور توکن دسترسی جدید خودداری کند یا اقدامات امنیتی بیشتری را اعمال نماید (مانند درخواست احراز هویت مجدد).
• بررسی User-Agent: به طور مشابه، تغییر در User-Agent (اطلاعات مربوط به مرورگر و سیستم عامل کاربر) نیز می‌تواند یک نشانه هشداردهنده باشد. البته، تغییر User-Agent ممکن است در شرایط عادی نیز رخ دهد (مثلاً به‌روزرسانی مرورگر)، بنابراین باید با احتیاط بیشتری مورد بررسی قرار گیرد.

سایر نکات مهم در مورد Refresh Token:

• ذخیره‌سازی امن: همانطور که اشاره شد، Refresh Token ها، باید به صورت امن در سمت سرور ذخیره شوند. استفاده از رمزنگاری قوی برای ذخیره‌سازی این توکن‌ها ضروری است.
• HttpOnly Cookie: برای محافظت از توکن بازخوانی در برابر حملات XSS (Cross-Site Scripting)، توصیه می‌شود آن را در یک کوکی با ویژگی HttpOnly ذخیره کنید. کوکی‌های HttpOnly از طریق جاوااسکریپت قابل دسترسی نیستند.
• Secure Cookie: برای اطمینان از اینکه توکن بازخوانی فقط از طریق اتصالات امن HTTPS منتقل می‌شود، باید ویژگی Secure برای کوکی آن تنظیم شود.
• چرخش Refresh Token (Refresh Token Rotation): یک روش امنیتی پیشرفته‌تر، چرخش توکن بازخوانی است. در این روش، هر بار که از یک توکن بازخوانی برای دریافت توکن دسترسی جدید استفاده می‌شود، یک توکن بازخوانی جدید نیز صادر شده و توکن بازخوانی قبلی باطل می‌شود. این کار خطر سوءاستفاده از توکن‌های بازخوانی دزدیده شده را به میزان قابل توجهی کاهش می‌دهد. توصیه میکنم که برای هر بار درخواست، الگورتیم رمزنگاری با مشخص شدن مدل آن در دیتابیس جهت بازخوانی، تغییر کنید. (کار سختی است ولی توصیه اکید دارم)
• ابطال Refresh Token: باید مکانیزمی برای ابطال توکن‌های بازخوانی وجود داشته باشد. این امر می‌تواند در مواردی مانند خروج کاربر از سیستم، تغییر رمز عبور یا تشخیص فعالیت‌های مشکوک ضروری باشد.
• محدودیت استفاده: می‌توان تعداد دفعات یا بازه زمانی مجاز برای استفاده از یک توکن بازخوانی را محدود کرد.
• پیوند دادن Refresh Token به کاربر و دستگاه: علاوه بر IP و User-Agent، می‌توان اطلاعات بیشتری مانند شناسه دستگاه کاربر را نیز هنگام صدور توکن بازخوانی ثبت کرد و در هنگام استفاده مجدد بررسی نمود.

چرا از Refresh Token استفاده می‌کنیم؟

• بهبود تجربه کاربری: با استفاده از Refresh Token، کاربران برای مدت طولانی‌تری می‌توانند بدون نیاز به ورود مجدد به سیستم دسترسی داشته باشند.
• افزایش امنیت: با کوتاه نگه داشتن طول عمر Access Token، حتی در صورت سرقت آن، مدت زمان سوءاستفاده محدود می‌شود. Refresh Token که به صورت امن در سمت سرور نگهداری می‌شود، امکان دریافت توکن‌های دسترسی جدید را فراهم می‌کند.
• امکان ابطال: در صورت لزوم (مثلاً در صورت تشخیص فعالیت مشکوک)، می‌توان Refresh Token را باطل کرد و دسترسی کاربر را قطع نمود.

چرا به جای Refresh Token از Access Token با طول عمر طولانی استفاده نمی‌کنیم؟

تصور کنید که ما به جای استفاده از Refresh Token، تصمیم بگیریم که Access Token خود را با طول عمر بسیار طولانی (مثلاً یک ماه یا بیشتر) صادر کنیم. در نگاه اول، ممکن است این کار ساده‌تر به نظر برسد و نیاز به مدیریت توکن‌های جداگانه (Access و Refresh) را از بین ببرد. با این حال، این رویکرد مشکلات امنیتی جدی ایجاد می‌کند:

1. افزایش خطر سوءاستفاده در صورت سرقت توکن:

• اگر یک Access Token با طول عمر طولانی به دست افراد غیرمجاز بیفتد (مثلاً از طریق حملات XSS، استراق سمع شبکه، یا دسترسی فیزیکی به دستگاه کاربر)، مهاجم می‌تواند برای مدت زمان بسیار طولانی به تمام منابع محافظت‌شده کاربر دسترسی داشته باشد.
• در این سناریو، تا زمانی که توکن منقضی نشود، هیچ راه آسانی برای جلوگیری از دسترسی مهاجم وجود ندارد.

2. عدم امکان ابطال فوری توکن:

• یکی از مزایای کلیدی Refresh Token، امکان ابطال آن در صورت لزوم است (مثلاً زمانی که کاربر از سیستم خارج می‌شود، رمز عبور خود را تغییر می‌دهد، یا فعالیت مشکوکی شناسایی می‌شود).
• اگر فقط از Access Token با طول عمر طولانی استفاده کنیم، در صورت بروز چنین شرایطی، نمی‌توانیم به سرعت دسترسی مهاجم (در صورت سرقت توکن) را قطع کنیم. تنها راه، انتظار برای انقضای طبیعی توکن خواهد بود که ممکن است زمان زیادی طول بکشد.

3. کاهش سطح امنیتی کلی سیستم:

• استفاده از Access Token با طول عمر کوتاه (همراه با Refresh Token) یک لایه امنیتی اضافی ایجاد می‌کند. حتی اگر یک Access Token به خطر بیفتد، دوره زمانی سوءاستفاده محدود خواهد بود.
• با استفاده از Access Token با طول عمر طولانی، ما این لایه امنیتی مهم را از دست می‌دهیم و سیستم را در برابر تهدیدات آسیب‌پذیرتر می‌کنیم.

4. پیچیدگی در مدیریت تغییرات نقش‌ها و مجوزها:

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

5. آسیب‌پذیری بیشتر در برابر حملات:

• طول عمر طولانی Access Token می‌تواند پنجره حمله را برای مهاجمان بازتر کند. آن‌ها زمان بیشتری برای تلاش برای سوءاستفاده از توکن دزدیده شده خواهند داشت.

چرا Refresh Token راه حل بهتری است؟

• امنیت بیشتر: Access Token با طول عمر کوتاه، خطر سوءاستفاده را محدود می‌کند. Refresh Token به صورت امن در سمت سرور ذخیره می‌شود و فقط برای دریافت Access Token جدید استفاده می‌شود.
• تجربه کاربری بهتر: کاربران برای مدت طولانی‌تری بدون نیاز به ورود مجدد به سیستم دسترسی دارند، در حالی که امنیت همچنان حفظ می‌شود.
• امکان ابطال: در صورت لزوم، می‌توان Refresh Token را باطل کرد و دسترسی کاربر را قطع نمود.
• کنترل بیشتر: سرور کنترل بیشتری بر جلسات کاربری دارد و می‌تواند در صورت نیاز، دسترسی‌ها را مدیریت کند.

چرا به جای Refresh Token، فیلدهای IsRevoke یا IP را برای Access Token ذخیره نمی‌کنیم؟

اگرچه ممکن است در نگاه اول ذخیره فیلدهایی مانند IsRevoke (آیا باطل شده است؟) یا IP (آدرس IP صادرکننده) برای Access Token به عنوان راهی برای افزایش امنیت به نظر برسد، اما این رویکرد با مشکلات و محدودیت‌های اساسی روبرو است که باعث می‌شود استفاده از Refresh Token به عنوان راه حل ارجح باقی بماند.

مشکلات ذخیره IsRevoke در Access Token:

• لزوم نگهداری لیست توکن‌های باطل‌شده (Stateful): اگر بخواهیم وضعیت IsRevoke را برای هر Access Token پیگیری کنیم، سرور باید یک پایگاه داده یا حافظه برای نگهداری لیستی از تمام توکن‌های باطل‌شده داشته باشد. این امر ماهیت "بی‌حالت" (Stateless) توکن‌های JWT را نقض می‌کند. یکی از مزایای اصلی JWT این است که سرور برای اعتبارسنجی توکن نیازی به مراجعه به پایگاه داده ندارد؛ تمام اطلاعات لازم در خود توکن رمزنگاری شده است. نگهداری لیست باطل‌شده‌ها، سرور را "با حالت" می‌کند و بار پردازشی و پیچیدگی سیستم را افزایش می‌دهد.
• افزایش بار پردازشی: در هر درخواست برای دسترسی به یک منبع محافظت‌شده، سرور علاوه بر اعتبارسنجی امضای توکن، باید لیست توکن‌های باطل‌شده را نیز بررسی کند تا مطمئن شود که توکن فعلی باطل نشده است. این کار سربار اضافی به هر درخواست تحمیل می‌کند.
• مشکلات مقیاس‌پذیری: نگهداری و جستجو در یک لیست بزرگ از توکن‌های باطل‌شده می‌تواند با افزایش تعداد کاربران و توکن‌ها، به یک گلوگاه عملکرد تبدیل شود و مقیاس‌پذیری سیستم را محدود کند.
• پیچیدگی مدیریت: مدیریت چرخه عمر توکن‌ها و به‌روزرسانی لیست باطل‌شده‌ها می‌تواند پیچیده و مستعد خطا باشد.

مشکلات ذخیره IP در Access Token:

• تغییر IP کاربر: آدرس IP کاربران می‌تواند به دلایل مختلفی تغییر کند (مثلاً تغییر شبکه Wi-Fi، استفاده از اینترنت همراه، تغییر پروکسی). اگر IP صادرکننده در Access Token ذخیره شود و IP کاربر در زمان درخواست تغییر کرده باشد، توکن به اشتباه نامعتبر تلقی خواهد شد و کاربر با مشکل مواجه می‌شود. این امر تجربه کاربری را به شدت تحت تاثیر قرار می‌دهد.
• NAT و شبکه‌های بزرگ: در بسیاری از شبکه‌های بزرگ (مانند شبکه‌های شرکتی یا دانشگاهی)، چندین کاربر ممکن است از طریق یک آدرس IP عمومی به اینترنت متصل شوند. ذخیره IP در توکن در این موارد نمی‌تواند به طور موثر هویت کاربر را تضمین کند.
• محدودیت‌های امنیتی: حتی اگر IP کاربر ثابت باشد، مهاجمان می‌توانند با استفاده از تکنیک‌های مختلف (مانند VPN یا پروکسی) آدرس IP خود را جعل کنند و از این محدودیت عبور کنند. بنابراین، تکیه صرف بر IP به عنوان یک عامل امنیتی قوی کافی نیست.
• افزایش اندازه توکن: افزودن فیلد IP به Access Token، حجم آن را افزایش می‌دهد و می‌تواند منجر به سربار بیشتر در انتقال توکن بین کلاینت و سرور شود.

چرا Refresh Token راه حل بهتری است؟

• حفظ ماهیت Stateless: Access Token همچنان می‌تواند بی‌حالت باقی بماند و اعتبارسنجی آن نیازی به مراجعه به پایگاه داده ندارد.
• امکان ابطال: Refresh Token که در سمت سرور ذخیره می‌شود، می‌تواند در صورت لزوم باطل شود. هنگامی که Access Token منقضی می‌شود و کلاینت سعی می‌کند با یک Refresh Token باطل‌شده توکن جدیدی دریافت کند، درخواست رد خواهد شد.
• امنیت بیشتر: Refresh Token معمولاً طول عمر بیشتری دارد و به صورت امن در سمت سرور ذخیره می‌شود. می‌توان مکانیزم‌های امنیتی بیشتری را برای مدیریت Refresh Token اعمال کرد (مانند چرخش توکن، محدودیت استفاده، پیوند دادن به دستگاه).
• بهبود تجربه کاربری: کاربران برای مدت طولانی‌تری بدون نیاز به ورود مجدد به سیستم دسترسی دارند، در حالی که امنیت همچنان حفظ می‌شود.

نتیجه‌گیری:

1. Refresh Token یک جزء حیاتی در سیستم‌های احراز هویت مبتنی بر JWT است که به تعادل بین امنیت و تجربه کاربری کمک می‌کند. با پیاده‌سازی صحیح و در نظر گرفتن نکات امنیتی مانند ذخیره‌سازی امن، استفاده از HttpOnly و Secure برای کوکی‌ها، بررسی IP و User-Agent، و پیاده‌سازی مکانیزم ابطال و چرخش توکن، می‌توان یک سیستم احراز هویت قوی و کاربرپسند ایجاد کرد.
2. استفاده از Access Token با طول عمر طولانی به جای Refresh Token، راحتی ظاهری را به قیمت کاهش شدید امنیت به همراه دارد. Refresh Token با ایجاد یک چرخه عمر جداگانه برای توکن دسترسی (کوتاه) و توکن بازخوانی (طولانی‌تر و محافظت‌شده‌تر)، یک راه حل امن و کارآمد برای مدیریت احراز هویت در سیستم‌های مدرن ارائه می‌دهد.
3. در حالی که افزودن فیلدهایی مانند IsRevoke یا IP به Access Token ممکن است در نگاه اول به عنوان یک اقدام امنیتی به نظر برسد، این رویکرد با مشکلات جدی در زمینه حفظ ماهیت بی‌حالت JWT، افزایش بار پردازشی، مشکلات مقیاس‌پذیری و محدودیت‌های امنیتی روبرو است. Refresh Token با جدا کردن مسئولیت دسترسی کوتاه مدت (Access Token) از امکان تمدید دسترسی (Refresh Token که در سمت سرور مدیریت می‌شود)، یک راه حل امن‌تر، کارآمدتر و مقیاس‌پذیرتر برای مدیریت احراز هویت در سیستم‌های مدرن ارائه می‌دهد.