בפעם הראשונה שהייתי צריך לנפות באגים בזרימת אישור שבורה ב-API של Laravel, בזבזתי אחר צהריים כי לא יכולתי לייצר אסימון שסמכתי עליו. תוכנת הביניים המשיכה להחזיר 401, ולא יכולתי לדעת אם הבאג נמצא בקוד האימות שלי או באסימון שאני מאכיל אותו. הייתי צריך JWT ידוע-טוב עם ספציפי sub, פקיעת תוקף ספציפית, וסוד ששלטתי בו, כדי שאוכל לבודד צד אחד של הבעיה העתקת אסימון אקראי מתשובה של Stack Overflow עשתה את ההיפך מעזרה, כי היא נחתמה בסוד שלא היה לי.
זה הפער שמחולל JWT ממלא זה לא שירות חתימת ייצור זה כלי ספסל לרגע שאתה בונה או בודק משהו שצורך אסימוני אינטרנט של JSON ואתה צריך אחד תקף לפי דרישה, עם הטענות המדויקות והסוד המדויק שאתה בוחר מדריך זה מכסה את אופן פעולת הכלי, אופן ההרכבה והחתומה של JWT, והמקרים המעשיים שבהם יצירת אסימון ביד חוסכת לך זמן אמת.
TL;DR: מחולל JWT הופך מטען JSON בתוספת סוד לאסימון חתום. הדבק את הטענות שלך, בחר HS256, HS384 או HS512, הזן את הסוד והעתק את האסימון. ה מחולל JWT שלטים עם הדפדפן Web Crypto API, כך המטען והסוד לעולם לא לעזוב את המכונה שלך השתמש בו כדי ליצור אסימוני בדיקה עם ידוע
sub, תפוגה מוגדרת, או תפוגה בכוונהexpכדי לממש את נתיבי השגיאה של API's. כדי לקרוא אסימון בחזרה, חבר אותו עם מפענח JWT.
מהו JWT ומה מייצר הגנרטור?
אסימון אינטרנט של JSON הוא דרך קומפקטית, בטוחה לכתובת URL לייצג קבוצה של תביעות המבנה מוגדר על ידי RFC 7519, והטופס החתום, וזה מה שכמעט כולם מתכוונים אליו על ידי "a JWT," הוא חתימת אינטרנט של JSON כפי שהוגדרה על ידי RFC 7515. לאסימון חתום יש שלושה חלקים המחוברים בנקודות: header.payload.signature.
הכותרת היא אובייקט JSON קטן ששם את אלגוריתם החתימה ואת סוג האסימון, משהו כמו { "alg": "HS256", "typ": "JWT" }. המטען הוא אובייקט JSON של טענות: על מי האסימון, מתי הוא יפוג, וכל השדות המותאמים אישית שהאפליקציה שלך מוסיפה. גם הכותרת וגם המטען מקודדים Base64url, שהוא base64 רגיל עם שני החלפות תווים וללא ריפוד, בדיוק כפי שמציין RFC 7515. החתימה היא hash עם מפתח המחושב על פני שני החלקים הראשונים.
הגנרטור מרכיב את שלושתם אתה מספק את המטען והסוד, הוא בונה את הכותרת, מקודד את שני הקטעים, מחשב את החתימה ומצטרף אליהם הפלט הוא מחרוזת שאתה יכול להפיל ישר לתוך Authorization: Bearer כותרת, מתקן בדיקה או א curl פקודה.
דבר אחד שווה להיות בוטה על מלפנים: JWT חתום מקודד, לא מוצפן כל מי שמחזיק את האסימון יכול Base64url-לפענח את המטען ולקרוא כל טענה בו החתימה לא מסתירה את התוכן זה רק מוכיח התוכן לא שונו על ידי מישהו ללא המפתח לעולם אל תשים סיסמה, מפתח API, או כל דבר אחר לא היית מראה למשתמש בתוך מטען JWT.
איך עובדת החתימה?
עבור משפחת HMAC, שזה מה שהכלי הזה חותם איתו, החתימה היא HMAC(secret, header + "." + payload). HMAC הוא מבנה hash עם מפתח המוגדר על ידי RFC 2104, ומפרט JWA, RFC 7518, ממפה עליו את שלושת שמות האלגוריתמים של JWT: HS256 משתמש ב-HMAC עם SHA-256, HS384 משתמש ב-SHA-384, ו-HS512 משתמש ב-SHA-512.
המאפיין החשוב הוא סימטריה אותו סוד גם יוצר וגם מאמת את החתימה כאשר השרת שלך מקבל אסימון הוא מחשב מחדש HMAC(secret, header + "." + payload) על פני שני הקטעים הראשונים שהתקבלו ובודק שהתוצאה שווה לקטע החתימה. אם בית בודד של המטען השתנה, ה-hash המחושב מחדש לא יתאים והאימות נכשל. זו כל הבטחת השלמות.
כי הוא סימטרי, הסוד הוא כל המשחק כל מי שיש לו את הסוד יכול להטביע אסימונים תקפים עבור המערכת שלך, וזו הסיבה המחולל מריץ את החתימה בדפדפן שלך דרך ה - API של קריפטו אינטרנט ולעולם לא משדר את הסוד בשום מקום אתה יכול לאשר זאת על ידי פתיחת הדפדפן שלך & #39;s כרטיסיית רשת בזמן שאתה מייצר אסימון: אין בקשה זה משנה יותר ממה שזה נשמע, כי הדבקת סוד חתימה של הפקה חיה לתוך כלי אינטרנט אקראי שטלפונים הביתה היו מוסרים את המפתחות לאימות שלך.
RS256 ו-ES256, האלגוריתמים האסימטריים, פועלים אחרת: מפתח פרטי מסמן ומפתח ציבורי תואם מאמת אלה הבחירה הנכונה כאשר שירותים רבים צריכים לאמת אסימונים אבל רק אחד צריך להיות מסוגל להנפיק אותם כלי זה בכוונה לא מציע אותם, כי חתימה איתם פירושה הדבקת מפתח פרטי בדף אינטרנט, וזה הרגל שכדאי לא להתחיל לעולם.
כיצד להשתמש במחולל JWT
שלב 1: כתוב את המטען
הזן את הטענות שלך כאובייקט JSON.דוגמה מינימלית היא { "sub": "1234567890", "role": "admin" }. ה sub הטענה היא הנושא, בדרך כלל מזהה משתמש. אתה יכול להוסיף כל שדות מותאמים אישית שהאפליקציה שלך קוראת, כגון role, scope, tenant_id, או email. הכלי שומר את כל מה שאתה שם כאן בדיוק כפי שנכתב.
שלב 2: הוסף את תביעות הזמן
השאר מונפק ב-on ואת חותמות הכלים iat עם זמן יוניקס הנוכחי. הגדר תפוגה בשניות כדי להוסיף exp טענה מחושבת כ-now plus that offset. עבור אסימון גישה של חמש עשרה דקות, הזן 900. עבור אסימון של שעה אחת, הזן 3600. אלו הן הטענות שרוב באגי האימות מסתכמים בהן, כך שחישובם נכון, תוך שניות מאז התקופה ולא אלפיות שניות, מסיר טעות נפוצה.
שלב 3: בחר את האלגוריתם והסוד
בחר HS256 אלא אם יש לך סיבה להשתמש HS384 או HS512 הזן את סוד החתימה בשדה לאחר מכן בחר כיצד הסוד מתפרש: טקסט רגיל משתמש UTF-8 בתים של מה שאתה מקליד, בעוד base64url ו hex לפענח את המחרוזת ראשונה לתוך בתים גולמיים בחירה זו משנה כי מערכות רבות לאחסן את הסוד כבר base64-מקודד, ואם אתה מזין את המחרוזת המקודדת כטקסט רגיל אתה תייצר חתימה שאינה תואמת.
שלב 4: העתק את האסימון
ה-JWT החתום מופיע יחד עם תצוגה מקדימה מפוענחת של הכותרת והמטען כך שתוכל לאשר כל טענה לפני השימוש בה העתק אותה והדבק אותה בכל מקום שתזדקק לה.
למה לייצר אסימון ביד?
בדיקת ה-API 's נתיב שמח
כאשר אתה כותב תוכנת ביניים המאמתת JWTs, אתה צריך אסימון שהקוד שלך צריך לקבל. צור אחד חתום באותו סוד שבו משתמש המאמת שלך, עם תוקף exp, ואשר את הבקשה מחזירה 200 אם לא, הבאג נמצא בלוגיקת האימות שלך, לא האסימון. שלב הבידוד היחיד הזה הוא הסיבה שאני מושיט יד לכלי לרוב.
בדיקת נתיבי הכשל
API חזק דוחה את האסימונים הנכונים מהסיבות הנכונות. צור אסימון עם א exp כבר בעבר כדי לאשר שאתה מחזיר את השגיאה הנכונה עם אסימון שפג תוקפו. צור אחד עם א nbf בעתיד כדי לבדוק את הנתיב שעדיין לא תקף. צור אחד חתום בסוד הלא נכון כדי לאשר את ריצות בדיקת החתימה שלך. המקרים השליליים הללו הם אלה שנשלחים ללא בדיקה, ומחולל הופך אותם לעבודה של שלושים שניות.
שחזור באג ממשתמש ספציפי
תמיכה מדווחת על בעיה שמתרחשת רק עבור חשבונות עם תפקיד מסוים. צור אסימון בדיוק עם זה role תביעה והמשתמש המושפע's sub, ואתה יכול לשחזר את הבקשה באופן מקומי מבלי לגעת בנתוני הייצור או לבקש מהמשתמש את אסימון הנושא האמיתי שלו, מה שלעולם לא תעשה בכל מקרה.
זריעת פיתוח מקומי
מפתחים חדשים בצוות זקוקים לאסימון עבודה כדי להגיע לנקודות קצה מוגנות בזמן שהאישור הקדמי עדיין נבנה. אסימון שנוצר חתום בסוד הפיתוח המקומי מבטל את החסימה שלהם באופן מיידי.
HS256 לעומת HS384 לעומת HS512: באיזה כדאי להשתמש?
| אלגוריתם | Hash | גודל חתימה | אורך מפתח מינימלי | מתי להשתמש |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 בתים | 32 בתים | ברירת המחדל מהיר, נתמך באופן נרחב, מאובטח כמעט לכל השימושים |
| HS384 | SHA-384 | 48 בתים | 48 בתים | כאשר מדיניות או תקן דורשים SHA-384 |
| HS512 | SHA-512 | 64 בתים | 64 בתים | הקשרים בעלי אבטחה גבוהה, או כאשר אתה כבר מתקנן ב-SHA-512 |
התשובה המעשית היא HS256 אלא אם כן משהו חיצוני דורש אחרת. RFC 7518 דורש שהמפתח יהיה ארוך לפחות כמו פלט ה-hash, אז 32 בתים עבור HS256, 48 עבור HS384 ו-64 עבור HS512. המחולל מזהיר כאשר הסוד המפוענח שלך קצר מהמינימום, מכיוון שמפתח קצר מחליש את החתימה ללא קשר לשם האלגוריתם. אלגוריתם ארוך יותר עם מספרים גבוהים יותר אינו מתקן סוד חלש; סוד אקראי באורך תקין הוא מה שחשוב.
טעויות נפוצות וכיצד להימנע מהן
השכיח שבהם הוא אי התאמה סודית הנגרמת על ידי קידוד המסגרת שלך מאחסנת את הסוד כ-base64, אתה מדביק את מחרוזת base64 כטקסט רגיל, ועכשיו בתים המפתח שונים ממה שהמאמת שלך משתמש החתימות אף פעם לא תואמות ואתה רודף אחרי באג פנטום תקן את זה על ידי בחירת הקידוד הסודי הנכון בכלי כך שבייטים המפתח הגולמי יהיו זהים משני הצדדים.
השני מבלבל בין שניות לאלפיות שניות תביעות הזמן הרשומות ב-RFC 7519 נמדדות כולן בשניות מאז עידן יוניקס. JavaScript's Date.now() מחזירה אלפיות שניות. אם אתה מחשב exp בעצמך ושכח לחלק ב-1000, נראה שהאסימון שלך יפוג בעוד חמישים אלף שנה, מה שכמה מאמתים קפדניים ידחו. לתת למחולל לחשב את הטענות נמנע מכך לחלוטין.
השלישי הוא התייחסות למטען כפרטי זה לא אם אתה מתפתה לאחסן סוד בתביעה, עצור כל מי שיש לו את האסימון יכול לקרוא אותו אחסן רק את מה שנוח לך עם מחזיק האסימון שרואה, ושמור נתונים סודיים באמת בשרת.
היכן JWTs מתאימים לצד כלים אחרים
לאחר שיצרת אסימון, השלב הבא הטבעי הוא לקרוא אותו בחזרה. ה מפענח JWT מפצל כל אסימון לכותרת ולמטען שלו ומסמן שפג תוקפו exp, שזה איך אתה מאשר את הגנרטור הפיק את מה שהתכוונת. אם אתה גם מייצר סודות, ה מחולל Hash מחשב גיבוב SHA בצד הלקוח, ואת מחולל סיסמא מייצר את סוג של מחרוזת אקראית ארוכה שעושה סוד HMAC טוב מלכתחילה.If you want to understand the Base64url step by hand, the מקודד/מפענח Base64 מציג את אותה טרנספורמציה הפיכה שהופכת את הכותרת והמטען לצורתם המקודדת. וכאשר אתה צריך מזהה אקראי כדי לרדת לתוך a sub או jti טענה, ה מחולל UUID נותן לך אחד בפורמט הנכון.
לתמונה הרחבה יותר של מדוע כלים מבוססי דפדפן מרחיקים חומר רגיש משרתי צד שלישי, ה פרטיות נתונים בכלים מקוונים המדריך מסביר את המודל בצד הלקוח, ואת ערכת כלים למפתחי אינטרנט מסכם את כלי השירות שמשתלבים היטב עם עבודת אסימונים.
כיצד שרת מאמת את האסימון שאתה מייצר?
זה עוזר לדעת מה קורה בצד השני, כי זה מסביר למה הסוד ואת הטענות צריך להיות בדיוק נכון כאשר API שלך מקבל אסימון, ספרייה כמו jsonwebtoken, חוזה, או PyJWT עושה שלושה דברים בסדר זה מפצל את האסימון על הנקודות ו Base64url-מפענח את הכותרת לקרוא את alg. זה מחשב מחדש את החתימה header.payload באמצעות הסוד המוגדר ומשווה אותו, בייט עבור בייט, מול קטע החתימה. וזה בודק את הטענות הרשומות: הוא exp בעבר, הוא nbf בעתיד, עושה iss ו aud התאימו למה שה-API מצפה.
כל אחד מאותם בודק מפות למשהו שהמחולל מאפשר לך לשלוט בו. אם האימות נכשל בחתימה, הסוד או הקידוד שלו שונים בין שני הצדדים. אם הוא נכשל exp, פג תוקפו של האסימון, שאולי גרמת בכוונה לבדוק את הנתיב הזה. אם הוא נכשל alg, יצרת אסימון עם אלגוריתם שהמאמת לא מוגדר לקבל, וזה בעצמו דבר שימושי לגלות. יצירת אסימונים עם וריאציות מכוונות היא הדרך שבה אתה ממפה בדיוק איזה בדיקה אוכף ה-API שלך ועל איזה הוא מדלג בשקט.
מילה על ה alg כותרת ספציפית. RFC 7515 מגדיר none כאלגוריתם חוקי לאסימון לא חתום, וספריות מוקדמות היו סומכות על אסימון שטען alg: none ודילג על אימות לחלוטין זו הפגיעות הקלאסית של JWT ספריות מודרניות דוחות אותה כברירת מחדל, אבל המחולל מציע את none אפשרות בדיוק כדי שתוכל להפעיל אסימון לא חתום ב-API שלך ולאשר שהוא אומר לא. אם ה-API שלך אי פעם יקבל אחד, מצאת באג רציני.
איך כדאי לטפל בסודות ואחסון אסימונים?
הסוד שאתה חותם איתו ראוי לאותה הקפדה כמו סיסמת מסד נתונים סוד HMAC טוב הוא מחרוזת ארוכה, אקראית, לא ביטוי בלתי נשכח, כי אבטחת HMAC תלויה בכך שהמפתח אינו ניתן לניחוש יצירת אחד עם כלי סיסמה ואחסוןו בתצורת הסביבה שלך, לעולם לא בבקרת מקור, הוא קו הבסיס כשאתה מסובב אותו, זכור שכל אסימון שנחתם בסוד הישן הופך לבלתי חוקי ברגע שבו המאמת עובר, וזו הסיבה שמערכות ייצור בדרך כלל תומכות ביותר מסוד חוקי אחד במהלך חלון סיבוב.
בצד הלקוח, המקום שבו אתה מאחסן את האסימון המוגמר חשוב כמו איך אתה חותם עליו. אסימון נכנס localStorage ניתן לקריאה על ידי כל JavaScript בדף, כך שפגם סקריפטים חוצה אתרים יחיד מעניק לתוקף אישור חוקי. א httpOnly, Secure, SameSite cookie אינו נראה לסקריפטים, מה שסוגר את הנתיב הזה במחיר של צורך בהגנה על CSRF. הדפוס הנפוץ הוא אסימון גישה קצר מועד השמור בזיכרון ואסימון רענון ארוך יותר ב- httpOnly עוגייה. כל זה לא משנה את האופן שבו אתה מייצר אסימון, אבל ההקשר הוא שהופך אסימון שנוצר לבטוח לשימוש ולא אחריות.
שָׁוא
כיצד אוכל ליצור JWT?
הדבק את הטענות שלך כאובייקט JSON, בחר אלגוריתם חתימה כגון HS256, והזן את הסוד. הכלי base64url-מקודד את הכותרת והמטען, מחשב את חתימת HMAC ומחזיר את האסימון המוגמר כדי שתוכל להעתיק הכל פועל בדפדפן שלך.
אילו אלגוריתמי חתימה נתמכים?
HS256, HS384 ו-HS512, משפחת HMAC, בתוספת "none" ללא חתימה; אפשרות לבדיקה. RS256 ו-ES256 אינם מוצעים בכוונה מכיוון שהם חותמים עם מפתח פרטי, והדבקת מפתח פרטי בדף אינטרנט היא סיכון אבטחה שעדיף להימנע ממנו.
הסוד שלי נשלח לשרת?
מס 'החתימה פועלת כולה בדפדפן שלך דרך ה - API של קריפטו באינטרנט, כך שהסוד והמטען לעולם לא עוזבים את המכשיר שלך אתה יכול לאשר זאת בכרטיסייה רשת DevTools, והכלי ממשיך לעבוד במצב לא מקוון לאחר הטעינה.
כיצד אוכל להגדיר את האסימון לפוג?
הזן תפוגה תוך שניות והכלי מוסיף א exp טענה שווה לזמן הנוכחי פלוס כל כך הרבה שניות לאסימון של רבע שעה הזן 900 השאר את השדה ריק כדי להשמיט exp לגמרי.
למה הסוד צריך להיות לפחות 32 בתים?
RFC 7518 דורש מפתח HMAC לפחות כל עוד פלט ה-hash, שהוא 32 בתים עבור HS256, 48 עבור HS384 ו-64 עבור HS512. סוד קצר יותר מחליש את החתימה, כך שהכלי מזהיר כאשר הסוד המפוענח קצר מדי.
האם אני יכול ליצור אסימון לא חתום?
כן בחר alg none והכלי מייצר header.payload. token עם חתימה ריקה.This is only for testing how your API handles unsigned tokens; רוב הספריות דוחות alg:none כברירת מחדל, וכדאי גם לך.
האם JWT שנוצר מוצפן?
מס 'JWT חתום מקודד, לא מוצפן: כל אחד יכול base64url-פענוח הכותרת ומטען ולקרוא כל טענה החתימה רק מוכיחה התוכן לא שונו לעולם אל תשים סיסמאות או סודות בתוך המטען.
