JWT در ASP.NET Core چیست؟ راهنمای کامل Authentication و امنسازی Web API
مبینا اسبقی
1405/07/02
JWT چیست؟ آشنایی با JSON Web Token و کاربرد آن در احراز هویت
وقتی وارد یک سایت یا برنامه میشوید، معمولاً انتظار دارید بعد از یک بار ورود، سیستم شما را بشناسد و لازم نباشد برای هر صفحه دوباره نام کاربری و رمز عبور را وارد کنید.
اینجا یک سؤال مهم پیش میآید: برنامه از کجا میفهمد شما همان کاربری هستید که چند دقیقه قبل وارد شدهاید؟
در برنامههای قدیمیتر معمولاً از Session برای نگهداری اطلاعات ورود کاربر استفاده میشد، اما با رشد برنامههای مدرن، مخصوصاً APIها و معماریهای Frontend و Backend جدا، روشهای جدیدتری مورد نیاز بودند.
یکی از محبوبترین روشها برای مدیریت احراز هویت در APIها، استفاده از JWT یا JSON Web Token است.
JWT به برنامه اجازه میدهد بعد از ورود موفق کاربر، یک Token ایجاد کند و کاربر در درخواستهای بعدی خودش آن Token را ارسال کند.
سرور هم با بررسی این Token متوجه میشود درخواست از طرف چه کاربری ارسال شده و آیا این کاربر اجازه انجام آن عملیات را دارد یا نه.
اگر بخواهیم خیلی ساده بگوییم:
JWT یک روش استاندارد برای انتقال اطلاعات احراز هویت بین Client و Server است که معمولاً در ساخت APIها استفاده میشود.
در این مقاله قرار است ببینیم JWT دقیقاً چیست، چطور کار میکند، چه تفاوتی با Session دارد، چطور در ASP.NET Core پیادهسازی میشود و در پروژه واقعی چه نکات امنیتی را باید رعایت کنیم.
تصویر 1
JWT چیست و چه مشکلی را حل میکند؟
فرض کن یک فروشگاه اینترنتی داری.
کاربر وارد حساب خودش میشود، سفارشهای قبلی خودش را میبیند، محصولات را به سبد خرید اضافه میکند و اطلاعات حسابش را تغییر میدهد.
حالا برنامه باید در هر درخواست بداند:
- این درخواست مربوط به کدام کاربر است؟
- آیا کاربر وارد حسابش شده یا نه؟
- آیا اجازه انجام این عملیات را دارد؟
اینجا بحث Authentication و Authorization مطرح میشود.
Authentication یعنی:
«سیستم مطمئن شود شما چه کسی هستید.»
Authorization یعنی:
«سیستم بررسی کند آیا اجازه انجام یک کار خاص را دارید یا نه.»
JWT بیشتر در مرحله انتقال اطلاعات مربوط به Authentication استفاده میشود.
یعنی بعد از اینکه کاربر با نام کاربری و رمز عبور وارد شد، سرور یک Token تولید میکند.
این Token در درخواستهای بعدی همراه درخواست ارسال میشود.
Authorization: Bearer your_token_here
سرور Token را بررسی میکند، اگر معتبر بود اطلاعات کاربر را استخراج میکند و اجازه ادامه پردازش درخواست را میدهد.
بدون JWT، هر بار باید روش دیگری برای نگهداری وضعیت ورود کاربر داشته باشیم.
JWT این فرآیند را مخصوصاً در معماریهایی که Client و Server جدا هستند سادهتر میکند.
Authentication و Authorization چه تفاوتی دارند؟
این دو مفهوم خیلی وقتها با هم اشتباه گرفته میشوند.
ولی در پروژههای واقعی باید تفاوتشان را دقیق بدانیم.
| مفهوم | توضیح |
|---|---|
| Authentication | بررسی هویت کاربر؛ یعنی سیستم بفهمد کاربر چه کسی است. |
| Authorization | بررسی سطح دسترسی؛ یعنی کاربر اجازه انجام چه کاری را دارد. |
برای مثال:
وقتی کاربر ایمیل و رمز عبور خودش را وارد میکند، سیستم Authentication انجام میدهد.
بعد از ورود، اگر بخواهد وارد بخش مدیریت شود، سیستم باید بررسی کند آیا این کاربر Role مربوط به مدیر را دارد یا نه.
این مرحله Authorization است.
JWT چطور کار میکند؟
برای اینکه بهتر متوجه شویم JWT چطور کار میکند، مسیر کامل ورود یک کاربر را بررسی کنیم.
فرض کن کاربر فرم ورود را ارسال میکند:
{
"username": "afshin",
"password": "123456"
}
مرحله اول: درخواست به Backend ارسال میشود.
مرحله دوم: سرور اطلاعات کاربر را بررسی میکند.
اگر اطلاعات درست باشد، سرور یک JWT Token ایجاد میکند.
نمونه ساده Token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
سپس Token به Client برگردانده میشود.
Client معمولاً این Token را ذخیره میکند و در درخواستهای بعدی همراه Header ارسال میکند.
GET /api/orders
Authorization: Bearer eyJhbGciOiJIUzI1...
حالا Backend Token را دریافت میکند، امضای آن را بررسی میکند و اگر معتبر بود اطلاعات داخل آن را میخواند.
در نهایت درخواست ادامه پیدا میکند.
تصویر 2
ساختار JWT چیست؟
یک JWT معمولاً از سه بخش تشکیل شده:
Header.Payload.Signature
این سه بخش با نقطه از هم جدا میشوند.
بخش اول: Header
Header معمولاً شامل اطلاعاتی درباره نوع Token و الگوریتم امضا است.
{
"alg": "HS256",
"typ": "JWT"
}
بخش دوم: Payload
Payload شامل اطلاعاتی است که به آن Claim گفته میشود.
مثلاً:
{
"sub": "12345",
"name": "Afshin",
"role": "Admin"
}
این اطلاعات میتواند شامل شناسه کاربر، Role، زمان ایجاد Token و زمان انقضا باشد.
بخش سوم: Signature
Signature برای اطمینان از معتبر بودن Token استفاده میشود.
سرور با استفاده از Secret Key خودش این امضا را ایجاد میکند.
وقتی Token دوباره دریافت شد، سرور میتواند بررسی کند آیا Token دستکاری شده یا نه.
آیا اطلاعات JWT رمزنگاری شدهاند؟
یکی از اشتباهات رایج درباره JWT این است که بعضیها فکر میکنند اطلاعات داخل JWT رمزنگاری شدهاند.
در حالت معمول JWT رمزنگاری نمیشود؛ بلکه Encode میشود.
یعنی اگر کسی Token را داشته باشد، میتواند بخش Payload را Decode کند و اطلاعات آن را ببیند.
بنابراین نباید اطلاعات حساس مثل:
- رمز عبور
- اطلاعات بانکی
- اطلاعات محرمانه کاربر
را داخل Payload قرار بدهیم.
امنیت JWT بیشتر به اعتبار Signature و مدیریت درست Token بستگی دارد.
JWT در ASP.NET Core چطور استفاده میشود؟
یکی از کاربردهای رایج JWT در پروژههای ASP.NET Core، محافظت از Web APIهاست.
فرض کن یک API برای مدیریت سفارشها داری:
GET /api/orders
نمیخواهی هر کسی بتواند این API را صدا بزند.
بنابراین روی Controller یا Action مربوطه از Authorization استفاده میکنی.
[Authorize]
[HttpGet]
public IActionResult GetOrders()
{
return Ok();
}
حالا فقط درخواستهایی که یک JWT معتبر دارند اجازه عبور پیدا میکنند.
در ASP.NET Core برای این کار معمولاً از JWT Bearer Authentication استفاده میشود.
نصب Package مربوط به JWT
برای استفاده از JWT در ASP.NET Core، اول باید Package مربوط به Authentication با JWT را به پروژه اضافه کنیم.
اگر از .NET CLI استفاده میکنی:
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
این Package امکانات لازم برای بررسی و اعتبارسنجی JWT Tokenها را به پروژه اضافه میکند.
بعد از نصب Package، باید Authentication را در پروژه تنظیم کنیم.
تنظیم JWT و Secret Key
برای اینکه سرور بتواند Tokenها را تولید و اعتبارسنجی کند، نیاز به یک Secret Key داریم.
این کلید برای ایجاد Signature استفاده میشود.
یک نمونه تنظیمات در فایل
appsettings.json
میتواند به این شکل باشد:
{
"Jwt": {
"Key": "your-secret-key-here",
"Issuer": "YourApplication",
"Audience": "YourApplicationUsers"
}
}
اینجا سه مقدار مهم داریم:
- Key: کلیدی که برای امضای Token استفاده میشود.
- Issuer: مشخص میکند این Token توسط چه سیستم یا برنامهای ایجاد شده است.
- Audience: مشخص میکند Token برای چه مصرفکنندهای صادر شده است.
در محیط Production نباید Secret Key را مستقیم داخل فایل تنظیمات قرار بدهیم.
بهتر است از روشهایی مثل Environment Variable، Secret Manager یا سرویسهای مدیریت Secret استفاده کنیم.
تنظیم Authentication در Program.cs
بعد از نصب Package، باید سرویس Authentication را در برنامه ثبت کنیم.
داخل فایل
Program.cs
معمولاً چنین تنظیمی انجام میشود:
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;
var builder = WebApplication.CreateBuilder(args);
var jwtSettings =
builder.Configuration.GetSection("Jwt");
builder.Services
.AddAuthentication(
JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.TokenValidationParameters =
new TokenValidationParameters
{
ValidateIssuer = true,
ValidateAudience = true,
ValidateLifetime = true,
ValidateIssuerSigningKey = true,
ValidIssuer =
jwtSettings["Issuer"],
ValidAudience =
jwtSettings["Audience"],
IssuerSigningKey =
new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(
jwtSettings["Key"]!
))
};
});
این تنظیمات مشخص میکند که ASP.NET Core هنگام دریافت Token چه مواردی را بررسی کند.
مثلاً:
- آیا Token توسط سیستم معتبر ایجاد شده؟
- آیا برای همین برنامه صادر شده؟
- آیا زمان اعتبار آن تمام نشده؟
- آیا Signature درست است؟
Authentication و Authorization Middleware
بعد از ثبت Authentication، باید Middlewareهای مربوط به آن را در Pipeline برنامه فعال کنیم.
در
Program.cs
معمولاً این ترتیب مهم است:
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();
ترتیب این دو خط مهم است.
اول باید Authentication انجام شود تا سیستم بداند کاربر چه کسی است، بعد Authorization بررسی کند که آیا این کاربر اجازه انجام عملیات را دارد یا نه.
ساخت JWT Token
تا اینجا یاد گرفتیم چطور Token را اعتبارسنجی کنیم.
حالا باید ببینیم چطور بعد از ورود موفق کاربر، یک JWT Token ایجاد کنیم.
معمولاً این کار در سرویس Login انجام میشود.
یک نمونه ساده:
public string GenerateToken(User user)
{
var claims = new[]
{
new Claim(
JwtRegisteredClaimNames.Sub,
user.Id.ToString()),
new Claim(
JwtRegisteredClaimNames.Email,
user.Email),
new Claim(
ClaimTypes.Role,
user.Role)
};
var key =
new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(
"your-secret-key"));
var credentials =
new SigningCredentials(
key,
SecurityAlgorithms.HmacSha256);
var token =
new JwtSecurityToken(
issuer: "YourApplication",
audience: "YourApplicationUsers",
claims: claims,
expires:
DateTime.UtcNow.AddMinutes(30),
signingCredentials:
credentials
);
return new JwtSecurityTokenHandler()
.WriteToken(token);
}
در این مثال چند مرحله اتفاق میافتد:
- اطلاعات مورد نیاز کاربر به شکل Claim ساخته میشود.
- Secret Key برای ایجاد Signature استفاده میشود.
- زمان انقضای Token مشخص میشود.
- در نهایت Token به یک رشته متنی تبدیل میشود.
نتیجه این متد همان رشتهای است که Client دریافت میکند و در درخواستهای بعدی ارسال میکند.
محافظت از API با [Authorize]
حالا که Authentication آماده شده، میتوانیم APIهای خودمان را محافظت کنیم.
برای مثال:
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
[Authorize]
[HttpGet]
public IActionResult GetOrders()
{
return Ok(
"User can see orders");
}
}
حالا اگر کاربر بدون Token معتبر این API را صدا بزند، درخواست رد میشود.
ولی اگر Header مناسب ارسال شود:
Authorization: Bearer your_token_here
درخواست اجازه عبور پیدا میکند.
دریافت اطلاعات کاربر از JWT
یکی از مزیتهای JWT این است که بعد از اعتبارسنجی Token، اطلاعات Claimها در اختیار برنامه قرار میگیرد.
مثلاً داخل Controller میتوانی شناسه کاربر را دریافت کنی:
var userId =
User.FindFirst(
ClaimTypes.NameIdentifier)
?.Value;
یا Role کاربر را بخوانی:
var role =
User.FindFirst(
ClaimTypes.Role)
?.Value;
این اطلاعات معمولاً برای کنترل دسترسیها استفاده میشوند.
مثلاً:
[Authorize(Roles = "Admin")]
public IActionResult DeleteUser(int id)
{
return Ok();
}
در این حالت فقط کاربرانی که Role آنها Admin است اجازه اجرای این متد را دارند.
Access Token و Refresh Token
در پروژههای ساده ممکن است فقط از یک JWT Token استفاده کنیم، اما در پروژههای واقعی معمولاً با دو مفهوم مهم روبهرو میشویم:
- Access Token
- Refresh Token
Access Token همان Token اصلی است که برای دسترسی به APIها استفاده میشود.
معمولاً زمان اعتبار Access Token کوتاه در نظر گرفته میشود.
مثلاً:
Expiration: 15 minutes
دلیل این کار افزایش امنیت است. چون اگر کسی به Token دسترسی پیدا کند، فقط برای مدت کوتاهی میتواند از آن استفاده کند.
اما اگر کاربر بعد از ۱۵ دقیقه مجبور باشد دوباره Login کند، تجربه کاربری خوبی نخواهد بود.
اینجا Refresh Token وارد میشود.
Refresh Token معمولاً عمر طولانیتری دارد و برای گرفتن یک Access Token جدید استفاده میشود.
| ویژگی | Access Token | Refresh Token |
|---|---|---|
| کاربرد | دسترسی به APIها | گرفتن Access Token جدید |
| زمان اعتبار | کوتاهتر | طولانیتر |
| ارسال در هر Request | بله | معمولاً خیر |
| سطح ریسک | کمتر به دلیل عمر کوتاه | حساستر چون عمر بیشتری دارد |
در معماریهای حرفهای معمولاً Refresh Token با دقت بیشتری مدیریت میشود.
مثلاً:
- در دیتابیس ذخیره میشود.
- قابلیت لغو شدن دارد.
- برای هر کاربر مدیریت جداگانه دارد.
JWT یا Session؟
یکی از سؤالهای رایج این است که:
«آیا JWT جای Session را گرفته است؟»
جواب این است که هر کدام کاربرد خودش را دارد.
Session و JWT دو روش متفاوت برای مدیریت وضعیت ورود کاربر هستند.
| موضوع | Session | JWT |
|---|---|---|
| محل نگهداری اطلاعات | معمولاً سمت Server | داخل Token سمت Client |
| نیاز به ذخیره وضعیت در Server | دارد | معمولاً ندارد |
| مناسب برای | برنامههای سنتی وب | APIها و معماریهای توزیعشده |
| مدیریت لغو دسترسی | سادهتر | نیازمند طراحی دقیقتر |
برای مثال در یک برنامه MVC سنتی با ASP.NET Core، Session میتواند انتخاب مناسبی باشد.
ولی وقتی یک Backend API داریم که چند Client مختلف مثل Web، Mobile یا Desktop به آن وصل میشوند، JWT معمولاً انتخاب رایجتری است.
اشتباهات رایج در استفاده از JWT
JWT خودش باعث امنیت برنامه نمیشود.
اگر درست پیادهسازی نشود، حتی میتواند باعث ایجاد مشکل امنیتی شود.
چند اشتباه رایج:
۱. قرار دادن اطلاعات حساس داخل Payload
همانطور که گفتیم، Payload رمزنگاری نشده است.
بنابراین اطلاعات محرمانه را نباید داخل آن قرار داد.
۲. استفاده از Secret Key ضعیف
Secret Key باید طول و پیچیدگی مناسبی داشته باشد.
استفاده از کلیدهای ساده مثل:
123456
secret
password
امنیت Token را کاهش میدهد.
۳. زمان انقضای خیلی طولانی
اگر یک Token برای مدت خیلی طولانی معتبر باشد، در صورت سرقت Token، مهاجم زمان بیشتری برای استفاده از آن دارد.
۴. ذخیرهسازی ناامن Token
محل نگهداری Token در سمت Client اهمیت زیادی دارد.
باید با توجه به نوع برنامه، روش ذخیرهسازی مناسب انتخاب شود.
۵. نادیده گرفتن HTTPS
JWT باید در ارتباط امن ارسال شود.
ارسال Token روی HTTP معمولی میتواند باعث افشای اطلاعات شود.
تست JWT با Swagger و Postman
بعد از پیادهسازی JWT، باید رفتار Authentication را تست کنیم.
دو ابزار رایج برای این کار:
- Swagger
- Postman
تست با Swagger
در پروژههای ASP.NET Core معمولاً Swagger برای تست APIها استفاده میشود.
برای اضافه کردن امکان وارد کردن JWT:
builder.Services
.AddSwaggerGen(options =>
{
options.AddSecurityDefinition(
"Bearer",
new OpenApiSecurityScheme
{
Name = "Authorization",
Type = SecuritySchemeType.Http,
Scheme = "Bearer",
BearerFormat = "JWT",
In = ParameterLocation.Header
});
});
بعد از اجرا، در Swagger یک دکمه Authorize اضافه میشود.
Token را به شکل زیر وارد میکنیم:
Bearer your_token_here
تست با Postman
در Postman کافی است:
- Request خود را ایجاد کنیم.
- وارد بخش Authorization شویم.
- نوع Bearer Token را انتخاب کنیم.
- JWT Token را وارد کنیم.
حالا Request همراه Token ارسال میشود.
نکات امنیتی JWT در Production
وقتی یک پروژه از حالت آموزشی خارج میشود و وارد محیط واقعی میشود، موضوع امنیت JWT اهمیت خیلی بیشتری پیدا میکند.
در یک پروژه واقعی فقط ساختن Token کافی نیست؛ باید چرخه کامل مدیریت Token را درست طراحی کنیم.
چند نکته مهم:
استفاده از HTTPS
JWT باید همیشه روی ارتباط امن ارسال شود.
اگر ارتباط بین Client و Server امن نباشد، امکان سرقت Token وجود دارد.
بنابراین در محیط Production استفاده از HTTPS یک الزام است.
مدیریت صحیح Secret Key
Secret Key یکی از مهمترین بخشهای امنیت JWT است.
این مقدار نباید داخل کد قرار بگیرد:
var key = "my-secret-key";
چون با قرار گرفتن کد در Repository یا دسترسی افراد دیگر، کل امنیت Tokenها به خطر میافتد.
روشهای بهتر:
- Environment Variable
- Secret Manager
- سرویسهای مدیریت Secret
تعیین زمان انقضای مناسب
زمان اعتبار Token باید با نیاز پروژه هماهنگ باشد.
Tokenهایی با عمر خیلی طولانی، در صورت سرقت ریسک بیشتری ایجاد میکنند.
معمولاً برای کاهش ریسک، Access Tokenها با زمان کوتاهتر و همراه Refresh Token استفاده میشوند.
بررسی همه Validationها
هنگام تنظیم JWT نباید Validationها را غیرفعال کنیم.
مواردی مثل:
- بررسی Issuer
- بررسی Audience
- بررسی Expiration
- بررسی Signature
باید با توجه به معماری پروژه فعال باشند.
JWT در معماری واقعی ASP.NET Core
در یک پروژه واقعی، JWT فقط یک خط کد در Controller نیست.
معمولاً یک جریان کامل برای مدیریت Authentication داریم.
یک معماری ساده میتواند این شکل را داشته باشد:
تصویر 3
- کاربر اطلاعات Login را ارسال میکند.
- Controller درخواست ورود را دریافت میکند.
- Service مربوط به Authentication اطلاعات کاربر را بررسی میکند.
- در صورت موفقیت JWT Token ساخته میشود.
- Client Token را دریافت و نگهداری میکند.
- درخواستهای بعدی همراه Token ارسال میشوند.
در پروژههای حرفهای معمولاً مسئولیتها جدا میشوند:
| بخش | مسئولیت |
|---|---|
| Controller | دریافت Request و برگرداندن Response |
| Authentication Service | بررسی کاربر و ساخت Token |
| Token Service | ایجاد و مدیریت JWT |
| Database | نگهداری اطلاعات کاربران و دسترسیها |
این جداسازی باعث میشود کد قابل نگهداریتر باشد و تغییرات آینده راحتتر انجام شوند.
مسیر یادگیری JWT و Authentication
اگر تازه وارد دنیای Backend شدهای، بهتر است JWT را جدا از مفاهیم پایه یاد نگیری.
برای اینکه واقعاً بفهمی JWT چه کاری انجام میدهد، این مسیر منطقیتر است:
- یادگیری HTTP و مفهوم Request و Response
- آشنایی با API و REST API
- یادگیری Authentication و Authorization
- کار با Identity در ASP.NET Core
- پیادهسازی JWT Authentication
- مدیریت Role و Permission
- آشنایی با Refresh Token
خیلی از مشکلاتی که برنامهنویسها هنگام کار با JWT دارند، به این دلیل است که فقط نحوه ساخت Token را یاد گرفتهاند ولی معماری Authentication را درست درک نکردهاند.
دوره پروژهمحور C# و ASP.NET Core
اگر نمیخوای فقط مفاهیم Authentication و JWT رو حفظ کنی، قدم بعدی اینه که همین مفاهیم رو داخل یک پروژه واقعی پیادهسازی کنی.
در یک پروژه واقعی باید یاد بگیری چطور Web API بسازی، ورود کاربر را مدیریت کنی، JWT Token ایجاد کنی و دسترسی کاربران را کنترل کنی.
در دوره پروژهمحور C# و ASP.NET Core تحلیلداده، همین مسیر از ساخت Backend تا پیادهسازی Authentication و اتصال بخشهای مختلف پروژه تمرین میشود.
مشاهده دوره پروژهمحور C# و ASP.NET Coreیادگیری JWT در یک پروژه واقعی
یاد گرفتن JWT فقط با خواندن چند مثال ساده کامل نمیشود.
زمانی مفهوم آن را بهتر متوجه میشوی که در یک پروژه واقعی ببینی:
- کاربر چطور ثبتنام میکند.
- Login چطور انجام میشود.
- Token چه زمانی ساخته میشود.
- API چطور درخواستهای بدون مجوز را رد میکند.
- Role و Permission چطور روی دسترسیها اثر میگذارند.
در یک پروژه واقعی، JWT فقط یک Token نیست؛ بخشی از معماری امنیت برنامه است.
سوالات متداول درباره JWT
JWT چیست؟
JWT یک استاندارد برای انتقال اطلاعات احراز هویت بین Client و Server است که معمولاً برای Authentication در APIها استفاده میشود.
آیا JWT امن است؟
خود JWT به تنهایی امنیت ایجاد نمیکند.
امنیت آن به نحوه پیادهسازی، مدیریت Secret Key، زمان انقضا، HTTPS و روش نگهداری Token بستگی دارد.
آیا اطلاعات داخل JWT رمزنگاری شدهاند؟
در حالت معمول خیر.
اطلاعات Payload قابل Decode شدن هستند، بنابراین نباید اطلاعات حساس داخل آن قرار داد.
تفاوت JWT و Session چیست؟
در Session اطلاعات سمت Server نگهداری میشوند، ولی در JWT معمولاً اطلاعات لازم داخل Token قرار میگیرد و Server فقط اعتبار آن را بررسی میکند.
آیا JWT فقط برای ASP.NET Core استفاده میشود؟
خیر.
JWT یک استاندارد عمومی است و در زبانها و Frameworkهای مختلف استفاده میشود.
Access Token و Refresh Token چه تفاوتی دارند؟
Access Token برای دسترسی به API استفاده میشود و معمولاً عمر کوتاهتری دارد.
Refresh Token برای گرفتن Access Token جدید استفاده میشود و معمولاً عمر بیشتری دارد.
جمعبندی JWT
JWT یکی از مهمترین مفاهیمی است که هر برنامهنویس Backend هنگام ساخت APIهای واقعی باید یاد بگیرد.
اما یادگیری JWT فقط حفظ کردن چند خط کد برای ساخت Token نیست.
باید بدانیم:
- Authentication چگونه کار میکند.
- Authorization چه نقشی دارد.
- Token چگونه ساخته و اعتبارسنجی میشود.
- دسترسی کاربران چگونه کنترل میشود.
- چه نکات امنیتی را باید در Production رعایت کنیم.
وقتی JWT را در کنار ASP.NET Core Web API، Identity، Role و Permission یاد بگیری، میتوانی APIهایی بسازی که ساختار امنیتی واقعیتری دارند.
مهمترین نکته این است که JWT را به عنوان یک ابزار در معماری نرمافزار ببینی، نه فقط یک قطعه کد آماده.