פשרות כואבות

24/07/2021

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

טכנולוגיות חתימה דיגיטלית איפשרו לנו להנפיק טוקנים שמכילים מידע ולא ניתן לשנות אותם אחרי שיצאו מהשרת שלנו. זה איפשר לשרתים לדלג על בדיקת הטוקן מול בסיס הנתונים ולקרוא את נתוני המשתמשים ישירות מהמידע ששמור בטוקן. ולמה זה מעניין? כי ברגע שאנחנו יכולים לוותר על בדיקת הטוקן מול בסיס הנתונים אפשר גם לוותר על שמירה שלו בבסיס הנתונים והרבה יותר קל להעביר את הטוקן בין מערכות כדי לבנות מערכת Single Sign On.

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

הכי מפתה לבוא ללקוח ולדרוש שיבחר: שחור או לבן, ביצועים או אבטחה, כיסוי קוד או התקדמות מהירה בפיתוח. מפתה אבל לא יעיל. הנדסה טובה היא מה שקורה באמצע, היא הפשרה הכואבת, היא הטוקן שפג תוקף אחרי 5 דקות (או 2, או 8), וה Refresh Token איתו מבקשים טוקן חדש בצורה אוטומטית, וההחלפה האוטומטית של Refresh Token אחרי כל שימוש כדי שלא ייגנב.

זה לא מושלם. זה לא צריך להיות. אבל זה מספיק טוב כדי שאפשר יהיה לעבוד איתו.