به نام خدا
اگر حتی ذره ای با مفاهیم Rest Api آشنایی داشته باشید، با خواندن عنوان مطلب پی خواهید برد که قصد داریم در مورد امنیت API ها صحبت کنیم، اما برای آنکه کمی عمقی تر رفتار کرده باشیم، اجازه بدهید ابتدا یک سوال مطرح کنیم !.
در کل JWT Refresh Token چیست و به چه معنا است ؟
وقتی کاربر در یک سیستم نرم افزاری لاگین میکند، اگر همه چیز درست بود و کاربر مجاز به ورود بود، یک رشته رمز شده به Browser باز خواهد گشت که حاوی چند داده کلیدی است. این رشته اصولا عمر زیاد طولانی ندارد و پس از چند دقیقه از بین خواهد رفت و کاربر بیچاره باید دوباره لاگین کند. خوب این روند زیاد جالب نیست. فرض کنید کاربر یک سیستم مالی هر 5 دقیقه یکبار به صفحه لاگین شوت شود و مجبور باشد دوباره لاگین کند!. فکر نکنم پس از 1 روز استفاده کسی زیر بار استفاده از چنین سیستم برود. حتی فرض کنید اینستاگرام شما را مجبور کند هر 5 دقیقه لاگین کنید، خوب این بسیار بسیار جر دهنده خواهد بود. یک راه ابلهانه هم داریم و آن هم طولانی کردن عمر Token است که آن هم امنیت سیستم را زیر سوال خواهد برد. فرض کنید عمر Token مثلن 6 ماه باشد!. اینطوری هر کسی میتواند Token شما را بدزدد و برود با آیتمهای امنیتی شما وارد سیستم شده و هر کاری دلش خواست بکند!.
به تصویر بالا دقت کنید، کاربر یکبار به سرور مراجعه و Token را میگیرد، ولی چون عمر Token کلن 5 دقیقه است، باز بعد از 5 دقیقه سپری شدن زمان، باید به سرور مراجعه و یک Token جدید بگیرد !!.
حالا مشکل را متوجه شدیم، راه حل منطقی آن چیست ؟
راه حل این است که یک Refresh Token داشته باشیم که از لحظه اولین لاگین مسئولیت خودبخود رفرش شدن را به عهده داشته باشد. نکته اصلی Refresh Token این است که کاربر را درگیر نمی کند و کاربر چیزی متوجه نخواهد شد.
این Refresh Token میتواند یک String یا عدد یا یک Object باشد. نوع آن اصلن مهم نیست، بحث فقط این است که وظیفه رفرش شدن و تحرک بین کلاینت و سرور را به درستی بازی کند.
سوال بعدی : این Refresh Token چطوری برای ما امنیت بیشتری ایجاد میکند ؟.
فرض کنید Token اصلی ما را کسی بردارد و سرقت کند، عمر این Token مثلن 5 دقیقه است، از بعد از دیگر به دردش نخواهد خورد، چون Refresh Token عملن Token قبلی را از حالت Valid خارج خواهد کرد و عملن آنرا بلا استفاده خواهد نمود.
به تصویر بالا دقت کنید، دزد کلاه به سر ما Token را دزدیده، ولی پس از نهایتن 5 دقیقه، دیگر دستش به سرور نمیرسد و ارتباطش با همه چیز قطع میشود، چرا؟. چون رفرش توکن عمل کرده و توکن قبلی را از درجه اعتبار ساقط نموده است.
حال باید دید ترکیب Token و Refresh Token اصلن چگونه عمل خواهند کرد ؟. به تصور زیر دقت کنید
بر اساس تصویری که مشاهده میکنید، کاربر در ابتدا درخواست لاگین را ارسال و به اصطلاح در سیستم لاگین میکند . عملیات بر روی سرور انجام شده و یک Token و یک Refresh Token به کلاینت ارسال خواهد شد. حال تا وقتی Token کاربر Valid است، کاربر درخواستهای خود را به منابع سرور ارسال خواهد کرد، مثلن لیست کالاها را با یک متد Get خواهد گرفت. تا وقتی Token کاربر ایرادی ندارد و Valid است، نتیجه درخواستها به درستی باز میگردد، ولی اگر یک جایی Token نبود یا Expire شده بود چه ؟. آنجاست که از سمت سرور یک Invalid Token خواهد گرفت . سپس Refresh Token را ارسال میکند و باز یک Token و یک Refresh Token صحیح و سالم خواهد گرفت. شاید هر بار که Token کاربر Expire شده باشد، Request با چند میلی ثانیه تاخیر روبرو شود که آن هم به دلیل ارسال Refresh Token و جدید شدن Token باشد که اصلن محسوس نیست و ضمنن بهتر از شوت کردن کاربر به صفحه لاگین خواهد بود.
برای شروع به صورت عملی باید یک پروژه حاوی API و پس از آن پیاده سازی JWT Token و سرانجام الحاق JWT Refresh Token به آن خواهیم بود. این روند عملی طولانی خواهد بود، لذا باید صبور باشید و قدم به قدم با من حرکت کنید.
در عمل برای رسیدن به این سطح از یک پروژه عملی ، باید در ابتدا یک پروژه API بسازیم، آنرا از نظر امنیتی به JWT Token Authentication مسلح کنیم و تازه بعد از آن میتوان Refresh Token را درون آن پیاده سازی نمود، پس باید طی چند فصل این روند را پیگیری کنیم.
ادامه این مبحث را در بخش بعدی به صورت عملی پی خواهیم گرفت .....
