מפענח JWT

מה מפענח JWT עושה בפועל

JSON Web Token (JWT) נראה כמו מחרוזת ארוכה ואטומה של תווים אקראיים, אבל הוא אינו מוצפן ואינו צופן סודי. זהו מכל קומפקטי ובטוח ל-URL שנושא נתונים מובנים בין שני צדדים. הדביקו טוקן במפענח שלמעלה, והוא מפרק את המחרוזת ומראה לכם את ה-JSON האמיתי שבפנים — את המטא-דאטה, את התביעות (claims), עבור מי הטוקן מיועד, ומתי הוא פג. הכל קורה ממש בדפדפן שלכם. הטוקן לעולם לא מועלה, נרשם ביומן, או נשלח לשום מקום, וזה משנה מאוד כאשר הדבר שאתם בודקים הוא אישור סשן חי.

שלושה חלקים, שתי נקודות

כל JWT תקין הוא שלוש מחרוזות מקודדות ב-Base64url ומחוברות בנקודות: header.payload.signature. אותה נקודה בודדת היא הדרך שבה פרסרים יודעים היכן מקטע אחד מסתיים והבא מתחיל, וזו הסיבה שטוקן עם מספר שגוי של נקודות נדחה עוד לפני שנקרא בו משהו.

הכותרת (header) היא אובייקט JSON זעיר המתאר את הטוקן עצמו. הוא כמעט תמיד מכיל typ (הסוג, בדרך כלל JWT) ו-alg — אלגוריתם החתימה, כמו HS256 (HMAC עם SHA-256) או RS256 (RSA עם SHA-256). הכותרת אומרת למאמת בדיוק כיצד הופקה החתימה.

המטען (payload) הוא החלק שרוב האנשים מתעניינים בו. זהו אובייקט JSON נוסף המחזיק את התביעות (claims) — הצהרות על המשתמש ועל הטוקן. המפרט ממיין תביעות לרשומות (registered, בעלות שמות סטנדרטיים ושמורים), ציבוריות (public), ופרטיות (private, שמות מותאמים אישית שאתם ממציאים עבור האפליקציה שלכם). פענוח המטען הוא מה שחושף מי מחובר, איזה תפקיד יש לו, ומתי הסשן שלו פג.

החתימה (signature) היא החותם הקריפטוגרפי. היא מחושבת על גבי הכותרת והמטען המקודדים באמצעות האלגוריתם מהכותרת בתוספת מפתח סודי או פרטי. מכיוון שהיא מכסה את שני החלקים האחרים, כל שינוי בכותרת או במטען — אפילו תו בודד — מבטל אותה.

התביעות שתראו הכי הרבה

התביעות הרשומות הן שמות קצרים בני שלוש אותיות שהוגדרו ב-RFC 7519 כדי שמערכות שונות יוכלו לפעול יחד. כמה מהן מופיעות כמעט בכל מקום:

• iss — issuer (מנפיק): מי טבע את הטוקן (שרת האימות או ספק הזהות שלכם).
• sub — subject (נושא): הישות שהטוקן עוסק בה, בדרך כלל מזהה משתמש יציב.
• aud — audience (קהל יעד): הנמען שעבורו הטוקן מיועד. API צריך לדחות טוקנים שקהל היעד שלהם אינו הוא עצמו.
• exp — expiration time (זמן תפוגה): חותמת זמן Unix שאחריה אין לקבל את הטוקן.
• iat — issued at (הונפק בתאריך): חותמת זמן Unix שבה נוצר הטוקן.

ייתכן שתיתקלו גם ב-nbf (not before, לא לפני) וב-jti (מזהה טוקן ייחודי). חותמות הזמן הן שניות מאז 1970 ב-UTC, וזו הסיבה שמפענח שמציג אותן כתאריכים קריאים לבני אדם חוסך לכם את החישוב המנטלי של בדיקה האם טוקן כבר פג.

פענוח אינו אימות — זה החלק שתופס אנשים

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

הכלי הזה מפענח. הוא מראה לכם מה הטוקן אומר, לא האם הטוקן אמין. טוקן יכול להיות מזויף, פג תוקף, או משוחזר (replayed) ועדיין להתפענח ל-JSON שנראה נקי לחלוטין. לעולם אל תקבלו החלטת הרשאה על סמך תביעות מפוענחות בלבד. בסביבת ייצור מאמתים את החתימה בצד השרת, בודקים את exp, ומוודאים ש-iss ו-aud תואמים למצופה — באמצעות ספרייה מבוקרת, לעולם לא השוואת מחרוזות תפורה ביד.

מטען אינו כספת

מכיוון שהמטען רק מקודד ב-Base64url, הוא קריא לכל מי שיירט את הטוקן. התייחסו לכל מה שבו כציבורי. אל תניחו סיסמאות, מספרי כרטיסי אשראי מלאים, מפתחות סודיים, או כל מידע אישי רגיש בתביעות JWT — אם אתם יכולים לפענח אותו כאן בקליק אחד, כך יכול גם כל מי שמקבל עותק. החתימה מגנה מפני שינוי, לעולם לא מפני קריאה. אם אתם באמת צריכים להסתיר את תוכן המטען, זו עבודה עבור JWE (טוקנים מוצפנים), מפרט שונה לגמרי.

פרטיות וכלים קשורים

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

שאלות נפוצות