המדריך המלא לטוקן JWT
מה זה JWT ?
ובכן JWT ראשי תיבות באנגלית של JSONWEB TOKEN , הינו תקן העברת נתונים בין שני צדדים, התקן חופף ועונה לתנאים של ארגון IETF ומחקרRFC-7519.
סינית? בואו נבין רגע משהו בסיסי, כאשר אנחנו מתחברים לפייסבוק שלנו, לאחר שאנחנו מכניסים שם משתמש וסיסמה אנחנו שולחים בקשה לשרתי פייסבוק לצורך זיהוי, אם שם המשתמש והסיסמה נכונים אנחנו בעצם מתחברים לפייסבוק שלנו.
אבל מה זה אומר לפייסבוק "שלנו"? ואיך מעכשיו והלאה כל בקשה שאנחנו עושים כמו יצירת פוסט חדש או תגובה, שרתי פייסבוק יודעים שמדובר בנו ולא באדם אחר?
כדי לפשט את הרעיון של JWT, נדמיין כניסה למועדון, כאשר תחילה עמדנו בכניסה וביקשו לזהות אותנו (למשל המארחת).
לאחר הזיהוי שלנו, המועדון חתם לנו על היד באמצעות חותמת ייחודית שרק המועדון מכיר.
מעכשיו, יתאפשר לנו להסתובב במועדון ולצרוך את כל שירותיו השונים ללא צורך בזיהוי מחדש, אף נוכל לצאת לגמרי מהמועדון ולחזור שנית מאוחר יותר בלי הצורך שהמארחת תזהה אותנו שוב.
למה הדבר דומה?
הדבר דומה לסגירה של הדפדפן והפעלתו מחדש, בהפעלה מחדש אם שמתם לב פייסבוק לא דורשים מאיתנו להתחבר שוב.
איך זה יכול להיות? איך הם יודעים שמדובר באותו המשתמש? התשובה היא שיש מזהה ייחודי שנשאר איתנו ואנחנו סוחבים איתנו אותו לכל מקום.
טוקן / אסימון - "החותמת של המועדון" , הטוקן שפייסבוק מייצרים לנו הוא טוקן בשם Access Token והוא מאפשר לנו לטעון מי אנחנו בכל בקשה שאנחנו עושים לשרת.
מעכשיו ואליך הטוקן ישמש אותנו בכל בקשה שנעשה מול פייסבוק, אז איך הטוקן הזה נראה? ולמה בכלל שנצטרך טוקן ייחודי?
למה צריך טוקן JWT?
אנחנו צריכים טוקן ייחודי כי כפי שאמרנו אנחנו צריכים דרך שבה פייסבוק ידעו לאמת את המשתמש ששולח להם בקשות וכדי שפייסבוק ידעו שלא מדובר במתחזה שמבקש לשנות פרטים או לפרסם בשם שלנו דברים, הטוקן הזה חייב להיות ייחודי ושרק אנחנו במכשיר / בדפדפן שלנו נדע עליו.
אם פייסבוק למשל היו משתמשים במספר המשתמש שלנו עבור הזיהוי שלנו, לדוגמה מספר המשתמש שלנו יהיה 220, אם היינו יכולים בצד הקליינט לשנות את הבקשה ולעדכן שאנחנו בכלל משתמש מספר 221, יכולנו בקלות לשנות פרטים או לפרסם מודעות בשם מישהו אחר.
בשביל זה נוצר רעיון שבו תהיה חותמת ייחודית לכל אדם, חותמת שלא יכולה להיות דומה לשום חותמת אחרת, כך באמצעות קריאה של החותמת פייסבוק יוכלו לדעת במי מדובר, ורק פייסבוק יוכלו לקרוא לפענח את הטוקן כי רק ברשותם היכולת ליצור אחד כזה.
מה היה בעבר לפני JWT ?
בעבר ואף בהווה השתמשו בשיטות שונות ומגוונות לצורך זיהוי משתמשים, השיטה הנפוצה ביותר הייתה יצירת session שבין הלקוח לשרת, לאחר זיהוי המשתמש היה נוצר בזיכרון השרת טוקן ייחודי באורך 128 ביטים אשר היה נשלח למשתמש ונשמר בתוך cookie בדפדפן של המשתמש, את הטוקן הזה המשתמש היה שולח כל פעם לשרת מחדש והשרת היה בודק מול הזיכרון שלו או במקרים אחרים אפילו מול הדאטה בייס האם המשתמש הזה מחובר או לא.
אז מה היה רע לנו עם יצירת סיישן?
הבדיקה שהשרת היה צריך לבצע כל פעם מול הדאטה בייס או מול הזיכרון של עצמו גרמו לאטיות רבה, תחשבו שאם היו 1000 משתמשים אז השרת היה צריך לאחסן 1000 טוקנים בזיכרון שלו כדי לדעת שהם מחוברים ומי כל אחד מהם, הדבר מהווה בעיה כאשר נרצה לעשות סקייל ולגדול עם השרת שלנו לשרת שתומך במליוני משתמשים.
אז איך JWT פתר את הבעיה?
JWT הגיע ונתן מענה, מענה שבו לשרת אין יותר צורך להחזיק נתונים של משתמשים מחוברים.
השרת יכול להסתכל על JWT לפענח אותו ולקרוא את תוכנו.
תחשבו כמה זה חוסך לשרת שהוא לא צריך לשמור שום דבר, למה הדבר דומה? למלון ששם צמיד מיוחד לאורחים שלו, כך בכל כניסה הבדיקה של האורח היא מינימלית ולא דורשת אמצעים מיוחדים.
אז איך נראה טוקן JWT?
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJfaWQiOiI2MTNhN2QzYjQzN2ZhYzJkYTQ2MTA4NjAiLCJzbcmVhdGVkQXQiOjE2MzEyMjMwOTkyOTIsImlhdCI6MTYzMTQ3NTA2OCwiZXhwIjoxNjMxNTYxNDY4fQ.tGEZut7B2yilNJ6RkqBJLiNEcA3cZM9Ev_vby2NjEAg
טוקן JWT בנוי משלושה מרכיבים ,ראש ,תוכן ,חתימה.
אפשר להסתכל על זה כעל שלושה אובייקטים שלכל אחד מהם יש ערכים שונים בתוכו.
שלושת אלו ביחד יוצרים את הטוקן שהוא סך הכל מחרוזת ארוכה שעוברת קידוד והצפנה בחלקה האחרון (חלק החתימה), את הטוקן אפשר לקודד חזרה לפורמט JSON ולראות את תוכנו, בעצם, כל אחד יכול לראות את התוכן שמחזיק הטוקן , כי אחרי הכל החלק הראשון והחלק השני (הראש והתוכן) סך הכל מקודדים בבסיס64 ולא מוצפנים.
הטוקן בנוי משלושה מחרוזות , הראש התוכן והחתימה, כאשר נקודה מפרידה בין כל אחד מהמקטעים, אם אתם תוהים למה החליטו על נקודה המפרידה בין המקטעים? נטו בשביל הקריאות.
אז איך jwt נוצר?
חלק א' - הראש:
הראש הינו חלק שכולל בתוכו אינפורמציה כוללת הקשורה ל:
- א. איזה סוג אלגוריתם הטוקן משתמש, האלגוריתם המתמטי שבאמצעותו ההצפנה של החתימה בוצעה.
- ב. איזה סוג של טוקן זה, ברוב המקרים סוג הטוקן יהיה JWT
"alg": "HS256", "typ": "JWT"התוכן הזה בעצם עובר קידוד בסיס 64, שזה שיטת קידוד נתונים בינאריים בפורמט טקסטואלי (הטקסט הזה יעבור קידוד וממנו תצא מחרוזת ראשונה שתייצג את החלק הראשון של הטוקן שלנו).
זאת אומרת שהאובייקט הזה יקודד למחרוזת הזו
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
חלק ב' - התוכן:
החלק השני שמרכיב את הטוקן שלנו הוא התוכן, ה payload.
החלק הזה מחזיק את הטענות שיש לטוקן שלנו,הטענות הם בעצם השדות השונים ששמורים בתוך הטוקן שלנו, ישנם כמה סוגים של טענות (שדות)
שדות ההרשמה Registered claims
שדות שלרוב יווצרו אוטומטית בזמן יצירת הטוקן על ידי אחת הספריות השונות בהן נשתמש.
- שדה iss - השדה שאומר לנו מי הנפיק את הטוקן, שם השרת שאחראי על ה identity או אולי צד שלישי כמו Auth0.
- שדה exp - שדה מאד חשוב שאומר לנו מתי פג תוקפו של הטוקן שלנו, בהמשך נבין שבעצם לכל טוקן ישנו תאריך תפוגה.
- שדה iat - שדה חשוב נוסף שמאפשר לנו לדעת מתי הונפק הטוקן.
- שדה aud - שדה ה audience עבור איזה קהל יעד הטוקן הזה נוצר.
שדות ציבוריים Public claims
זה הזמן לספר שבדיוק במקום זה נוכל להוסיף גם שדות משלנו, שדות המכילים נתונים כמו אימייל המשתמש , שם , כתובות ותפקידים.
שדות פרטיים Private claims
כנל שדות שנרצה להוסיף שהם פרטיים ומספרים יותר על דברים כמו הרשאות המשתמש איזה הרשאות יש לו האם הוא אדמין המערכת או איש מכירות וכו'.
נוכל להוסיף זאת והאובייקט של ה payload יראה כך
"_id": "613a7d3b437fac2da4610860", "source": "facebook", "email": "[email protected]", "createdAt": 1631223099292, "iat": 1631475068, "exp": 1631561468כנל גם התוכן של ה payload יעבור קידוד זאת אומרת שהאובייקט הזה יקודד למחרוזת הבאה:
eyJfaWQiOiI2MTNhN2QzYjQzN2ZhYzJkYTQ2MTA4NjAiLCJzb3VyY2UiOiJmYWNlYm9vayIsImVtYWlsIjoiZG9jdG9yY29kZUBnbWFpbC5jb20iLCJjcmVhdGVkQXQiOjE2MzEyMjMwOTkyOTIsImlhdCI6MTYzMTQ3NTA2OCwiZXhwIjoxNjMxNTYxNDY4fQ
חלק ג' החתימה:
כדי ליצור את החלק האחרון בטוקן JWT , נאלץ לקחת את הקידוד של החלק הראשון הלא הוא ה header ואת הקידוד של החלק השני הלא הוא ה payload ואת המפתח הסודי הלא הוא ה secret שרק השרת שמנפיק את הטוקן יודע, יחד עם אלגוריתם קריפטוגרפי שנבחר מראש נאחד את 2 המחרוזות המקודדות אל מחרוזת אחת אחרונה שתייצג בעצם את החלק השלישי והאחרון של הטוקן שלנו.
signature = HMACSHA256(EncodedHeader + '.' + EncodedPayload, secret )מהרצת אלגוריתם הקריפטו והרצת הפונקציה צפויה לחזור אלינו מחרוזת חדשה שתהווה החלק האחרון של טוקן ה JWT שלנו.
tGEZut7B2yilNJ6RkqBJLiNEcA3cZM9Ev_vby2NjEAg
אם נחבר עכשיו את התוצאות של חלק א' חלק ב' וחלק ג' נקבל את טוקן ה JWT שלנו.
מה הבעיה לשנות את התוכן ולעבוד על השרת?
אם איזה משתמש שובב חושב לו שהוא יכול ללכת ולשנות את ערכי התוכן ולהתחזות למשתמש אחר, אז הוא יכול להמשיך לחשוב כי אין לו דרך לשנות את התוכן, זה כי החתימה כוללת בתוכה את חלק א' וחלק ב' שנחתמו בזמן החתימה.
כך נגיד שאם מישהו ירצה לשנות לעצמו איזה ערך מסויים, זה לא יעזור לו כי הערך האמיתי חתום בתוך ערך החתימה.
תחשבו על זה ככה , בזמן החתימה
חלק א = בננה🍌
חלק ב = אגס🍑
חלק ג = 🍌 + 🍑 + 🔑
אם יגיע אדם ויחליט לשנות את התוכן של חלק ב' הלא הוא ה payload שמעכשיו הוא בכלל 🍎 תפוח.
הטוקן שלו לא יתקבל על ידי השרת, כי 🍎 אינו חלק מ 🍌 + 🍑.
לצורך המחשה משתמש מנסה לשנות את הבאלנס של הנקודות שיש לו, שוב זה לא יעזור לו כי החלק האמצעי ישתנה אבל החתימה לא, והחתימה המקורית כולל בתוכה את החלק האמצעי הישן והאמיתי.
משמע, השרת יבדוק את הטוקן ויראה שבתוך החתימה יש תוכן שהוא אגס ולא תפוח ולכן השרת ידחה את הבקשה! וכך בעצם נמנע ממשתמש חיצוני לנסות להתחזות לאדם אחר או לשנות לעצמו פרטים בחשבון ללא הרשאה.
מה הוא access token?
כאשר אנחנו מתחברים לשירות מסוים למשל פייסבוק, אנחנו מקבלים 2 סוגי טוקנים הראשון הוא access token והשני לרוב נקרא refresh token.
טוקן הגישה הראשי שאותו אנחנו מקבלים אחרי ביצוע הזדהות מול השרת, את הטוקן הזה נשמור בצד הקליינט ונשלח / נצרף אותו לכל בקשה שנעשה מעכשיו והלאה.
באמצעות שליחת ה access token בכל בקשה השרת יכול לזהות שבאמת מדובר בנו, או באמת מדובר במשתמש אמיתי, או באמת מדובר במשתמש שיש לו את ההרשאות לראות את הנתונים שהוא מבקש ולכן השרת יכול לענות למשתמש בהתאם.
את הטוקן לרוב נצרף ל headers של בקשת ה http שלנו.
לרוב המוסכמה אומרת שצריך לצרף את הטוקן בתור שדה Authorization והטוקן שלנו בתור הערך
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJfaWQiOiI2MTNhN2QzYjQzN2ZhYzJkYTQ2MTA4NjAiLCJzb3VyY2UiOiJmYWNlYm9vayIsImVtYWlsIjoiZG9jdG9yY29kZUBnbWFpbC5jb20iLCJjcmVhdGVkQXQiOjE2MzEyMjMwOTkyOTIsImlhdCI6MTYzMTQ3NTA2OCwiZXhwIjoxNjMxNTYxNDY4fQ.tGEZut7B2yilNJ6RkqBJLiNEcA3cZM9Ev_vby2NjEAgנהוג להוסיף את המילה Bearer לפני הטוקן, זה בעצם סוג ההרשאה שבא אנחנו משתמשים.
מה הוא refresh token?
כפי שלמדנו טוקן הגישה access token נושא עימו חותמת של זמן תפוגה, כאשר הטוקן פג תוקף, נדרש מאיתנו "להתחבר מחדש", לא היינו רוצים שכל 10 דקות כאשר הטוקן שלנו יפוג, להכריח את המשתמש להתחבר מחדש נכון ?
בכדי למנוע את ההתנהגות הלא רצויה הזו, הגיח רעיון הריפרש טוקן.
כמו שהשם מרמז הטוקן הזה נועד כדי לעשות עם השרת החלפה עבור טוקן גישה ראשי חדש.
איך זה עובד?
המשתמש שולח בקשה לחידוש טוקן ושולח לשרת את ה refresh token שברשותו, השרת יעשה את הבדיקות שלו מול הדאטה בייס שלו ויחזיר למשתמש access token חדש בעל תוקף חדש. ( כן, השרת לרוב ישמור את ה refreshToken שלכם בתוך רשימה פשוטה ששם הוא יוכל לעשות את הבדיקות שלו לגבי המשתמש).
למה הסנריו הזה קורה?
- נגיד שהמשתמש התחבר למערכת כלשהי וקיבל בחזרה טוקן גישה ראשי בעל תוקף של 10 דקות בלבד.
- הוא עזב את המחשב וחזר לאחר 20 דקות.
- בנקודה הזו התוקף שלו אינו תקף יותר כך שאם הוא ישלח בקשה לשרת resource כלשהו הוא יקבל שגיאה שהטוקן שלו פג תוקף.
יש 2 דרכים לטפל בבעיה כדי לא לזרוק את המשתמש חזרה לעמוד התחברות מייאש!
- בצד לקוח (באפליקציה הקדמית) אנחנו יכולים לשמור מתי פג התוקף של הטוקן, ולפני כל בקשה שאנחנו שולחים לבדוק האם אנחנו קודם כל צריכים לבצע ריענון, אם אנחנו צריכים לבצע רענון, נשלח את הטוקן refresh token לשרת, כמובן ל route ייעודי וידוע מראש שיחזיר לנו טוקן גישה חדש ורק לאחר מכן נמשיך עם הבקשה המקורית.
- למשל ראוט כזה /api/v1/auth/refresh_token
- ליצור מנגנון חידוש אוטומטי ברקע, silent refresh, ברגע שאנחנו מקבלים שגיאה מסוג "פג תוקף" אוטומטית נשלח את ה refresh token לשרת כמובן ל route ייעודי וידוע, כדי לקבל חזרה טוקן גישה חדש ולאחר מכן שוב לשלוח את אותה הבקשה שנשלחה תחילה אך כשלה.
היתרונות בשימוש ב - JWT
מיקרו שרתים
אם אתם מפתחים מיקרו שרתים אתם בוודאי יודעים שיש שרת אשר אחראי על מערכת התחברות וישנם שרתים נוספים אשר אחראים על תוכן resource.
בוא ניקח לדוגמה אפליקציה של פרסום מודעות של כלבים שאבדו.
באפליקציה הזו יש מן הסתם שרת שאחראי על הרשמה של משתמשים שרת auth. באפליקציה הזו יש גם שרת resource שאחראי על CRUD של מודעות כלבים שרת pets. ואפילו שרת האחראי על הודעות שמשתמשים יכולים לשלוח אחד לשני שרת chat .
השרתי resource יכולים לוודא בקשות שנשלחות אליהם ישירות באמצעות ה JWT, מכיוון שיש להם את היכולת לעשות זאת בין אם יש להם את הסוד secret או שהם משתמשים ב public key ששרת ה auth חושף לכול דורש.
השיטה הזו עוזרת להוריד בקשות מיותרות משרת ה auth ועוזרת לבזר את המיקרו שרתים בצורה קלה ויעילה כך שהמהות של מיקרו שרתים תמשיך להתקיים בלי bottlenecks מיותרים או בלי בדיקות מיותרות בכל שרת.
משקל
השימוש ב JSON עוזר לנו כי JSON שוקל פחות וגם נראה טוב יותר וקריא יותר מאשר XML ועוד יותר כאשר JSON מקודד הוא אף משמעותית קל יותר מפתרונות אחרים.
הקלה על השרת
בעוד sessions נשמרים בצד שרת וגורמים לעומס על זיכרון ram השרת או אפילו על הדאטה בייס, JWT מכילים את כל פרטי המשתמש שהשרת צריך, כך אנחנו יכולים לחסוך מליוני בקשות מיותרות של הלוך ושוב של בדיקות מול הזיכרון של האפליקציה שלנו או של בדיקות הטוקן מול הדאטה בייס שלנו.
מעגל אמון
בעוד שעוגיות cookies מוגבלות פר דומיין , את טוקן ה JWT אפשר לצרף לכל בקשה גם לבקשות שיוצאות דומיינים צד שלישי, כך אפשר לצרוך עם הטוקן שירותים מרובים שדורשים הרשאות שונות בשימוש אחיד.
טוקן אסימטרי לעומת טוקן סימטרי HMAC VS RSA
ישנם כמה דרכים ליצור טוקן JWT
יצירה סימטרית
בשיטה סימטרית השרת מייצר טוקנים באמצעות שימוש במחרוזת secret.
מה זה secret? כל מחרוזת שנבחר שהיא באורך שבין 32 ועד 512 אותיות.
דוגמה רעה למחרוזת סוד:
iWasBornOn1980iWasBornOn1980iWasBornOn1980iWasBornOn1980
דוגמה טובה למחרוזת סוד:
790ae206da02412523e500667336d9abdd27b4fcce5227407f968194690da6eaad5efea6db9aeaa5cd67643e878178a62a52fb98268bea83ba65544c710209fc
יצירה אסימטרית
בשיטה אסימטרית, ישנם 2 מפתחות, מפתח אחד ליצירת טוקנים ומפתח אחד לבדיקתם.
מפתח אחד הוא מפתח סודי שרק השרת שמייצר טוקנים יודע בשם private key, למה? כי הוא מפתח פרטי הרגע אמרנו.
מהמפתח הפרטי, אפשר לייצר מפתח נוסף שנקרא public key, המפתח הזה יאפשר לשרתים אחרים לוודא את הטוקנים שמגיעים אליו אבל לא ליצור חדשים!
תחשבו על כל עניין האסימטריות בצורה הבאה:
סימטרי: יצירת טוקן באמצעות סוד, הסוד מאפשר לייצר או לוודא טוקנים.
אסימטרי: יצירת טוקן באמצעות סוד שמאפשר ליצור טוקנים,ויצירת סוד נוסף (שמועה ) שמאפשר לוודא טוקנים בלבד.
החסרונות בשימוש בחתימה על ידי secret יחיד הם:
- אם יש לנו מיקרו שרתים, בכל שרת אנחנו צריכים לשמור בצורה בטוחה את ה secret שלנו, תארו לכם צוותים רבים שמשום מה אחד מהעובדים באחד מהצוותים נחשף איכשהו ל secret או שאפילו מותקף על ידי האקר שגונב מהמחשב שלו את ה secret, בום, בעיה ה secret הזה משותף לכל השרתים וכולם צריכים באופן מיידי להחליפו.
- היכולת לבצע secret rotation בצורה נוחה וקלה, כל סוד בסוף מתגלה, זה למה צריך ליצור סוד חדש בכל פעם :) אז אין זמן מדויק ליצירת secret חדש אבל קורה שחברות מחליטות לעשות רוטציה של secrets ובתצורה הזו קשה יותר לבצע רוטציה, כי צריך לשנות את הסוד בכל המכונות ובכל המיקרו שרתים קיימים.
- חוסר עקביות - אם כל אחד מהשרתים מסוגל בפוטנציה ליצור טוקנים בעצמו, יהיה קשה לעקוב מי יצר את הטוקן של איזה משתמש.
ישנם דרכים בטוחות יותר לעבוד עם secret וחתימה סימטרית למשל בשימוש ב secret manager כאשר משתמשים בשירותי aws כך שאף אחד חוץ ממנהלים בכירים לא יכול לגשת לעולם לסוד השמור אפילו לא המפתחים ולא הדבאופס.
לשאלת השאלות איפה לשמור JWT ?
אוקי לשאלת השאלות שעולות מדי פעם בפורומים בערוצים השונים, איפה הכי בטוח לשמור את הטוקנים ?
תשובה זריזה למי שאין לו עוד כוחות.
את טוקן הרענון נשמור:
בתור עוגיה בטוחה - cookie httpOnly sameSite
את טוקן הגישה נשמור:
בתור עוגיה בטוחה - cookie httpOnly sameSite
בתוך הזיכרון של האפליקציה באמצעות javascript closure
טוקן רענון
אין בעיה לשמור את טוקן הרענון בתוך cookie httpOnly secure, מהסיבה שהוא לא מכיל שום מידע חשוב על המשתמש, לא אימייל, לא שם המשתמש, שום דבר, טוקן רענון ריק מתוכן, השימוש שלו הוא אך ורק ליצירת טוקן גישה חדש.
אם נשמור את טוקן הרענון ב localStorage או ב sessionStorage נהיו חשופים להתקפות XSS ו CSRF והאקרים יוכלו לגנוב את הטוקן שלנו ולעשות בו שימוש (אומנם למספר דקות עד שהוא יפוג ונבין שמישהו עושה בשם שלנו פעולות באתר).
כדי למנוע את הבעיה הזו, נשמור את טוקן הרענון בתוך עוגיה בטוחה, עוגיה שלא ניתנת לקריאה על ידי javascript כך שתוקף לא יוכל לגשת לעוגיה, אבל כן נהיה חשופים להתקפת CSRF, אבל בגלל ש refresh token במהותו לא הולך להישלח לשרת שלנו בתור בקשת POST אלה רק בתור בקשת GET , שהרי גם אם ההאקר גנב לנו את ה refresh token אין לו דרך לשים יד על ה accessToken החדש ש"ישלח" אליו כי התוכן מגיע בצורה מאובטחת ישירות דרך הדפדפן לעוגיה בטוחה, עוד מעבר לכך אם נדאג ל CORS בצד שרת ההאקר לא יוכל לשלוח בקשת HXR GET מהשרת / אתר שלנו לראוט המאובטח שלנו ולשים את היד שלו על הJWT שלנו.
לכן הכי נכון לשמור את טוקן הרענון תחת עוגיה שמורה.
טוקן הגישה
בואו נבחן את הדרכים שבהן אפשר לשמור את טוקן הגישה
- אחסון מקומי localStorage
- סיישן sessionStorage
- עוגיות cookies
- זיכרון application memory
אופציה ראשונה:
אחסון טוקן הגישה ב localStorage היא האופציה הגרועה מבין כולם, האחסון הזה שורד סגירה של הדפדפן משמע אם נסגור את הדפדפן ונפתח מחדש המידע עדיין יהיה קיים שם,לכן האחסון הזה מאד פריץ חשוף להתקפות פשוטות כמו XSS.
אופציה שנייה:
אחסון טוקן ב sessionStorage כנל אופציה גרועה מכיוון שהאחסון חשוף להתקפות XSS וגרוע מכך בכל סגירה של החלון או טאב של האפליקציה שלנו המידע שם נמחק, זה למה זה נקרא סשיין כי המידע שקיים שם קיים רק בזמן הפעלת האתר לאחר סגירתו באופן מוחלט כל החומר שם נמחק.
אופציה שלישית:
עוגי שוגי עוגיה, עוגיות.
דרך מעולה לשמור את הנתונים שלנו, הדרך הזו חשופה להתקפת XSS, אבל אפשר להתגבר עליה באמצעות שימוש בעוגיות HttpOnly, האופציה הזו גם חשופה להתקפות CSRF אבל אפשר להתגבר על כך בשימוש בפוליסת CORS, X-CSRF-TOKEN עוגיות SameSite.
החיסרון היחיד בשיטה הזו היא שהשרת אוטינטיקציה auth חייב יהיה לשבת על אותו דומיין שבו האפליקציה הקדמית שלנו נמצאת.
אופציה רביעית:
האופציה הבטוחה ביותר אבל הקשה ביותר ליישום, היא האופציה של שמירת הטוקנים בזיכרון האפליקציה שלנו, באופן זמני, אנחנו יכולים לשמור את ה access token שלנו בתוך מקום בקוד שלנו שאין לאף אחד גישה אליו, בג'אווה סקריפט זה אפשרי ליצור מקום כזה באמצעות closures .
החסרון היחיד בשיטה הזו היא שנצטרך למצוא דרך
לשתף את מצב ההתחברות של המשתמש בין טאבים שונים, כי כמו שאתם יודעים בכל טאב שאנחנו פותחים קיימת יישות חדשה לגמרי של האתר / הקוד שלנו.
ליצור מכניזם של רפרוש כך שבכל פעם שנפתח טאב חדש של האתר / אפליקציה שלנו נעשה התחברות שקטה מחדשה באמצעות טוקן ה refreshToken שלנו.
לסיכום
- לעולם אל תשמרו פרטים אישיים של משתמשים על גבי ה JWT זכרו כל אחד יכול לקודד את המידע.
- אם אתם עובדים עם מיקרו שרתים, בדקו את הדרך הנכונה ביותר עבורכם, אין פסול בשימוש בטכניקת secret ואין פסול בשימוש בטכניקת key pairs , הטכניקה המומלצת יותר היום היא כמובן שימוש ב pair keys, אך ישנם שיטות חדשות לבזר את תוכן ה secret כך שהוא יהיה מאובטח מאד בין מיקרו שרתים.
- הדוקטור מקווה שהפוסט עזר לכם להבין קצת יותר על מה הוא טוקן JWT, איך עובדים איתו, ולמה בכלל להשתמש בו.