json web token vs cookie auth

dovid

@clickone אמר בjson web token vs cookie auth:

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

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

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

הדבר היחיד שאני יכול להבין בתהליך הוא שיתוף של ההידר בין 2 שרתים שונים לגמרי, אבל גם בזה אפשר שהקוקיז יהיה תקף ב"קורס" ב2 דומיינים.

אני חושב שאתה טועה, קוקיז לא אמור להכיל משהו מעבר להצפנה של session-id (כל שימוש כאחסון אפילו מוצפן נחשב כמסוכן, לא יודע למה).
קשה להעביר אותו בין שרתים שונים כי טכנית קוקיז שייך לדומיין אב אחד לכל היותר לכן לכל השירותים חייב להיות דומיין אב אחד.
כלומר אם יש לך a.com וגם b.com אתה חייב לעשות פעם אחת לפחות אימות נוסף, ובנוסף בצד השרת אתה צריך להצליב מידע, כלומר לטעון את פרטי המשתמש ממקור משותף.
גם אם מדובר בדומיין אב אחד, צריך בצד השרת של שני השירותים לעשות שימוש משותף בשסנים, או לפחות לבדוק מול הטבלה של השירות השני. זה מה ש@aaron ניסה לחסוך.

dovid

@dovid אמר בjson web token vs cookie auth:

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

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

חוקר

@clickone אמר בjson web token vs cookie auth:

מכירים חברות גדולות שעובדות עם זה? בדקתי בינתיים בבנק פועלים ובגוגל, ושם ראיתי שהם משתמשים בקוקי.

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

dovid

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

חוקר

@dovid אמר בjson web token vs cookie auth:

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

גם בדשבורד שלהם זה עובד כך.
אך ייתכן מהסיבה שבין כך בנו את ל API

yossiz

@clickone תודה רבה על העלאת הנושא. תמיד ידעתי שקיים משהו שנקרא JWT אבל דחפתי את זה למגירה של דברים ללמוד "יום אחד...".

@clickone אמר בjson web token vs cookie auth:

והצעת המתכנת שם לעבור לאימות משתמשים באמצעות JWT.

מסקרן אותי מה הנימוקים שלו? רק בגלל שזה חדש ומבריק?

בדקתי בינתיים בבנק פועלים ובגוגל, ושם ראיתי שהם משתמשים בקוקי

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

לעצם הנושא, זה די חדש לי כנ"ל, אבל יצאתי מהמחקר שלי עם תובנות אלו:
צריך לחלק את הנושא לתת-נושאים,
א) יתרונות/חסרונות של שמירת הרשאות בקוקי לעומת local storage. (ראיתי טענות לכאן ולכאן: בקוקי יש בעית CSRF, ב-local storage אין את ההגנות שנוספו במשך השנים כ-http only ועוד)
ב) יתרונות/חסרונות של שמירת state/session data בלקוח לעומת בשרת. (ראיתי טענות לכאן ולכאן: בשמירת סשן בשרת יש בעיות של scaling, בשמירת סשן בלקוח יש בעיה שאין שליטה על הטוקנים אחרי הנפקתם)

נהנתי מכתבה זו שמסכמת את הנושא בצורה ברורה.

מנצפך

אני בדיוק נדרש כעת לנושא זה.

לדעתי, כפי שכתבו כאן למעלה, ב API חיצוני, זה מאוד מתאים.

אבל בשביל סשן של דף וובי רגיל, זה פחות מתאים.

ההבדלים:

