عیبیابی JWT
خطای ۴۰۱ با توکنی که سالم به نظر میرسد تقریباً همیشه یکی از شش علت را دارد. این صفحه توکن را همانطور نشان میدهد که سرور میخواند تا بفهمید کدام است.
برای آزمودن یک سرویس، توکن خودتان را امضا کنید. همهچیز در همین صفحه محاسبه میشود.
کلید و توکن ساختهشده در مرورگر شما میمانند؛ هیچکدام جایی فرستاده نمیشوند و در پیوند همرسانی هم نمیآیند.
این توکن را در کد خودتان بررسی کنید. نمونهکد از الگوریتمی که در هدر آمده پیروی میکند.
عیبیابی توکنی که پذیرفته نمیشود
توکنها به شمار انگشتشماری راه شکست میخورند و هیچکدام در خود توکن دیده نمیشود؛ توکن سه تکه Base64URL است با نقطه در میانشان. اینجا که بچسبانیدش به چیزی بدل میشود که میتوان با آن بحث کرد: هر فیلد هدر و هر کلیم در جدولی که میگوید هر کدام برای چیست، انقضا ترجمهشده به زبان ساده، و امضا سنجیدهشده با هر کلیدی که در دست دارید.
رمزگشایی همان حین تایپ انجام میشود و چیزی جایی فرستاده نمیشود. در چنین صفحهای باید این را صریح گفت، چون آنچه میخواهید بچسبانید یک گواهی فعال برای حساب کسی است.
شش شکست، به ترتیبی که بهصرفه است
| چه چیزی خراب است | اینجا چطور دیده میشود | چاره |
|---|---|---|
| منقضی شده | خط بالای هدر میگوید «منقضی شده است» | توکن را تازه کنید؛ اگر فقط چند ثانیه است ساعتها را ببینید |
| مخاطب اشتباه | aud نام API دیگری را میبرد | توکن را برای همان مخاطبی بگیرید که API انتظار دارد |
| صادرکننده اشتباه | iss نشانی محیط آزمایشی است نه محیط اصلی | کلاینت را به صادرکننده درست بگیرید، یا API را |
| کلید اشتباه | بررسی امضا میگوید امضا مطابقت ندارد | همان کلیدی را بگذارید که صادرکننده با آن امضا کرده؛ مراقب کلیدهای Base64 باشید |
| الگوریتم اشتباه | هدر ES256 میگوید و کلید شما RSA است | کلید را با الگوریتمی که کنار کادر کلید نوشته شده جور کنید |
| اصلاً JWS نیست | صفحه آن را JWE با پنج بخش مینامد | پیلود رمزنگاری شده؛ آن را جایی بخوانید که کلید رمزگشایی هست |
ترتیب مهم است. انقضا و مخاطب نه کلید میخواهند و نه همکاری کسی، پس در چند ثانیه کنار میروند؛ دنبال کردن یک مشکل امضا که آخرش ناسازگاری aud از آب درمیآید، همان چیزی است که یک بعدازظهر را میبلعد.
خواندن با بررسی کردن یکی نیست
همینجاست که آدمها میلغزند. رمزگشایی میگوید توکن چه ادعایی دارد؛ درباره درستی آن ادعا چیزی نمیگوید، چون هدر و پیلود کدگذاری شدهاند نه رمزنگاری، و هر کسی میتواند مال خودش را بنویسد. بررسی یعنی بازمحاسبه امضا با کلید محرمانه یا عمومی صادرکننده — کاری که این صفحه در مرورگر شما میکند — و تنها همین گام است که ادعا را به واقعیت بدل میکند.
پس نمای رمزگشاییشده را برای ساختن فرضیه به کار ببرید و دکمه بررسی امضا را برای آزمودنش؛ و در کد خودتان هرگز تصمیم مجوزدهی را روی محتوای رمزگشاییشده بنا نکنید. زبانه «کد» دقیقاً به همین دلیل بررسی سمت سرور را در هشت زبان مینویسد. اگر خودِ کدگذاری برایتان گیجکننده است، تفاوت Base64 و Base64URL توضیح میدهد چرا یک بخش JWT را نمیشود همینطوری در یک رمزگشای معمولی Base64 چسباند.
چیزهایی که شبیه مشکل توکناند و نیستند
- واژه
Bearerکه همراه توکن کپی شده، یا یک خط تازه که از ترمینال آمده؛ هر دو ورودی امضا را عوض میکنند و امضا را میشکنند. - توکنی که نمایشگر لاگ کوتاهش کرده. بخش امضا برای هر الگوریتم طول ثابتی دارد، پس توکن بریده همیشه رد میشود.
- دو سرویس که کلید محرمانه مشترکی دارند و یکیشان آن را Base64 ذخیره میکند. گزینه کلید بهصورت Base64 است را بزنید تا همان سمت را بازسازی کنید.
- یک
kidکه دیگر وجود ندارد چون صادرکننده کلیدهایش را چرخانده؛ توکن سالم است و مجموعه کلیدها کهنه.
وقتی خود توکن تبرئه شد، متهمهای باقیمانده سمت سرورند: میانافزاری که هرگز بررسی نمیکند، ساعتی که میلغزد، حافظه نهانی که مجموعه کلید قدیمی را نگه داشته. اگر برای آزمودن هر کدام به توکنی در وضعیت مشخص نیاز دارید — منقضی، معتبر، یا امضاشده با کلیدی که خودتان دارید — تولید JWT آن را میسازد و بررسی انقضای توکن میگوید یک بررسیکننده کلیمهای زمان را چطور میخواند.