למה משתמשים מתנתקים באקראי, ואיך מתקנים באגים בסשנים של JWT

למה כל כך קשה לאתר התנתקויות אקראיות?

כי הן תלויות בתזמון. אותו משתמש שעושה אותו דבר מחובר פעם אחת ומנותק בפעם הבאה. לפני ששינים קוד, רושמים כל כישלון אימות עם הסיבה שלו (פג תוקף, חתימה לא תקינה, refresh token לא נמצא, refresh token כבר נוצל) ועם השעה בשרת. עמודת הסיבה בדרך כלל מצביעה ישר על הבעיה.

סיבה 1: שתי בקשות מרעננות את אותו טוקן בבת אחת

תוקף ה־access token פג. הדף שולח שלוש קריאות API באותו רגע; שלושתן מקבלות 401 ושלושתן מנסות לרענן. עם רוטציה של refresh tokens, הרענון הראשון מצליח ומבטל את ה־refresh token הישן, כך ששני האחרים נכשלים והאפליקציה מנתקת את המשתמש. שתי לשוניות פתוחות עושות בדיוק את אותו הדבר.

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

let refreshing = null

function refreshOnce() {
  if (!refreshing) {
    refreshing = api.post("/auth/refresh").finally(() => { refreshing = null })
  }
  return refreshing   // every caller waits for the same refresh
}

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

סיבה 2: תוקף והפרשי שעון

אם השרת שמנפיק טוקנים והשרת שבודק אותם לא מסכימים על השעה, טוקן חדש יכול להיראות כפג תוקף. ‏access tokens קצרים מאוד מחמירים את זה. מסנכרנים את שעוני השרתים, מאפשרים סבילות שעון קטנה בבדיקה, ומרעננים קצת לפני שפג התוקף ולא אחרי ה־401 הראשון.

jwt.verify(token, secret, { clockTolerance: 30 })   // seconds

סיבה 3: הגדרות cookie שמאבדות את הטוקן

אם ה־refresh token נשמר ב־cookie, בודקים את ההגדרות שלו: ה־domain וה־path צריכים לכסות את ה־API, ‏SameSite צריך לאפשר את הבקשה שהאפליקציה שולחת, ‏Secure דורש HTTPS, ותוקף ה־cookie עצמו לא יכול להיות קצר מתוקף ה־refresh token. ‏cookie שלא נשלח בשקט נראה בדיוק כמו התנתקות אקראית.

סיבה 4: שרתים שלא חולקים את אותו סוד

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

איך מוודאים שהתיקון עבד?

• פותחים את האפליקציה בשתי לשוניות, מחכים שתוקף ה־access token יפוג ומשתמשים בשתיהן.
• שולחים כמה קריאות API בבת אחת מיד אחרי שפג התוקף.
• עוקבים אחרי יומן כישלונות האימות לפי סיבה; הסיבה שראיתם קודם צריכה להיעלם.