فرض من در این مقاله این است که: معنی و مفهوم api برای مخاطب مشخص است. مخاطب با asp core آشناست و مثلا برای دسترسی به appsetting و استفاده از اینترفیس IConfiguration مشکلی ندارد. قبلا از نوگت ( nuget ) برای نصب کتابخانه ها استفاده کرده. ایجاد کلاس user با پراپرتی های دلخواه و نوشتن یک متد برای ثبت کاربر در این جدول را بلد است. شاید اولین قدم برای امن کردن api ها بحث اعتبارسنجی یا Authentication باشد. به زبان ساده و با روشی ساده می توانیم بفهمیم چه کسی Api را صدا زده و این فرد چه مشخصاتی دارد. مثلا برای نمایش پروفایل یک فرد یا خریدهای قبلی (در فروشگاه) این موضوع اهمیت دارد. از طرفی به فرد این قابلیت را می‌دهیم که بتواند به Api های خاص دسترسی داشته باشد و یا از دسترسی منع شود. مثلا دسترسی به محتوای خریداری شده محدود به فرد خریدار باشد. این دو موضوع جدا از هم نیستند، یعنی ما لاگین می‌کنیم که بتوانیم کلیدی در اختیار داشته باشیم تا به کمک آن به متدها دسترسی داشته باشیم. این کلید را توکن میگوییم. این روش به ما کمک می‌کند در هر ریکویست، به جای چک کردن هرباره‌ی یوزر و پسورد، با یک توکن نسبت به هویت فرستنده‌ی ریکویست آگاه شویم و تصمیم مناسب بگیریم. این توکن عمر مشخصی دارد و پس از انقضا قابل استفاده نخواهد بود. همچنین هر کاربر توکن منحصر به فرد خود را دارد و از همین راه شناسایی خواهد شد. اما JWT چیست؟ یک تکست که ساختاری برای حمل اطلاعات و تشخیص هویت دارد. ساختار JWT به شکل زیر است: بخش هدر که معرف الگوریتم و تایپ است. بخش بدنه یا همان payload که میتواند اطلاعات را درون خود نگه دارد. مثل نام کاربری و. بخش سوم secret نام دارد که نخوه انکریپشن است و کد secret در سمت سرور قرار دارد. وارد جزییات هر بخش نمی‌شویم، اما این نکته را بدانید که بخش payload برای نگهداری اطلاعاتی است که در سمت کلاینت لازم هستند. مثلا شماره تماس یا آدرس و یا ایمیل کاربر. این بخش برای نگهداری اطلاعات حساس مثل رمز کاربر نیست چون خواندن آن برای همه امکانپذیر است ولی تغییر آن در فرانت امکانپذیر نیست و به کلید سمت سرور نیاز دارد. در انیمیشن بالا ابتدا api لاگین را می‌بینید که با دریافت یوزر و پسورد از کلاینت به سمت سرور رفته و پس از تشخیص هویت (بررسی کردن وجود یوزر و پسورد در دیتابیس) ، توکن توسط نام کاربری و کلید رمز سمت سرور تولید و برای کلاینت ارسال میشود. کلاینت این توکن را در جایی مثل local storage ذخیره می‌کند تا در درخواست های بعدی به شکل Header ارسال کند. در اینجا مثلا برای متد MyProfile این توکن jwt ارسال شده است و با تایید توکن در سمت سرور، اطلاعات مورد نیاز گرفته شده و به سمت کلاینت ارسال میشود. میخواهیم این مدل اعتبار سنجی را در دات نت کور بدون حضور Identity پیاده سازی کنیم. (با افزودن Identity به عنوان یک کتابخانه، بسیاری از کارها به شکل خودکار انجام میشود و ما متدهای از پیش آماده شده برای تشخیص و تایید و ایجاد و مدیریت کاربر خواهیم داشت) باید جدول اطلاعات کاربران یا Users را خودمان بسازیم. قبل از ساختن جدول، مراحل را طی میکنیم و بعدا بر اساس نیاز ستون های این جدول را ایجاد میکنیم. یک متد برای تولید توکن مینویسیم. قبل از آن کتابخانه Microsoft . IdentityModel . Tokens و System . IdentityModel . Tokens . Jwt را نصب میکنیم. (در نوگت سرچ کنید) این متد یک آبجکت برمیگرداند که حاوی تمام چیزهاییست که نیاز داریم. این متد اطلاعات موجود در claim را بر اساس کلیدی که در appsetting تعریف کرده ایم با یک طول عمر مشخص به توکن تبدیل میکند. ( میتوانیم یک متد لاگین بدون ورودی بنویسیم که فقط تولید توکن را تست کنیم. در متد لاگین پس از سنجش اینکه کاربری با user و pass مشخص شده وجود دارد این متد را فراخوانی و توکن تحویل میدهیم. حالا هر متدی بخواهد با این توکن کار کند کافیست اتریبیوت Authorize را در بالای آن قرار دهیم. برای اینکه اتریبیوت فوق کار کند باید کتابخانه Microsoft . AspNetCore . Authentication . JwtBearer را نصب و تغییرات زیر را در startup اعمال کنید. (از طریق نوگت نصب کنید) همچنین دو خط زیر را در Configure فایل startup . cs اضافه میکنیم: حالا یک متد جدید مینویسیم: میتوانید اطلاعات بیشتری را در Claim قرار دهید و اتریبیوت کاستومی برای Authorize بنویسیم و مثلا نقش کاربر را بررسی کنید. برای تست زمان توکن را دقیقه میکنیم. باید ببینیم که توکن باطل میشود و بعد از یک دقیقه متد در دسترس نخواهد بود. حالا متد لاگین را به شکل زیر مینویسیم، (فرض لیستی از یوزرها در حافظه داریم) تا اینجای کار به شکل عملی ایجاد توکن و استفاده از آن را دیدیم. شما می‌توانید محتوای توکن ها را از طریق سایت jwt ببینید ولی این به معنی توانایی دستکاری نیست. توکن بر اساس یک الگوریتم ثابت تولید نمیشود، کلید تولید توکن یا همان secret key در سمت سرور وجود دارد و توکن بر اساس آن تولید و تغییر آن سمت سرور انجام می‌شود. کلاینت توکن را به سمت سرور میفرستد و سرور به کمک سکرت میتواند توکن را ولیدیت کند. کلاینت به تنهایی میتواند هدر و payload را دیکد کند بدون آنکه secret را بداند. در ادامه بهتر است از استفاده کنیم. رفرش توکن، توکنی است که میتواند برای دریافت یک access token جدید استفاده شود بدون آنکه به یوزر پسورد نیاز باشد. قدم اول این است که خروجی متد ایجاد توکن را اصلاح کنیم که رفرش توکن هم برگرداند. پس یک متد برای تولید رفرش توکن درست میکنیم (ساده ترین راه، new کردن یک Guid است) و آن را در دیتابیس ذخیره میکنیم به شکلی که معلوم باشد هر رفرش توکن مربوط به کدام کاربر است. پس متد لاگین ما به جز توکن، رفرش توکن هم برمیگرداند. حالا کلاینت به محض پایان یافتن تاریخ انقضای توکن باید توکن را توسط رفرش توکن اصلاح کند. پس لازم است در قدم دوم یک api به نام refresh ایجاد کنیم که توکن و رفرش توکن را بگیرد و اگر رفرش توکن در دیتابیس وجود داشت بر اساس user معادل آن، توکن جدید تولید کند و به کلاینت پاس دهد. به این شکل کلاینت برای درخواست های جدید، دیگر نیاز به لاگین دوباره ندارد و این موضوع در اپ های موبایل بسیار اهمیت دارد. با توکن و رفرش توکن آشنا شدیم. پیشنهاد می‌کنم برای ذخیره کلمه عبور در دیتابیس تحقیق کنید و راه حل های مختلف را ببینید. پروسه ذخیره کلمه عبور در دیتابیس در عین سادگی، بسیار اهمیت دارد.