קשה (יותר) לבטל JWT, זה מצריך רשימה שחורה. וזה מוריד את כל הקאצ' של הטוקן.
ב JWT יש פחות התאמה לשמירת נתונים על הסשן הספציפי. (נניח רוצים לשמור רשימת קניות או כל state אחר.

אני משתמש ב JWT בשביל דברים שמצריכים סשן ארוך טווח. נראה לי לזה זה יותר מתאים.

avr416

איזה קטע!!
אני כבר לפחות שנתיים משתמש רק עם jwt.
זה לא איזה משהו חדש.. וזה אכן נראה שזה הסטנדרט היום בכל הפרוייקטים שממשים api.
באנגולר אני רואה את זה כמעט בכל פרוייקט שאני ניגש אליו.
הייתרון של זה שזה אכן מאפשר לך גישה לapi מכל קליינט שהוא (דפדפן, אפליקציה וכו').
וכן לנהל את המשתמשים מסרביס אחד, ולפנות על ידי הטוקן לביצוע פעולות בסרביסים אחרים כמו שכתבו כאן לפני, דבר שנהיה נפוץ יותר ויותר.
למשל https://auth0.com/ מספק לך אפשרות לנהל את כל המשתמשים שלך באפליקציות שונות, במקום מרכזי אחד. (וכמדומני שהם גם היוצרים של jwt..).
ראה כאן עוד הרחבה
https://auth0.com/docs/tokens/json-web-tokens
https://auth0.com/learn/json-web-tokens/

avi rz

בס"ד

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

-

אבל לא כ"כ התרשמתי ולא ראיתי בזה משהו מיוחד כי בעצם,
אם אני עושה טבלה של טוקנים, וכשנכנס משתמש עם השם משתמש והסיסמא שלו, והם נכונים אני מג'נרט לו טוקן, והוא שומר את זה בדפדפן, (אפשר ב LocalStorage) ובכל בקשה לשרת אני שולח, את טוקן, ובודק אם הוא פעיל, (אם לא ביטלו אותו, אם היה בו פעילות לאחרונה, אפשר גם להגביל לip ולסוג דפדפן ומערכת הפעלה ולחצי שנה או שנה מתאריך יצירת הטוקן, וכו'.).

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

avr416

@מנצפך אמר בjson web token vs cookie auth:

ב JWT יש פחות התאמה לשמירת נתונים על הסשן הספציפי. (נניח רוצים לשמור רשימת קניות או כל state אחר.

נכון.
למה שתרצה לשמור את רשימת הקניות בשרת שלך? לא חבל להעמיס עליו? המטרה שלך היא לנצל את כח העיבוד של הקליינט ולהעביר אליו כמה שיותר משימות שהוא יבצע, כדי שהשרת שלך יתמקד במה שהוא צריך לעשות.

את הסטייט תנהל בקליינט.

avi rz

@avi-rz אמר בjson web token vs cookie auth:

בס"ד
סליחה על הבורות.
יכול להיות שחסר לי במה שjwt מכילה,
איך שהבנתי: שולחים את השם משתמש וסיסמא, והיא מחזירה טוקן שאותו שומרים בדפדפן ושולחים אותו לשרת בכל בקשה (כמובן - בקשה שאמורה להיות פרטית)
וכשהשרת מקבל את הטוקן, יש פונקציה שבודקת האם הטוקן הזה פעיל והיא מחזירה true/false.
נ.ב. ראיתי את ה בעבר בהדרכה של ליאור רבינוביץ,
רישום טוקן - שימוש בטוקן
אבל לא כ"כ התרשמתי ולא ראיתי בזה משהו מיוחד כי בעצם,
אם אני עושה טבלה של טוקנים, וכשנכנס משתמש עם השם משתמש והסיסמא שלו, והם נכונים אני מג'נרט לו טוקן, והוא שומר את זה בדפדפן, (אפשר ב LocalStorage) ובכל בקשה לשרת אני שולח, את טוקן, ובודק אם הוא פעיל, (אם לא ביטלו אותו, אם היה בו פעילות לאחרונה, אפשר גם להגביל לip ולסוג דפדפן ומערכת הפעלה ולחצי שנה או שנה מתאריך יצירת הטוקן, וכו'.).

לגבי אבטחה של הטוקן: מה הבעיה לשמור אותו ב dataBase שלי הרי אם יפרצו לשם אז כבר לא יצטרכו טוקן יוכלו לגשת לכל הנתונים גם בלי,

לגבי ממשק מדובר בטבלה אחת וכמה פונקציות.

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

@clickone פיספסתי מידי הרבה דברים על jwt?

nigun

@avi-rz
בא נתחיל ממה שכן הבנת
תתחיל לפרט ואז ידעו מאיפה להתחיל
כי לא ברור על מה אתה שואל על טוקן רגיל או על JWT

dovid

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

תחומים - פורום חרדי מקצועי

json web token vs cookie auth