تولید JWT
برای آزمودن یک سرویس، توکن خودتان را امضا کنید؛ با همان دوازده الگوریتمی که یک صادرکننده واقعی به کار میبرد و بدون اینکه کلید هرگز از مرورگرتان بیرون برود.
برای آزمودن یک سرویس، توکن خودتان را امضا کنید. همهچیز در همین صفحه محاسبه میشود.
کلید و توکن ساختهشده در مرورگر شما میمانند؛ هیچکدام جایی فرستاده نمیشوند و در پیوند همرسانی هم نمیآیند.
این توکن را در کد خودتان بررسی کنید. نمونهکد از الگوریتمی که در هدر آمده پیروی میکند.
ساختن یک JSON Web Token امضاشده
بیشتر کار با توکنها خواندن آنهاست، کاری که رمزگشای JWT انجام میدهد. گاهی جهت عکس لازم است: توکنی که هنوز وجود ندارد، تا ببینید یک سرویس چه واکنشی نشان میدهد. یک API آزمایشی که همه چیز را رد میکند، میانافزاری که تازه مینویسید، یا دادهای برای تست که باید پنج دقیقه دیگر منقضی شود؛ همه به توکنی نیاز دارند که در اختیار خودتان باشد، و همین صفحه آن را امضا میکند.
صفحه روی زبانه ساخت توکن باز میشود. هر چه آنجاست — منوی الگوریتم، پیلود و کلید — با crypto.subtle.sign در مرورگر خودتان ساخته و امضا میشود. در هیچ مرحلهای درخواستی به سرور نمیرود، پس کلیدی که میچسبانید بهاندازه همان زبانهای که در آن تایپ شده خصوصی است.
در پایان چه چیزی در هدر و پیلود مینشیند
هدر را صفحه برایتان مینویسد: الگوریتمی که انتخاب کردهاید و typ: "JWT"، بهعلاوه یک kid اگر آن فیلد را پر کنید. شناسه کلید وقتی اهمیت دارد که سرویس گیرنده چند کلید نگه میدارد و یکی را با نام انتخاب میکند؛ اگر خالی بماند، هدر با دو فیلد میماند.
پیلود مال شماست. دو کلیم نه: هنگام امضا همیشه iat با زمان کنونی مهر میخورد و exp از منوی انقضا پس از تنظیم میشود — پنج دقیقه، یک ساعت، یک روز، سی روز، یا هیچ. وقتی توکن ظاهر شد، کادر پیلود با همان چیزی که واقعاً امضا شده بازنویسی میشود، پس زمانهایی که میبینید همانهاییاند که درون توکن نشستهاند. اگر همین دو کلیم موضوع آزمون شماست، بررسی انقضای توکن توضیح میدهد سرور چطور آنها را میخواند.
انتخاب الگوریتم
دوازده الگوریتم در دو خانواده جا میگیرند، و تفاوتشان نه در قدرت که در این است که چه کسی باید کلید را نگه دارد.
| خانواده | کلیدی که میچسبانید | وقتی به کار میآید که |
|---|---|---|
| HS256 / HS384 / HS512 | یک کلید مشترک، بهصورت متن یا Base64 | یک سرویس هم توکن را صادر میکند و هم خودش بررسی میکند |
| RS256 / RS384 / RS512 | کلید خصوصی PKCS#8 (PEM) یا JWK | سرویسهای متعدد بررسی میکنند و فقط نیمه عمومی را میبینند |
| PS256 / PS384 / PS512 | همان کلید خصوصی RSA | RSA با لایهگذاری تازهتر PSS، وقتی گیرنده آن را میخواهد |
| ES256 / ES384 / ES512 | کلید خصوصی EC روی P-256 / P-384 / P-521 | امضای کوتاه و کلید کوچک میخواهید |
HS256 پیشفرض است چون معمولاً همان چیزی است که آدمها آزمایش میکنند: یک کلید محرمانه در متغیر محیطی و یک سرویس در هر دو سر. بهمحض اینکه بیش از یک سرویس باید توکن را بررسی کند، الگوریتم کلید عمومی شکل بهتری است، چون هرگز لازم نیست به بررسیکننده چیزی بسپارید که بتواند با آن توکن بسازد.
توکن ساختهشده به چه درد میخورد و به چه دردی نمیخورد
توکنی که اینجا امضا میشود توکن واقعی است: آن را در رمزگشای بالا بچسبانید، با همان کلید بررسی امضا را بزنید و امضا درست درمیآید، چون صفحه آن را دقیقاً مثل هر کتابخانهای حساب میکند. همین آن را برای دادههای آزمون، برای بازسازی یک باگ با توکن منقضی یا هنوز نامعتبر، و برای اینکه بفهمید میانافزارتان واقعاً aud را بررسی میکند یا فقط میخواندش، به کار میآورد.
آنچه نیست، راه ورود است. توکن را فقط سرویسی میپذیرد که کلید متناظرش را داشته باشد، پس امضا کردن یکی با کلید محرمانه خودتان برای هیچکس دیگری چیزی ثابت نمیکند. کار امضا دقیقاً همین است، و به همین دلیل تفاوت توکن و کوکی نشست به این میرسد که چه کسی باید چه چیزی را نگه دارد.
کلیدها، قالبها و خطاهایی که میسازند
برای خانواده HS، کلید محرمانه را همانطور که هست بچسبانید، یا اگر پیکربندی شما آن را کدشده نگه میدارد گزینه کلید بهصورت Base64 است را بزنید: یک رشته یکسان، خام و رمزگشاییشده، دو امضای کاملاً متفاوت میدهد و همین یکی از دلیلهای رایج آن است که توکنی در یک جا کار میکند و در جای دیگر نه.
برای RS و PS و ES، مرورگر یک PEM از نوع PKCS#8 را میپذیرد — بلوکی که با -----BEGIN PRIVATE KEY----- شروع میشود — یا یک JWK، همان قالب JSON که مجموعه کلیدها با آن پخش میشود. بلوک قدیمیتر -----BEGIN RSA PRIVATE KEY----- از نوع PKCS#1 است و اول باید تبدیل شود. اگر بهاشتباه کلید عمومی بچسبانید، صفحه همین را میگوید و با خطای نامفهوم شکست نمیخورد، چون کلید عمومی میتواند امضا را بررسی کند اما هرگز نمیتواند امضا بسازد.