بازگشت

JWT Decoder

رمزنگاری

رمزگشایی و بررسی انقضای توکن JWT

آفلاین داده‌های شما روی مرورگر رمزنگاری

ساخت توکن JWT (Encoder)

تبدیل Unix Timestamp

Unix timestamp فعلی:

JWT چیست و چرا در توسعه وب اهمیت دارد؟

اگر با احراز هویت در API، OAuth2 یا سیستم‌های مدرن تک‌صفحه‌ای (SPA) کار کرده باشید، حتماً با توکن‌های JWT روبرو شده‌اید. JSON Web Token یا JWT (تلفظ: «جاتی») یک استاندارد باز بر اساس RFC 7519 است که روشی فشرده و URL-safe برای انتقال اطلاعات بین دو طرف به‌صورت امضاشده ارائه می‌دهد. برخلاف session‌های سنتی که نیاز به ذخیره‌سازی روی سرور دارند، JWT تمام اطلاعات لازم را درون خودش دارد — به همین دلیل برای معماری‌های microservice و APIهای stateless بسیار مناسب است.

ساختار توکن JWT

هر JWT از سه بخش جدا شده با نقطه تشکیل می‌شود: header.payload.signature. هر بخش با Base64Url کدگذاری شده است (نه رمزنگاری‌شده!) و بنابراین قابل رمزگشایی بدون نیاز به کلید است:

  • Header: الگوریتم امضا (مثل HS256، RS256) و نوع توکن (JWT). مثلاً: {"alg":"HS256","typ":"JWT"}
  • Payload (Claims): اطلاعات کاربر و متادیتا. شامل claim‌های استاندارد مثل sub (شناسه کاربر)، exp (انقضا)، iat (زمان صدور)، iss (صادرکننده) و claim‌های سفارشی.
  • Signature: امضای HMAC یا RSA روی header+payload با کلید مخفی. این بخش تضمین می‌کند توکن دستکاری نشده.

Claim های استاندارد JWT

RFC 7519 مجموعه‌ای از claim‌های ثبت‌شده تعریف می‌کند که هر ابزار JWT decoder باید آن‌ها را بشناسد:

  • iss (Issuer): سرویسی که توکن را صادر کرده — مثلاً https://auth.example.com
  • sub (Subject): شناسه‌ی یکتای کاربر یا موجودیت
  • aud (Audience): مخاطب مجاز توکن
  • exp (Expiration Time): Unix timestamp انقضای توکن — بررسی این فیلد در هر اعتبارسنجی الزامی است
  • nbf (Not Before): توکن قبل از این زمان معتبر نیست
  • iat (Issued At): زمان دقیق صدور توکن
  • jti (JWT ID): شناسه‌ی یکتا برای جلوگیری از replay attack

آسیب‌پذیری‌های رایج JWT که باید بدانید

استفاده‌ی نادرست از JWT می‌تواند منجر به آسیب‌پذیری‌های جدی شود. آشنایی با این حملات برای هر توسعه‌دهنده‌ی وب ضروری است:

  • Algorithm None Attack: اگر سرور توکن با alg: none را بپذیرد، مهاجم می‌تواند بدون امضا توکن جعلی بسازد. همیشه الگوریتم را در سرور whitelist کنید.
  • Key Confusion (RS256→HS256): اگر سرور RSA public key را به‌عنوان HMAC secret استفاده کند، مهاجم می‌تواند با public key توکن امضا کند.
  • Missing Expiration: توکن بدون exp هرگز منقضی نمی‌شود — هر توکن leaked برای همیشه معتبر است.
  • Weak Secret: استفاده از کلیدهای ضعیف مثل «secret» یا «password» امکان brute-force را ساده می‌کند.

ابزار JWT Decoder وزیروب

با این ابزار می‌توانید توکن JWT را رمزگشایی کرده، تمام claim‌ها را به‌صورت خوانا مشاهده کنید و بررسی انقضا را با یک شمارش معکوس زنده ببینید. قابلیت تأیید امضا با HMAC-SHA256/384/512، بررسی خودکار آسیب‌پذیری‌های رایج، ساخت توکن JWT جدید (Encoder) با کلید دلخواه، و تبدیل Unix timestamp هم پشتیبانی می‌شود. تمام پردازش‌ها در مرورگر انجام می‌شود — توکن هرگز به سرور ارسال نمی‌شود.

سوالات متداول

پاسخ سوالات رایج درباره این ابزار

آیا می‌توان JWT را بدون کلید مخفی رمزگشایی کرد؟

بله. بخش‌های header و payload در JWT فقط با Base64Url کدگذاری شده‌اند، نه رمزنگاری. هر کسی می‌تواند محتوای آن‌ها را بخواند. به همین دلیل هرگز اطلاعات حساس مثل رمز عبور یا اطلاعات کارت بانکی را در payload JWT قرار ندهید. کلید مخفی فقط برای تأیید اینکه توکن دستکاری نشده لازم است.

تفاوت JWT با Session Token چیست؟

Session Token یک کلید تصادفی است که سرور باید در database بررسی کند (stateful). JWT خودش اطلاعات لازم را دارد و سرور می‌تواند آن را بدون database تأیید کند (stateless). JWT برای microserviceها و APIها ایده‌آل است ولی امکان revoke کردن آنی ندارد — برای logout آنی باید از blacklist یا refresh token استفاده کنید.

فیلد exp در JWT چیست و چطور بررسی می‌شود؟

exp (Expiration Time) یک Unix timestamp است که نشان می‌دهد توکن تا چه زمانی معتبر است. سرور باید در هر درخواست exp را با زمان فعلی مقایسه کند — اگر exp از زمان حال کمتر باشد، توکن رد شود. فراموش کردن بررسی exp یکی از آسیب‌پذیری‌های رایج است. ابزار JWT Decoder وزیروب این را با شمارش معکوس زنده نمایش می‌دهد.

HMAC-SHA256 و RS256 در JWT چه تفاوتی دارند؟

HS256 (HMAC-SHA256) یک کلید مشترک (shared secret) استفاده می‌کند — هم برای امضا هم تأیید. مناسب برای سیستم‌های تک‌سرور. RS256 از جفت کلید RSA (public/private) استفاده می‌کند — سرور auth با private key امضا می‌کند، سایر سرویس‌ها با public key تأیید می‌کنند. RS256 برای معماری microservice که چندین سرویس باید توکن را تأیید کنند مناسب‌تر است.