Refresh Token و چرخه عمر Token

.NET 10 | Rotation، Revocation و Session Security

Refresh Token امکان دریافت Access Token جدید بدون ورود مجدد را فراهم می‌کند. امنیت این چرخه به Storage امن، Rotation، Revocation و تشخیص Reuse وابسته است.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

Refresh Token امکان دریافت Access Token جدید بدون ورود مجدد را فراهم می‌کند. امنیت این چرخه به Storage امن، Rotation، Revocation و تشخیص Reuse وابسته است.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

2. ساختار پیشنهادی در پروژه

Refresh Token خام تنها یک بار به Client داده می‌شود و در Server Hash آن ذخیره می‌گردد. هنگام Refresh، Token قبلی مصرف‌شده علامت‌گذاری و Token جدید صادر می‌شود.

public sealed class RefreshToken
{
    public long Id { get; set; }
    public int UserId { get; set; }
    public string TokenHash { get; set; } = string.Empty;
    public DateTime ExpiresAt { get; set; }
    public DateTime? RevokedAt { get; set; }
    public long? ReplacedByTokenId { get; set; }
}

3. سناریوی اجرایی

در Refresh موفق، Access Token و Refresh Token جدید صادر می‌شوند. اگر Refresh Token مصرف‌شده دوباره ارائه شود، Token Family مربوط می‌تواند به‌عنوان اقدام دفاعی revoke شود.

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

if (stored.RevokedAt is not null || stored.ExpiresAt <= clock.UtcNow)
    throw new InvalidRefreshTokenException();

stored.RevokedAt = clock.UtcNow;
var nextToken = CreateRefreshToken(user.Id);
stored.ReplacedByTokenId = nextToken.Id;

4. اصول طراحی و نگهداری

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

• Refresh Token مانند Password محافظت شود.
• Token خام در Log ثبت نشود.
• Logout و تغییر Credential بتواند Sessionها را revoke کند.
• Device/Session Metadata در صورت نیاز جداگانه نگهداری شود.

5. خطاهای رایج و کنترل آن‌ها

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

• ذخیره Refresh Token خام در Database.
• Refresh Token بدون Expiration.
• عدم Rotation و قابلیت استفاده نامحدود از یک Token.
• نادیده گرفتن Token Reuse پس از سرقت احتمالی.

6. چک‌لیست نهایی فصل

• Hash Token ذخیره می‌شود.
• Rotation در هر Refresh انجام می‌شود.
• Revocation و Logout تست شده‌اند.
• Reuse Detection رفتار مشخص دارد.

7. جمع‌بندی

مفاهیم این فصل زمانی کامل محسوب می‌شوند که هم مسیر موفق و هم مسیر خطا قابل پیش‌بینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.