هر JSON Web Token را رمزگشایی کنید تا هدر، payload و امضای آن را ببینید — یا با HS256/384/512 یکی جدید امضا کنید. امضاهای HMAC بهصورت محلی تأیید میشوند. ۱۰۰٪ در مرورگر شما.
هر JSON Web Token را رمزگشایی کنید تا هدر، payload و امضای آن را ببینید — یا با HS256/384/512 یکی جدید امضا کنید. امضاهای HMAC بهصورت محلی تأیید میشوند. ۱۰۰٪ در مرورگر شما.
نه. کل ابزار جاوااسکریپت داخل همین صفحه است. یک توکن بچسبانید، رمزگشایی در مرورگر شما اتفاق میافتد و بایتها هرگز از تب خارج نمیشوند. DevTools → Network را باز کنید و تماشا کنید — هیچ درخواستی هنگام رمزگشایی یا تأیید ارسال نمیشود. به همین دلیل چسباندن توکنهای واقعی مشتری یا production امن است.
این ثابت میکند که توکن توسط شخصی که رمز (HMAC) یا کلید خصوصی (RSA/ECDSA) را در اختیار دارد امضا شده است. payload را رمزگذاری نمیکند — هدر و payload صرفاً JSON کدشده با base64url هستند و هر کسی که توکن را داشته باشد میتواند آنها را بخواند. امضا فقط جلوی دستکاری را میگیرد: اگر حتی یک بایت از payload را تغییر دهید، امضا دیگر مطابقت نخواهد داشت.
یک JWT اغلب شامل شناسه کاربر، ایمیل، scopes و گاهی معادل کوکیهای نشست است — دقیقاً همان دادههایی که نباید در سرور یک غریبه چسبانده شوند. رمزگشای iKit بهعنوان جاوااسکریپتی که از قبل در تب مرورگر شما بارگذاری شده اجرا میشود. در DevTools → Network قابل تأیید است: هیچ fetch، XHR یا beacon در طول رمزگشایی یا تأیید وجود ندارد.
برای توکنهای HS256/384/512، رمز امضا را تایپ کنید تا امضا بهصورت محلی تأیید شود. برای RS256/ES256 (RSA/ECDSA) از یک کتابخانه سمت سرور استفاده کنید — تأیید با کلید عمومی نیازمند فایل PEM است که اینجا پشتیبانی نمیکنیم.
HS256 برای استحکام واقعی رمزنگاری به حداقل ۳۲ بایت (۲۵۶ بیت) نیاز دارد. برای آزمایش هر چیزی کار میکند، اما در محیط production باید از یک رمز تصادفی طولانی استفاده کرد.
سریعترین راه برای دیباگ یک JWT — بدون آپلود، بدون ثبتنام، بدون هیچ شخص ثالثی بین شما و توکنتان.
یک JWT را بچسبانید، هدر، payload و امضای رمزگشاییشده را در کنار هم ببینید. claims استاندارد (iss, sub, aud, exp, iat) با مهر زمانی و برچسب نمایش داده میشوند.
برای توکنهای HS256/384/512، رمز را تایپ کنید تا امضا با استفاده از Web Crypto مرورگر تأیید شود. رمز هرگز از تب شما خارج نمیشود.
به حالت Encode بروید، هدر و payload را بهصورت JSON ویرایش کنید، الگوریتم را انتخاب کنید، یک رمز تایپ کنید و فوراً یک توکن امضاشده دریافت کنید.
payloadهای JWT حاوی شناسه کاربران، ایمیلها و گاهی scopeها هستند — هرگز آنها را در یک ابزار سرور نچسبانید. رمزگشای iKit بهعنوان جاوااسکریپت در مرورگر شما اجرا میشود. در DevTools → Network قابل تأیید است.
claims استاندارد مانند exp، nbf و iat با تاریخهای قابل خواندن انسانی و یک نشان واضح منقضیشده / معتبر برجسته میشوند تا با یک نگاه بفهمید توکن هنوز خوب است یا نه.
ساختهشده با Web Crypto بومی مرورگر و JSON parser — همان الگوریتمهای OpenSSL، libjwt، jose. رفتار آن با هر کتابخانه مدرن JWT مطابقت دارد.
یک JWT سه قطعه JSON کدشده با base64url است که با نقطه از هم جدا شدهاند — همین.
یک JWT شبیه aaa.bbb.ccc است. ما بر اساس دو نقطه واقعی تقسیم میکنیم تا هدر، payload و امضای کدشده را بهدست آوریم. اگر دقیقاً سه بخش بهدست نیاوریم، توکن خراب است.
هدر و payload بهصورت JSON با UTF-8 و کدگذاری base64url هستند. Base64URL = Base64 با -/_ بهجای +//= و بدون padding. ما پس از جایگزینی کاراکترها، atob را اجرا میکنیم و سپس رشته حاصل را با JSON.parse تجزیه میکنیم.
هدر الگوریتم (alg: HS256، RS256 و غیره) و typ را به ما میگوید. payload شامل claims است — موارد استاندارد (iss، sub، aud، exp، iat، nbf، jti) بهعلاوه هر فیلد سفارشی. ما هر کدام را در یک بخش برچسبدار نمایش میدهیم.
برای HS256/384/512، ما HMAC مربوط به header.payload را با استفاده از رمزی که تایپ کردهاید مجدداً محاسبه کرده و با امضای موجود در بخش سوم مقایسه میکنیم. مشابه HMAC(SHA-256, secret, signing_input) کدشده با base64url. تطابق = امضای معتبر.
موقعیتهای واقعی که در آنها به سراغ یک رمزگشای JWT میروید.
Auth0، Firebase، Keycloak و AWS Cognito همگی پس از ورود JWT برمیگردانند. access_token را بچسبانید تا ببینید برنامه شما واقعاً چه claimsای دریافت میکند — شناسه کاربر چیست، چه scopeهایی دارد، چه زمانی منقضی میشود؟
API درخواست شما را رد میکند؟ توکن را رمزگشایی کنید تا بررسی کنید: آیا منقضی شده است (exp در گذشته)؟ آیا claim مخاطب (aud) همان چیزی است که API انتظار دارد؟ آیا صادرکننده (iss) tenant درست است؟
Stripe، GitHub Apps و Slack payloadهای webhook را بهصورت امضاشده در قالب JWT ارسال میکنند. پس از دریافت یکی، آن را بههمراه رمز مشترک در حالت Decode بچسبانید تا تأیید شود درخواست واقعاً از طرف آنها بوده است.
به یک JWT امضاشده تازه برای تست یکپارچهسازی نیاز دارید؟ به حالت Encode بروید، payload را ویرایش کنید (شناسه کاربر سفارشی، انقضای سفارشی)، HS256 + رمز آزمایشی خود را انتخاب کنید و در عرض میلیثانیه یک توکن دریافت کنید. بدون رفتوبرگشت با backend.
یک JWT اغلب شامل شناسه کاربر، ایمیل، scopes و گاهی معادل کوکیهای نشست است — دقیقاً همان دادههایی که نباید در سرور یک غریبه چسبانده شوند. رمزگشای iKit بهعنوان جاوااسکریپتی که از قبل در تب مرورگر شما بارگذاری شده اجرا میشود. در DevTools → Network قابل تأیید است: هیچ fetch، XHR یا beacon در طول رمزگشایی یا تأیید وجود ندارد.
آموزشهای تخصصی و مقایسه ابزارها از وبلاگ iKit.
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
نه. کل ابزار جاوااسکریپت داخل همین صفحه است. یک توکن بچسبانید، رمزگشایی در مرورگر شما اتفاق میافتد و بایتها هرگز از تب خارج نمیشوند. DevTools → Network را باز کنید و تماشا کنید — هیچ درخواستی هنگام رمزگشایی یا تأیید ارسال نمیشود. به همین دلیل چسباندن توکنهای واقعی مشتری یا production امن است.
این ثابت میکند که توکن توسط شخصی که رمز (HMAC) یا کلید خصوصی (RSA/ECDSA) را در اختیار دارد امضا شده است. payload را رمزگذاری نمیکند — هدر و payload صرفاً JSON کدشده با base64url هستند و هر کسی که توکن را داشته باشد میتواند آنها را بخواند. امضا فقط جلوی دستکاری را میگیرد: اگر حتی یک بایت از payload را تغییر دهید، امضا دیگر مطابقت نخواهد داشت.
سه دلیل رایج: (۱) رمز اشتباه — رمزهای JWT به حروف کوچک و بزرگ حساساند و هر اختلاف فاصلهای تأیید را خراب میکند. (۲) عدم تطابق الگوریتم — هدر میگوید HS256 ولی رمز در اصل با HS512 استفاده شده است. (۳) توکن پس از امضا تغییر کرده است — حتی یک بایت امضا را خراب میکند. مطمئن شوید header.alg با چیزی که انتظار دارید مطابقت دارد.
iKit در حال حاضر فقط از تأیید HMAC (HS256/384/512) پشتیبانی میکند. RS256 و ES256 از رمزنگاری کلید عمومی استفاده میکنند — تأیید نیازمند کلید عمومی صادرکننده در قالب PEM است که UI پیچیدهتری میطلبد. فعلاً رمزگشایی همچنان کار میکند (بخشهای هدر/payload/امضا بهدرستی نمایش داده میشوند)، اما دکمه «تأیید» میگوید پشتیبانی نمیشود. تأیید RSA/ECDSA در برنامه است.
ایده یکسان، پیشفرضهای متفاوت. رمزگشای iKit کاملاً در مرورگر شما اجرا میشود (jwt.io هم همین کار را میکند، اما کد iKit برای view-source باز است و دامنه ما هیچ ردیاب شخص ثالثی ندارد). ما یک نشان واضح منقضیشده / معتبر برای claim exp، یادداشتهای ساختاریافته (iat / nbf / iss / sub / aud / jti بهصورت ردیفهای قابل خواندن) و یک دکمه کپی همهچیز اضافه کردهایم که خروجی ساختاریافته کامل را برای چسباندن در گزارش باگ به شما میدهد.