JWT

حاوی متادیتای توکن است: الگوریتم امضا (alg) و نوع توکن (typ). همیشه JSON با رمزگذاری Base64url است. انتخاب الگوریتم در اینجا بر امنیت کل توکن تأثیر می‌گذارد.

{
  "alg": "HS256",
  "typ": "JWT"
}

حاوی ادعاها است: اطلاعاتی درباره کاربر و متادیتای اضافی. همچنین JSON با رمزگذاری Base64url است. هر کسی می‌تواند این بخش را رمزگشایی کند — داده‌های payload رمزگذاری نشده‌اند، فقط امضا شده‌اند.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

یک امضای رمزنگاری بر روی header و payload رمزگذاری‌شده است. تأیید این امضا تضمین می‌کند که توکن دستکاری نشده است. کلید مخفی (HMAC) یا کلید خصوصی (RSA/ECDSA) هرگز در توکن گنجانده نمی‌شود.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

از یک کلید مخفی مشترک هم برای امضا و هم برای تأیید استفاده می‌کند. پیاده‌سازی ساده اما نیاز دارد همه تأییدکنندگان کلید مخفی را بدانند.

از کلید خصوصی برای امضا و کلید عمومی برای تأیید استفاده می‌کند. کلید خصوصی هرگز سرور احراز هویت را ترک نمی‌کند.

مانند RSA اما با کلیدهای کوچک‌تر و امضای سریع‌تر. امنیت معادل با عملکرد بهتر ارائه می‌دهد.

اصلاً هیچ امضایی ندارد. توکنی با alg:none هیچ تضمین یکپارچگی ندارد و می‌تواند توسط هر کسی جعل شود.

برخی کتابخانه‌ها توکن‌هایی با alg:none (بدون امضا) می‌پذیرند. یک مهاجم می‌تواند payload را تغییر داده و alg را به none تنظیم کند تا هر JWT را جعل کند. همیشه الگوریتم مجاز را به صراحت مشخص و اعتبارسنجی کنید.

اگر یک کتابخانه انتظار تأیید RS256 را داشته باشد اما HS256 را هم بپذیرد، یک مهاجم می‌تواند با استفاده از کلید عمومی به عنوان secret در HMAC توکنی امضا کند. کتابخانه آن را با موفقیت تأیید می‌کند. همیشه الگوریتم مورد انتظار را مشخص نگه دارید.

یک JWT بدون ادعای exp، یا کدی که exp را بررسی نمی‌کند، اجازه می‌دهد توکن‌ها پس از خروج یا مسدود شدن کاربر به‌طور نامحدود استفاده شوند. همیشه زمان‌های انقضای کوتاه تنظیم کنید و ادعای exp را اعتبارسنجی کنید.

payload های JWT با Base64 رمزگذاری شده‌اند، نه رمزگذاری واقعی. هر کسی که یک JWT را دریافت کند می‌تواند payload را رمزگشایی و بخواند. هرگز رمز عبور، شماره کارت اعتباری یا سایر اسرار را در ادعاهای JWT ذخیره نکنید.

JWT‌های امضاشده با HMAC با اسرار کوتاه یا قابل پیش‌بینی می‌توانند به صورت آفلاین brute-force شوند. یک مهاجم که یک JWT را به دست آورد می‌تواند میلیاردها کلید در ثانیه امتحان کند. از اسرار تصادفی رمزنگاری با حداقل ۲۵۶ بیت استفاده کنید.

قبول کردن JWT بدون بررسی امضا یعنی اعتماد کامل به محتوای payload. این یک باگ حیاتی است که به هر کاربری اجازه می‌دهد ادعاهای دلخواه بسازد. همیشه قبل از اعتماد به هر ادعایی امضا را تأیید کنید.

JWT‌های استاندارد (JWS — JSON Web Signature) امضا شده‌اند اما رمزگذاری نشده‌اند. payload با Base64url رمزگذاری شده که به سادگی قابل برگشت است. هر کسی که یک JWT داشته باشد می‌تواند محتوای آن را بخواند. JWE (JSON Web Encryption) رمزگذاری واقعی ارائه می‌دهد اما بسیار کمتر رایج است.

توکن‌های دسترسی باید کوتاه‌مدت باشند: ۵ تا ۶۰ دقیقه معمول است. توکن‌های طولانی‌مدت خطرناک هستند زیرا بدون یک لیست مسدود توکن نمی‌توانند باطل شوند. از refresh token‌ها (طولانی‌مدت‌تر، با ذخیره‌سازی امن) برای دریافت توکن‌های دسترسی جدید استفاده کنید.

کوکی‌های HttpOnly امن‌ترین گزینه هستند — برای JavaScript غیرقابل دسترسی هستند و از سرقت XSS جلوگیری می‌کنند. localStorage در برابر حملات XSS آسیب‌پذیر است اما از CSRF جلوگیری می‌کند. حافظه (متغیر JavaScript) امن‌ترین است اما پس از reload صفحه باقی نمی‌ماند. هیچ گزینه کاملی وجود ندارد.

نه بدون وضعیت سمت سرور. ماهیت بدون وضعیت JWT‌ها به این معناست که سرور نمی‌تواند آن‌ها را باطل کند. راه‌حل‌ها: زمان‌های انقضای کوتاه، یک لیست مسدود توکن (Redis)، چرخش refresh token‌ها، یا تغییر به توکن‌های session مات برای عملیات حساس.

کوکی‌های session یک شناسه session تصادفی ذخیره می‌کنند؛ سرور داده‌های session را جستجو می‌کند. JWT‌ها خودکفا هستند — سرور امضا را بدون جستجوی پایگاه داده اعتبارسنجی می‌کند. JWT‌ها در چندین سرور بهتر مقیاس‌پذیر هستند اما بدون زیرساخت اضافی نمی‌توانند باطل شوند.

حداقل: sub (شناسه کاربر)، exp (انقضا) و iat (زمان صدور). برای راه‌اندازی‌های چند سرویسه iss (صادرکننده) اضافه کنید. payload‌ها را کوچک نگه دارید — JWT‌ها با هر درخواست ارسال می‌شوند. داده‌های حساس یا آبجکت‌های بزرگ پروفایل را در ادعاها قرار ندهید.

RS256 (نامتقارن) برای اکثر سیستم‌های تولید بهتر است زیرا فقط سرور احراز هویت به کلید خصوصی نیاز دارد. سرویس‌های متعدد می‌توانند با استفاده از کلید عمومی توکن‌ها را بدون اشتراک‌گذاری secret تأیید کنند. HS256 ساده‌تر است اما نیاز دارد همه تأییدکنندگان secret مشترک را بدانند.

PKCE (Proof Key for Code Exchange) یک افزونه برای جریان کد مجوز OAuth2 است که از حملات دزدیدن کد مجوز جلوگیری می‌کند. برای کلاینت‌های عمومی (SPA‌ها، برنامه‌های موبایل) که نمی‌توانند client secret را به صورت امن ذخیره کنند الزامی است.