tigtools

מחולל JWT

בנו וחתמו JSON Web Token לבדיקות, או בדקו אם חתימת ה‑HMAC של אסימון תואמת לסוד. החתימה משתמשת ב‑Web Crypto API של הדפדפן שלכם.

פועל בדפדפן שלך ללא הרשמה

מצב
הסוד נשאר בלשונית הדפדפן הזו ולעולם לא נשלח לשום מקום. עם זאת, אל תדביקו סודות חתימה של סביבת ייצור באף אתר: כל מי שיש לו את הסוד יכול ליצור אסימונים תקינים למערכת שלכם. השתמשו כאן בסודות לבדיקה.

alg נקבע מתפריט האלגוריתם; typ הוא JWT כברירת מחדל.

claims כגון sub, iat ו־exp. הזמנים הם בשניות מאז 1970 (UTC).

יש להזין סוד כדי לחתום על הטוקן.

איך להשתמש בו

  1. בחרו HS256, HS384 או HS512.
  2. ערכו את שדות ה‑payload ולחצו על “קבע iat ו‑exp” כדי להוסיף את השעה הנוכחית ותפוגה.
  3. הזינו סוד לבדיקה, או צרו סוד אקראי של 256 סיביות.
  4. העתיקו את האסימון החתום. כדי לבדוק אסימון, עברו אל “אימות חתימה”, הדביקו אותו והזינו את הסוד.

איך זה עובד

ל-JSON Web Token (RFC 7519) יש שלושה חלקים מקודדים ב-Base64URL: כותרת, מטען של claims וחתימה. באלגוריתמי ה-HMAC HS256, HS384 ו-HS512, החתימה היא HMAC עם SHA-256, SHA-384 או SHA-512 על “header.payload”, עם סוד משותף כמפתח. כל מי שיש לו את הסוד יכול ליצור ולאמת אסימונים.

הכלי מסדר את הכותרת ואת המטען כ-JSON דחוס, מקודד אותם וחותם עליהם באמצעות crypto.subtle, ממשק Web Crypto API המובנה בדפדפן שלכם. השדה alg בכותרת תואם תמיד לאלגוריתם שנבחר, ברירת המחדל של typ היא JWT, וכל שדה כותרת אחר, כגון kid, נשמר. האפשרות “הגדר iat ו־exp” כותבת את השעה הנוכחית בתור iat (מועד ההנפקה) ומוסיפה את משך החיים שנבחר בתור exp, שניהם בשניות מאז 1 בינואר 1970 UTC. התוצאה תואמת ספריות JWT אחרות; לדוגמה, האסימון הקלאסי לדוגמה של jwt.io משוחזר בדיוק.

הסוד יכול להיות טקסט רגיל (בתי ה-UTF-8 שלו הם המפתח) או בתים מקודדים ב-Base64/Base64URL, שבהם משתמשות מסגרות רבות. כפתור הסוד האקראי יוצר 32 בתים אקראיים באמצעות crypto.getRandomValues. עבור HS256 השתמשו ב-32 בתים אקראיים לפחות; סודות קצרים שנבחרו בידי אדם ניתנים לניחוש לא מקוון מתוך כל אסימון.

האימות מפענח את האסימון, בודק שהוא משתמש באלגוריתם HMAC ומחשב מחדש את החתימה באמצעות crypto.subtle.verify. הוא גם מציג מתי exp או nbf משמעותם שהאסימון פג תוקף או שעדיין אינו תקף. RS256, ES256 ואלגוריתמים אחרים מבוססי מפתח ציבורי אינם נתמכים, והאימות כאן אינו בודק מנפיק, קהל יעד או claims אחרים שהיישום שלכם עשוי לדרוש.

דוגמאות

בדיקת API מקומית

שרת הפיתוח שלכם מצפה לאסימוני HS256 חתומים עם “dev-secret-change-me”. הגדירו את sub למזהה משתמש לבדיקה, לחצו על “הגדר iat ו־exp” עם שעה אחת, הזינו את הסוד ושלחו את האסימון בכותרת Authorization: Bearer.

בדיקה איזה סוד חתם על אסימון

אסימון staging נדחה. הדביקו אותו באפשרות “אימות חתימה” ונסו את סוד ה‑staging: ההודעה “החתימה אינה תקינה” אומרת שהאסימון נחתם עם סוד אחר או שהסוד בפורמט שונה (טקסט לעומת Base64).

שחזור הדוגמה של jwt.io

כאשר ה‑header הוא {"alg":"HS256","typ":"JWT"}, ה‑payload הוא {"sub":"1234567890","name":"John Doe","iat":1516239022} והסוד הוא “your-256-bit-secret”, האסימון מסתיים ב‑SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c, בדיוק כמו ב‑jwt.io.

שאלות נפוצות

האם הסוד שלי נשלח לשרת שלכם?

לא. החתימה והאימות מתבצעים באמצעות Web Crypto API בתוך הדפדפן שלכם, והסוד אינו נשמר ואינו נשלח לשום מקום. עם זאת, אנו ממליצים להשתמש רק בסודות לבדיקה, כי סוד חתימה אמיתי לא אמור להיות מוקלד באתר לעולם.

מדוע החתימה אינה תקינה למרות שהסוד נכון?

בדקו את פורמט הסוד. חלק מהמערכות משתמשות בטקסט של הסוד, ואחרות מפענחות אותו קודם מ‑Base64, מה שמניב בתי מפתח שונים. כמו כן, בדקו שהאסימון לא שונה ושהוא משתמש באותו אלגוריתם.

האם אפשר ליצור אסימוני RS256 או ES256?

לא בכלי הזה. הוא תומך רק באלגוריתמי HMAC עם סוד משותף: HS256, HS384 ו‑HS512.

האם ה‑payload מוצפן?

לא. JWT חתום הוא רק מקודד; כל אחד יכול לפענח ולקרוא את ה‑payload. החתימה רק מוכיחה שהאסימון לא שונה. אל תשימו סיסמאות או סודות אחרים ב‑payload.

פרטיות

האסימונים נוצרים ומאומתים רק בדפדפן שלכם באמצעות Web Crypto API. ה‑header, ה‑payload, האסימון והסוד אינם מועלים, נשמרים או נכללים בניתוח נתונים.