באביב שעבר, משתמשים התחילו להתנתק מ Toolz.dev.לא לפעמים - ללא הרף. sign in, click one tool, boom: back to the login screen.The backend issues 15-minute access tokens and 7-day refresh tokens, and I'd tested that flow a hundred times.So naturally I imposed the refresh endpoint was broken and spended a hour and forty minuture reading Express middleware that had nothing wrong with it.
ואז סוף סוף עשיתי את הדבר הברור מאליו תפסתי אסימון גישה חיה מתוך כותרת ההרשאה, הדבקתי אותו במפענח והסתכלתי על הטענות. ה exp היה בסדר. ה iat היה בסדר האסימון היה תקף לעוד 14 דקות מה שאומר שהשרת היה בסדר - והבאג היה צריך להיות על הלקוח בטח: החזית שלי בדקה payload.exp < Date.now(). exp הוא שניות מאז עידן. Date.now() הוא אלפיות שניות כל אסימון שהוטבע טרי נראה כאילו פג אי שם בסביבות 1970, אז הלקוח " helpfully" התנתק כולם לפני שהשרת אי פעם קיבל מילה. שלוש תווים של תיקון - /1000- אחרי כמעט שעתיים של ציד.
That's כל המגרש על שיש מפענח JWT בארגז הכלים שלך. JWT נראה כמו רעש קו - שלושה נתחים של ג'יבריש base64url מודבקים יחד עם נקודות - אבל זה 's רק JSON לובש מעיל טרנץ'. ברגע שאתה יכול לקרוא את הטענות, חצי מהאגים שלך באישור מפסיקים להיות תעלומות. קהל שגוי, אסימון שפג תוקפו, תפקיד חסר, הטיית שעון, אלפיות שניות מול שניות - הם' כולם יושבים שם בטקסט רגיל ברגע שאתה מפענח.
אבל - וזה משנה - שבו אתה מפענח אינו בחירה ניטרלית אסימון גישה אמיתי הוא אישור חי. הדבק אותו באתר מפענח ששולח אסימונים לשרת, ואתה ' זה עתה הפקדת מפתח עובד ל-API שלך ב-stranger's יומני בקשות. That's הסיבה הספציפית שבניתי את Toolz.dev JWT מפענח כדי לרוץ כולו בדפדפן שלך. עוד על זה למטה.
TL;DR: כדי לפענח JWT באינטרנט, הדבק אותו ב- Toolz.dev JWT מפענח- זה מפצל כותרת, מטען וחתימה באופן מיידי, מתורגם
exp/iatלתוך תאריכים אנושיים, ופועל 100% בצד הלקוח כך האסימון לעולם לא עוזב את המכונה שלך דבר אחד לצרוב בזיכרון: פענוח אינו מאמת. JWT הוא רק JSON מקודד base64url שכל אחד יכול לקרוא - רק אימות חתימה עם המפתח מוכיח את זה 's אמין.
תכונות מפתח
כותרת מיידית, מטען ופיצול חתימה
הדבק אסימון והמפענח מיד מפרק אותו לשלושת חלקיו: הכותרת (אלגוריתם וסוג אסימון), המטען (הטענות שלך) והחתימה (שמאלה מקודדת, כי זה ' הוא MAC גולמי או חתימה - שם 's שום דבר לא קריא אנושי שם). אין כפתור שלח, אין טעינה מחדש של עמוד זה משקף בדיוק את מה שספריית האישורים שלך עושה באופן פנימי לפני אימות: פיצול ., base64url-פענח את שני הקטעים הראשונים, נתח כ JSON.לראות את החלקים מונחים זה לצד זה היא הדרך המהירה ביותר לבנות אינטואיציה עבור הפורמט.After כמה עשרות אסימונים, you'll להתחיל לזהות אסימון RS256 Auth0 לעומת אסימון HS256 Laravel במבט חטוף - הכותרת נותנת אותו בכל פעם.
חותמות זמן ניתנות לקריאה של exp, iat ו-nbf
התכונה השימושית ביותר, נקודה. exp, iat, ו nbf האם ערכי NumericDate - שניות מאז עידן יוניקס - ואף אחד, כולל אני, לא יכול לקרוא 1783430700 ואומר לך אם זה ' ביום שלישי הבא או מוות החום של היקום. המפענח ממיר כל תביעת חותמת זמן לתאריך ושעה בפועל, באזור הזמן המקומי שלך וב-UTC. זה המקום שבו הבאג הקלאסי של אלפיות השנייה לעומת שניות הופך לגלוי מיידי: אם אתה מפוענח exp מציג כתאריך בשנה 56,000-משהו, מישהו מילא JavaScript Date.now() לתוך שדה שמצפה שניות. I'שלחת את הבאג הזה. לראות את התאריך האבסורדי הוא האבחנה. לארכיאולוגיה עמוקה יותר של חותמת זמן, ה ממיר חותמת זמן נמצאת במרחק של כרטיסייה אחת.
ספירה לאחור ומצב תפוגה
מעבר לעיבוד התאריך בלבד, המפענח אומר לך את האסימון' המצב הנוכחי: תקף, פג או עדיין לא פעיל (מתי nbf האם בעתיד). אם האסימון 's עדיין בחיים, אתה מקבל ספירה לאחור עד לפקיעת תוקף. זה נשמע כמו נוחות קטנה עד שאתה ' מאתר באגים ב-401 לסירוגין וצריך לענות " האם האסימון הספציפי הזה מת כשהבקשה נורתה?" שוב ושוב. השוואת הספירה לאחור מול השרת שלך 's מוגדר TTL גם תופס תצורה שגויה במהירות - אם אסימוני הגישה שלך אמורים לחיות 15 דקות והספירה לאחור אומרת 6 ימים, קוד ההנפקה שלך קורא את ערך התצורה השגוי.
בדיקת אלגוריתם וכותרת
הכותרת המפוענחת מראה לך alg ו typ (פלוס kid וחברים כאשר נוכחים), אשר עונה על שאלות שחשובות לאבטחה, לא רק ניפוי באגים האם אסימון זה HS256 או RS256? האם ה kid התאם מפתח שנקודת הקצה של JWKS שלך באמת משרתת? והגדול: הוא alg משהו שזה לעולם לא צריך להיות, כמו none? אסימונים טוענים "alg": "none" האם או מתקני בדיקה או מישהו חוקר את המאמת שלך - כך או כך, אתה רוצה לראות את זה מיד אני בודק את הכותרת תחילה על כל אסימון לא מוכר, לפני שאני קורא טענה אחת.
תביעות JSON מודגשות, מעוצבות בתחביר
מטענים מפוענחים גולמיים הם כתמי JSON בשורה אחת, וספקי זהות אוהבים לארוז אותם: אובייקטים מקוננים, תביעות מותאמות אישית בקצב שמות, מערכי היקפים. המפענח מדפיס הכל עם הדגשת תחביר כך roles, scope, aud מערכים, ואובייקטי הרשאה מקוננים ניתנים למעשה לסריקה. It's אותו טיפול ה פורמט JSON נותן JSON שרירותי, המוחל אוטומטית על הטענות שלך. כאשר אתה 're משווה שני אסימונים - נניח, אחד ממשתמש שיכול לגשת לנקודת קצה ואחד ממשתמש שיכול 't - פלט מעוצב הופך תרגיל פזילה להפרש של עשר שניות.
100% צד לקוח - האסימון שלך לעולם לא עוזב את הדפדפן
זוהי התכונה I'd להילחם עבור. אסימון גישה מודבק אינו נתונים לדוגמה - it's אישור חי שמאמת כמשתמש אמיתי עד exp. כל מפענח שמפרסם את האסימון שלך ל-backend כתב זה עתה מפתח עובד לתוך יומני שרת, אנליטיקה, אולי עוקב שגיאות של צד שלישי. מפענח Toolz.dev עושה את כל הפענוח ב-JavaScript, בכרטיסייה שלך. שום דבר לא מועבר, שום דבר לא מאוחסן. Don' t קח את המילה שלי: פתח את DevTools, צפה בכרטיסייה Network, הדבק אסימון. אפס בקשות. כתבתי מדוע הארכיטקטורה הזו חשובה עבור כל כלי קלט רגיש ב הקטע שלי על פרטיות נתונים בכלים מקוונים.
עובד עם כל JWT, מכל מחסנית
JWTs הם תקן - RFC 7519- אז המפענח doesn't אכפת מי טבע את שלך. Auth0 ו Firebase אסימונים עם טענות מותאמות אישית בקצב השמות שלהם, הגדרות צמודות Laravel Sanctum, Keycloak, Supabase, AWS Cognito, או אסימוני HS256 מגולגל ביד שלי אקספרס backend סימנים עבור Toolz.dev - אם זה & #39;s שלושה מקטעי base64url הצטרפו על ידי נקודות, זה מפענח.That כולל malformed כמעט-JWTs: אם קטע שני won't לנתח כמו JSON, המפענח אומר לך איזה חלק שבור במקום להיכשל בשקט, וזה עצמו אבחון. אסימונים קטומים על העתקה נפוצים יותר ממה שאתה & #39;d חושב.
כיצד להשתמש במפענח JWT
שלב 1: תפוס את האסימון
מצא את האסימון בכל מקום שהאפליקציה שלך שומרת אותו. לרוב: DevTools → כרטיסיית רשת → לחץ על בקשה → העתק את Authorization: Bearer eyJ... ערך כותרת (ללא המילה " Bearer"). או לבדוק Application → Local Storage / Cookies, מאחר והרבה אפליקציות מאחסנות שם אסימונים.On the backend, log it or pull it from your test suite.Copy the entire string - a JWT that loses its last features still decodes but will never valuate, and that's a complusing hour you don't need.
שלב 2: הדבק אותו
פתח את מפענח JWT ולהדביק פענוח קורה תוך כדי הקלדה - אין כפתור אם אתה' עצבניים לגבי הדבקת אסימון הפקה בכל מקום (אינסטינקט טוב), פתח תחילה את הכרטיסייה רשת ואשר שום דבר לא מועבר. זה 't. בדיקת הפרנויה הזו אורכת עשר שניות והיא 's בדיוק מה I'd עושה על מישהו אחר 's כלי.
שלב 3: קרא את שלושת החלקים
כותרת ראשונה: אשר alg הוא מה שהמערכת שלך מצפה ו typ הוא JWT. ואז המטען: iss (מי טבע את זה), aud (למי זה 's עבור), sub (איזה משתמש), בתוספת כל התפקידים, היקפים, או מותאם אישית טוען מחסנית שלך מוסיף.the החתימה נשארת מקודד - זה & #39;s פלט קריפטוגרפי, לא נתונים.If הכותרת אומרת none, עצור ולך לבדוק את המאמת שלך's אפשר-רשימה לפני כל דבר אחר.
שלב 4: בדוק את exp ואת התביעות שנושכות
תראה את המפוענח exp תאריך וסטטוס התפוגה. פג? There's your 401. תקף אך נדחה בכל מקרה? עכשיו השווה aud ו iss כנגד התצורה של verifier's - אי התאמה יש את הסיבה השנייה בשכיחותה לאחר פקיעת התוקף. ואם חותמת זמן כלשהי מופיעה כשנה בת חמש ספרות, מזל טוב: you' מצאת באג של אלפיות שניות מול שניות, ואני מברך אותך בזאת למועדון גדול מאוד.
מה 's בעצם בתוך JWT? אנטומיה של שלושת החלקים
אסימון אינטרנט של JSON, המוגדר ב-RFC 7519, הוא שלושה מקטעים מקודדים base64url המחוברים לפי תקופות: header.payload.signature. (באופן קפדני, הזן החתום הוא JWS לכל RFC 7515 - there's בן דוד מוצפן, JWE, אבל כמעט כל אסימון שאתה ' תפגשו בטבע הוא JWS חתום.)
מילת המפתח היא מקודד.Base64url הוא קידוד תחבורה - דרך הפיכה להפוך בתים ל-URL-בטוחים - לא הצפנה כל מי שמחזיק JWT יכול לקרוא הכל בכותרת ומטען עם אפס מפתחות, אפס סודות, אפס מאמץ שחק עם הקידוד הגולמי ב ממיר Base64 ואתה 'תראה את זה 's האלפבית הסטנדרטי עם + ו / הוחלף עבור - ו _, ריפוד ירד. כתבתי עוד על הקידוד עצמו ב- מדריך קידוד Base64.
פענח כותרת טיפוסית ותקבל:
{ "alg": "HS256", "typ": "JWT" }
ומטען שנבנה מהתביעות הרשומות RFC 7519 מגדיר:
{
"iss": "https://toolz.dev",
"sub": "user_8f3a2c",
"aud": "toolz-api",
"exp": 1783431600,
"nbf": 1783430700,
"iat": 1783430700,
"jti": "b4d1f0e2"
}
iss האם המנפיק, sub הנושא (בדרך כלל מזהה המשתמש שלך), aud הקהל המיועד, jti מזהה אסימון ייחודי. exp, nbf, ו iat האם ערכי NumericDate: שניות seconds מאז עידן יוניקס. לא אלפיות שניות. JavaScript's Date.now() מחזירה אלפיות שניות, ובלבול בין השניים מייצר אסימונים שפג תוקפם באופן מיידי (באג ההתנתקות שלי Toolz.dev) או אסימונים עם exp תאריכים בשנת 56,000 שלמעשה לעולם אינם פוקעים - וזה בשקט הכישלון המסוכן יותר.
HS256 לעומת RS256. HS256 חותם עם HMAC על סוד משותף - מהיר, פשוט, אבל כל שירות שמאמת אסימונים מחזיק גם בסוד, וכל מי שמחזיק בסוד יכול מנטה אסימונים. קנס למונוליט כמו הקצה האחורי שלי, שבו מנפיק ומאמת הם אותו תהליך. RS256 חותם עם מפתח פרטי ומאמת עם מפתח ציבורי, כך שתוכל לפרסם את המפתח הציבורי (דרך JWKS) ולתת לתריסר שירותי מיקרו לאמת מבלי שאף אחד מהם יוכל לזייף. מערכות מבוזרות ו-IDP של צד שלישי צריכים להיות ב-RS256 או באחיו ECDSA/EdDSA.
ה alg: none התקפה. RFC 7519 מאפשר JWT לא מאובטחים היכן alg הוא none והחתימה ריקה ספריות מוקדמות סמכו על הכותרת's alg באופן עיוור, אז תוקפים הפשיטו את החתימה, הגדר alg ל none, והפליג דרך אימות עם טענות הנשלטות על ידי תוקף מלא. טריק קשור מחליף את RS256 עבור HS256 כך שהמאמת משתמש ב ציבורי מפתח כסוד HMAC. זו הסיבה ש-RFC 8725 - JSON Web Token Best Practices Current Practices - בוטה: המאמת חייב להצמיד את האלגוריתמים המותרים שלו לקוד ולעולם לא לתת לאסימון לבחור. אם שיחת הספרייה שלך עושה 't כלול מפורש algorithms רשימה, תקן את זה היום.
פענוח לעומת אימות - הקו שחשוב. פענוח הוא קריאה; אימות הוא אמון. ההבדל בקוד:
// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
Buffer.from(token.split('.')[1], 'base64url').toString()
);
// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });
מפענח מקוון עושה את הדבר הראשון. זה יכול להראות לך את הטענות; זה לא יכול - ולא צריך להעמיד פנים - להגיד לך שהאסימון אותנטי. רק verify, עם המפתח, עושה את זה. לעולם אל תקבל החלטות הרשאה על תביעות מפוענחות אך לא מאומתות.
מה שמוביל לכלל האחרון: לעולם אל תכניס סודות למטען JWT. אין סיסמאות, אין מפתחות API, אין נתונים you'd אכפת קריאת תוקף המטען הוא ציבורי על ידי בנייה - חתום נגד שיבוש, פתוח לרווחה לקריאה.If it's באסימון, להניח את כל האינטרנט יכול לראות את זה.
מקרי שימוש נפוצים
איתור באגים של 401s במהלך פיתוח API
ה-401 הוא קוד המצב הכי פחות אינפורמטיבי ב-HTTP השרת אמר לא - אבל האם פג תוקפו של האסימון? קהל שגוי? חתום עם מפתח מעופש? חסר לחלוטין כי המיירט שלך עשה ' לא יורה? פענוח האסימון בפועל מהבקשה הכושלת ממוטט את מרחב החיפוש תוך שניות. חצי מהזמן exp עונה על זה לבד החצי השני, משווה iss ו aud מול המאמת שלך 's הסביבה config מוצא אסימון dev משוחזר נגד בימוי, או להיפך. אני שומר את המפענח מוצמד ליד לקוח ה-HTTP שלי בדיוק ללולאה הזו; it's ערך ליבה אצלי ערכת כלים לניפוי באגים של API. פענח ראשון, קרא תוכנת ביניים שניה - הסדר ההפוך עלה לי שעה וארבעים דקות פעם אחת, ואני מתכוון להמשיך לגבות עניין בשיעור הזה.
הסבר על התנתקות מהפתעה
כאשר משתמשים מדווחים " זה ממשיך לרשום אותי, " האסימון 's חותמות זמן הן הצהרת העד שלך.פענח אסימון גישה טרי ובדוק את הפער בין iat ו exp- האם זה בעצם 15 הדקות שהגדרת, או ש-env var עקף את זה ל-60 שניות? ואז בדוק אם אסימון הרענון 's חלון של 7 ימים הוא מה שאתה חושב שהוא. הטיית שעון מופיעה גם כאן: אם השרת המנפיק שלך 's השעון פועל כמה דקות מהר, אסימונים מגיעים כבר עתיקים על ידי הלקוח 's reconnaing. וכמובן, באג ההשוואה של שניות מול מילישניות - זה שביט Toolz.dev - מכריז על עצמו ברגע שאתה רואה תוקף מושלם exp על אסימון הלקוח שלך נשבע שפג תוקפו.
ביקורת מה ספק הזהות שלך מכניס אסימונים
רוב הצוותים מעולם לא קראו את האסימונים שלהם IdP mints, וזה & #39;s שווה לעשות.פענח אחד ואתה עשוי למצוא כתובות דואל, שמות מלאים, כתובות URL של תמונות, מזהים דיירים - PII רוכב לאורך בכל בקשת API בודדת, מאוחסן ב localStorage, וקריא על ידי כל דבר שמניח את ידיו על האסימון. Here's העמדה הדעתנית שלי, ו-I' יתווכח על זה עם כל אחד: don't לשים מיילים של משתמשים במטענים של JWT. ה sub תביעה קיימת בדיוק כדי שתוכל לשאת מזהה אטום ולחפש את צד שרת הפרטים האנושיים. כל טענה נוספת היא נתונים שאתה 're שידור ובייטים שאתה 're משלם עליהם בכל בקשה. פענח, ביקורת, ואז עבור לקצץ IdP's שלך מיפוי תביעות.
אימות תפקידים והיקפים במהלך איתור באגים בהרשאה
אימות אומר מי אתה; הרשאה אומרת מה אתה יכול לעשות - וכאשר הרשאה מתנהגת לא נכון, התשובה נמצאת בטענות המשתמש נשבע שהם ' הם אדמין אבל מקבל 403s? פענח את האסימון שלהם. אם role אומר user, האסימון הוטבע לפני הקידום והם צריכים להתחבר מחדש - תוצאה קלאסית של אסימונים חסרי מדינה הנושאים תמונות מעופשות. אם התפקיד קיים אך הגישה עדיין נכשלת, בדוק את שם התביעה והצורה המדויקים: roles vs role, מערך לעומת מחרוזת, scope כמחרוזת מופרדת ברווח לעומת scp כמערך. Middleware בודק payload.roles.includes('admin') נגד מטען שיש לו role: "admin" נכשל בשקט ומקומם שני אסימונים מפוענחים זה לצד זה - אחד עובד, אחד לא - בדרך כלל מיישבים אותו תוך פחות מדקה.
השוואת תוכן אסימון גישה ורענון
במערך כפול אסימונים כמו שלי, שני האסימונים צריכים להיראות שונים באופן משמעותי, ופענוח שניהם הוא הביקורת אסימון הגישה: קצר exp, בנוסף לכל מה שטוען שה-API צריך לפי בקשה. אסימון הרענון: ארוך exp, א jti למעקב אחר ביטולים, וכמה שיותר קרוב לשום דבר אחר. אם אסימון הרענון שלך נושא תפקידים ונתוני פרופיל, משהו ' כבוי - it's הוצג רק לנקודת קצה אחת ואמור 't לשכפל את אסימון הגישה 's עבודה. בדיקה זו לצד זו תופסת גם את שיעור הבאגים המביך שבו שני האסימונים מקבלים בטעות את אותו TTL, שהופך את חלון הגישה "15 דקות שלך; לתיאטרון אבטחה שאל אותי איך אני יודע לבדוק את זה.
JWT לעומת אסימוני הפעלה אטומים: השוואה כנה
| JWT | אסימון הפעלה אטום | |
|---|---|---|
| חוסר אזרחות | עצמאי; כל שרת עם המפתח מאמת ללא חיפוש | שרת (או חנות משותפת כמו Redis) חייב לחפש כל בקשה |
| ביטול | קשה - תקף עד exp אלא אם כן אתה בונה דניליסט, שמכניס מחדש מדינה |
טריוויאלי - מחק את הרשומה בצד השרת, האסימון מת באופן מיידי |
| גודל לפי בקשה | מאות בתים עד מעל קילובייט, על כל בקשה | ~32–64 בתים |
| היכן מתרחש אימות | בכל מקום שמחזיק את המפתח (הציבורי) - נהדר עבור שירותי מיקרו | בכל מקום בו מתגוררת חנות הסשן |
| לטעון לרעננות | תמונת מצב בזמן ההנפקה; שינויים בתפקידים ממתינים להוצאה מחדש | תמיד עדכני - קורא נתונים חיים |
| יכולת ניפוי | פענח וקרא טענות באופן מיידי | אטום בעיצובו; דורש גישה לחנות |
אני משתמש ב-JWTs עבור Toolz.dev ו-I' עדיין אגיד לך שהם 'נרשמו יתר על המידה. סיפור הביטול הוא באמת גרוע: כשאתה אוסר על משתמש, אסימון הגישה שלו ממשיך לעבוד עד exp- וזו בדיוק הסיבה שאסימוני הגישה שלי חיים 15 דקות ואסימון הרענון של 7 ימים הוא הדבר שאני יכול להרוג בצד השרת. ההיברידית הזו היא הדפוס הישר: JWTs חסרי מצב קצרי מועד לאימות זול, מחסום מצבי אחד לשליטה. אם אתה ' מריצים מונוליט עם מסד נתונים אחד, הפעלות פשוטות יותר, קטנות יותר וניתנות לביטול מיידי - כוח העל של JWT' של אימות מבוזר פותר בעיה שאתה עושה ' אין לך.
בעוד we're משווה - HS256 לעומת RS256 במבט אחד:
| HS256 | RS256 | |
|---|---|---|
| דגם מפתח | אחד משותף סימנים סודיים ו מאמת | סימני מפתח פרטיים, מפתח ציבורי מאמת |
| מי יכול להטביע אסימונים | כל מי שמחזיק בסוד | רק מחזיק המפתחות הפרטי |
| הכי מתאים | שירות יחיד, מנפיק = מאמת | שירותי מיקרו, IDP של צד שלישי, JWKS |
| גודל חתימה / מהירות | קטן יותר, מהיר יותר | גדול יותר, איטי יותר, בטוח יותר להפצה |
שאלות נפוצות
האם זה בטוח להדביק JWT לתוך מפענח מקוון?
רק אם המפענח פועל צד לקוח.אסימון אמיתי הוא אישור חי - שליחתו למישהו & #39; שרת s שותל מפתח עובד ביומנים שלהם. Toolz.dev JWT Decoder עושה את כל הפענוח בדפדפן שלך ולא משדר דבר; אתה יכול לאשר זאת בעצמך על ידי צפייה בכרטיסייה רשת בזמן שאתה מדביק. עבור מפענחים אתה יכול ' לא לאמת, להשתמש באסימוני פג או לבדוק בלבד.
האם אתה יכול לפענח JWT בלי הסוד?
כן - that's הנקודה שאנשים מפספסים ביותר הכותרת והמטען הם JSON מקודד base64url, והקידוד אינו הצפנה כל אחד יכול לקרוא כל טענה ללא כל מפתח.The הסוד (או מפתח פרטי) נחוץ רק כדי ליצור או לאמת את החתימה פענוח דורש שום דבר; אמון דורש אימות.
What's ההבדל בין פענוח לאימות JWT?
פענוח קורא את התוכן: פיצול על נקודות, base64url-פענוח, לנתח JSON.אימות מוכיח אותנטיות: recompute או לבדוק את החתימה באמצעות המפתח הסודי או הציבורי, לאשר את האלגוריתם, לבדוק תפוגה מפענח מראה לך מה אסימון טוען; רק אימות, נעשה בצד השרת עם המפתח, אומר לך אם להאמין בזה.Never לאשר מבוסס על טענות מפוענחות אך לא מאומתות.
מדוע ה-JWT שלי מופיע כלא חוקי או שפג תוקפו?
לרוב ה exp עבר באמת - פענח אותו ובדוק את התאריך. החשודים הבאים: אסימון קטום מהדבקת העתקה מרושלת, א aud או iss זה מתאים 't config המאמת שלך 's, הטיית שעון בין שרתים, או חתימה ממפתח מסובב. אם המפוענח exp נראה בסדר אבל הקוד שלך דוחה את האסימון, בדוק אם אתה 'משווים שניות מול אלפיות שניות.
האם JWTs מוצפנים?
JWTs סטנדרטיים - מבחינה טכנית JWS, לכל RFC 7515 - חתומים, לא מוצפנים החתימה מזהה שיבוש אך לא מסתירה דבר; המטען ניתן לקריאה על ידי כל אחד. גרסה מוצפנת (JWE) קיימת אך נדירה באישור אינטרנט טיפוסי. כלל מעשי: התייחס לכל מטען JWT כפומבי, ולעולם אל תכניס סיסמאות, מפתחות API או נתונים רגישים לאחד.
באיזה פורמט נמצאת תביעת exp?
exp הוא NumericDate: שניות מאז עידן Unix (1 בינואר 1970 UTC), כפי שהוגדר ב-RFC 7519. אותו דבר עבור iat ו nbf. הבאג הקלאסי משתמש ב-JavaScript's Date.now(), שמחזיר אלפיות שניות - מייצר אסימונים שנראים פג תוקף מיידי או נושאים תאריכי תפוגה בסביבות שנת 56,000. אם חותמת זמן מפוענחת מציגה שנה בת חמש ספרות, זה ' הוא הבאג שלך.
מהי התקפת alg none?
RFC 7519 מאפשר JWTs לא מאובטחים עם "alg": "none" וחתימה ריקה ספריות ישנות סמכו על הכותרת's שדה אלגוריתם, כך תוקפים הפשיטו חתימות, להגדיר alg ל none, ועבר אימות עם טענות מזויפות. RFC 8725, ה-JWT Best Current Practices, דורש מהמאמתים להצמיד רשימת הרשאות מפורשת של אלגוריתמים בקוד ולהתעלם מכל מה שהאסימון מבקש.
האם עלי להשתמש ב-HS256 או RS256?
HS256 משתמש בסוד משותף אחד לחתימה ואימות - פשוט ומהיר, מתאים לשירות יחיד שגם מנפיק וגם בודק את האסימונים שלו. RS256 חותם עם מפתח פרטי ומאמת עם ציבורי, כך ששירותים רבים יכולים לאמת מבלי יכולת לזייף.Rule of thumb: monolith, HS256; microservices או ספק זהות של צד שלישי, RS256.
עוטף
בניתי את מפענח JWT כי המשכתי להזדקק לו בזמן בניית Toolz.dev עצמו - אותם אסימוני גישה של 15 דקות ואסימוני רענון של 7 ימים I' כבר לנתח לאורך המדריך הזה. it decodes instantly, translates the timestamps that cause 90% of the confusion, and never sends your token anywhere. that last part is't a feature checkbox; for a tool that handles live certifications, it's the whole design.
אם אסימונים הם חלק מניפוי הבאגים היומי שלך, השכנים ירוויחו גם את השמירה שלהם: ה ממיר חותמת זמן לארכיאולוגיה של עידן, ה ממיר Base64 לחטט בקטעים גולמיים, ה פורמט JSON לכתמי תביעה, וה מְחוּגָה כאשר אתה'עובדים מחדש עם digests.לזרימת העבודה הרחבה יותר, שלי מדריך כלים לניפוי באגים ב-API מכסה היכן שמפענח מתאים ללולאה.
ולשמור את גרסת משפט אחד מודבק על הצג שלך: פענוח אומר לך מה אסימון אומר, אימות אומר לך אם להאמין בזה.Confuse השניים ואתה & #39;ll ספינה הסוג של באג כי בסופו של דבר כמו אנקדוטה הפתיחה ב someone's פוסט בבלוג.הפעם זה היה שלי.
