json web token vs cookie auth
-
לא רציתי להכנס לדברי המומחים אבל אכן ב rast api משתמשים בזה
ומה ששאלת בקשר למה החברות הגדולות לא משתמשים בזה כגון הבנקים וכו לידיעתך בבנקים עד לאחרונה ואפילו כעת בבנקים מסויימים אם אתה רוצה לשלוח איזשהו פניה זה מתבצע דרך ה-פ-ק-ס!!?
כך שבנקים לא תמיד זה ראיה גם יכול להיות שיש להם סטנדרטים שהם צריכים לעמוד בהם ורשמי עדיין אי אפשר להשתמש בזה.... -
@scez-scez
בנק פועלים מבחינתי הוא בנק שאני מתייחס אליו, כי בד"כ הם בחזית הטכנולוגיה בין שלל הבנקים בארץ.בכל מקרה, גימייל עצמם עדיין משתמשים בקוקיז.
@aaron לא הבנתי שזה בציניות, סורי
לגבי הרידיירקט וכו', לא הבנתי איפה הJWT פותר את זה? מה זה משנה איך החוסר אימות הגיע לדפדפן, שלכן הוא צריך להעביר לדף לוגין וכו'?
ז"א, ב2 המקרים, הגיעה בקשה עם הידר שמכיל בתוכה את פרטי המשתמש הנוכחי בדרך כלשהיא, שם יכול להיות גם עוד נתונים,
ואז השרת מחליט שהמשתמש לא מאומת בגלל סיבה, הוא מחזיר תשובה שצריך לעשות לוגין, אם זה SPA, אז זה חוזר בJSON, ואם זה דף רגיל, זה הפניית 301.....אבל מוסכם שבשניהם זה הידר שמצורף לכל בקשה.
אם אני אדחוף את הערך של JWT לתוך קוקיז במקום להידר בירר, ואז אנתח בכניסה את הJWT, זה יהיה שונה?
למה השימוש בהידר מיוחד?הדבר היחיד שאני יכול להבין בתהליך הוא שיתוף של ההידר בין 2 שרתים שונים לגמרי, אבל גם בזה אפשר שהקוקיז יהיה תקף ב"קורס" ב2 דומיינים.
בASP הרגיל ובMVC (שייתכן שבעוד אפליקציות), חלק מהאימות מוצפן בקוקיז, ולא מדובר רק ב SessionId שלו....
אגב, גם בטמפלט האנגולר הרשמי של מייקרוסופט, האימות משתמשים נעשה עם קוקיז ולא עם JWT.לא שכל הטענות האלו באות להוכיח משהו......
סליחה על האריכות..... משהו כאן מתפספס לי
תודה על הזמן שלכם
-
@clickone אמר בjson web token vs cookie auth:
@scez-scez
בנק פועלים מבחינתי הוא בנק שאני מתייחס אליו, כי בד"כ הם בחזית הטכנולוגיה בין שלל הבנקים בארץ.שום דבר בארץ לא בשום חזית טכנולוגית... אני הבאתי ראיה מאתרים עולמיים, של חברות טכנולוגיה.
לבנק הפועלים יש כמו כל גוף ישראלי שפע של מתכנתי פלסטיק שיוצרים דברים מפגרים.
אז נכון שמידי פעם הם מצליחים להביא בשורה תחתונה משהו, אבל תעיף מבט בקוד מקור צד לקוח ותראה שהעבודה שמה ממש "סבבה".הדבר היחיד שאני יכול להבין בתהליך הוא שיתוף של ההידר בין 2 שרתים שונים לגמרי, אבל גם בזה אפשר שהקוקיז יהיה תקף ב"קורס" ב2 דומיינים.
בASP הרגיל ובMVC (שייתכן שבעוד אפליקציות), חלק מהאימות מוצפן בקוקיז, ולא מדובר רק ב SessionId שלו....הדבר היחיד שאני יכול להבין בתהליך הוא שיתוף של ההידר בין 2 שרתים שונים לגמרי, אבל גם בזה אפשר שהקוקיז יהיה תקף ב"קורס" ב2 דומיינים.
אני חושב שאתה טועה, קוקיז לא אמור להכיל משהו מעבר להצפנה של session-id (כל שימוש כאחסון אפילו מוצפן נחשב כמסוכן, לא יודע למה).
קשה להעביר אותו בין שרתים שונים כי טכנית קוקיז שייך לדומיין אב אחד לכל היותר לכן לכל השירותים חייב להיות דומיין אב אחד.
כלומר אם יש לך a.com וגם b.com אתה חייב לעשות פעם אחת לפחות אימות נוסף, ובנוסף בצד השרת אתה צריך להצליב מידע, כלומר לטעון את פרטי המשתמש ממקור משותף.
גם אם מדובר בדומיין אב אחד, צריך בצד השרת של שני השירותים לעשות שימוש משותף בשסנים, או לפחות לבדוק מול הטבלה של השירות השני. זה מה ש@aaron ניסה לחסוך. -
@clickone אמר בjson web token vs cookie auth:
מכירים חברות גדולות שעובדות עם זה? בדקתי בינתיים בבנק פועלים ובגוגל, ושם ראיתי שהם משתמשים בקוקי.
אין לי מושג האם זה נקרא עבורך חברה גדולה, אבל חברת צ'רידי משתמשים בזה.
למשל בכדי לעדכן ביצוע תרומה שנעשתה אצלי בשרת, השרת שלי מזדהה מול השרת שלהם עם jwt.
ואגב יש לזה בדר"כ תוקף של שנה ופעם בשנה אני צריך לבקש להם טוקן חדש..
וגם כל הדשבורד שלהם בדפדפן עובד עם זה -
@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 בשביל דברים שמצריכים סשן ארוך טווח. נראה לי לזה זה יותר מתאים.
-
-
איזה קטע!!
אני כבר לפחות שנתיים משתמש רק עם jwt.
זה לא איזה משהו חדש.. וזה אכן נראה שזה הסטנדרט היום בכל הפרוייקטים שממשים api.
באנגולר אני רואה את זה כמעט בכל פרוייקט שאני ניגש אליו.
הייתרון של זה שזה אכן מאפשר לך גישה לapi מכל קליינט שהוא (דפדפן, אפליקציה וכו').
וכן לנהל את המשתמשים מסרביס אחד, ולפנות על ידי הטוקן לביצוע פעולות בסרביסים אחרים כמו שכתבו כאן לפני, דבר שנהיה נפוץ יותר ויותר.
למשל https://auth0.com/ מספק לך אפשרות לנהל את כל המשתמשים שלך באפליקציות שונות, במקום מרכזי אחד. (וכמדומני שהם גם היוצרים של jwt..).
ראה כאן עוד הרחבה
https://auth0.com/docs/tokens/json-web-tokens
https://auth0.com/learn/json-web-tokens/ -
בס"ד
סליחה על הבורות.
-
יכול להיות שחסר לי במה שjwt מכילה,
איך שהבנתי: שולחים את השם משתמש וסיסמא, והיא מחזירה טוקן שאותו שומרים בדפדפן ושולחים אותו לשרת בכל בקשה (כמובן - בקשה שאמורה להיות פרטית)
וכשהשרת מקבל את הטוקן, יש פונקציה שבודקת האם הטוקן הזה פעיל והיא מחזירה true/false.
נ.ב. ראיתי את ה בעבר בהדרכה של ליאור רבינוביץ,
אבל לא כ"כ התרשמתי ולא ראיתי בזה משהו מיוחד כי בעצם,
אם אני עושה טבלה של טוקנים, וכשנכנס משתמש עם השם משתמש והסיסמא שלו, והם נכונים אני מג'נרט לו טוקן, והוא שומר את זה בדפדפן, (אפשר ב LocalStorage) ובכל בקשה לשרת אני שולח, את טוקן, ובודק אם הוא פעיל, (אם לא ביטלו אותו, אם היה בו פעילות לאחרונה, אפשר גם להגביל לip ולסוג דפדפן ומערכת הפעלה ולחצי שנה או שנה מתאריך יצירת הטוקן, וכו'.).-
לגבי אבטחה של הטוקן: מה הבעיה לשמור אותו ב dataBase שלי הרי אם יפרצו לשם אז כבר לא יצטרכו טוקן יוכלו לגשת לכל הנתונים גם בלי,
-
לגבי ממשק מדובר בטבלה אחת וכמה פונקציות.
-
לגבי גישה מכל המכשירים: בכל מקרה בכל מכשיר יצטרכו להתחבר מחדש כי צריך לשמור את הטוקן במקום שהאפליקציה נותנת.
-
-
@מנצפך אמר בjson web token vs cookie auth:
- ב JWT יש פחות התאמה לשמירת נתונים על הסשן הספציפי. (נניח רוצים לשמור רשימת קניות או כל state אחר.
נכון.
למה שתרצה לשמור את רשימת הקניות בשרת שלך? לא חבל להעמיס עליו? המטרה שלך היא לנצל את כח העיבוד של הקליינט ולהעביר אליו כמה שיותר משימות שהוא יבצע, כדי שהשרת שלך יתמקד במה שהוא צריך לעשות.את הסטייט תנהל בקליינט.
-
@avi-rz אמר בjson web token vs cookie auth:
בס"ד
סליחה על הבורות.
יכול להיות שחסר לי במה שjwt מכילה,
איך שהבנתי: שולחים את השם משתמש וסיסמא, והיא מחזירה טוקן שאותו שומרים בדפדפן ושולחים אותו לשרת בכל בקשה (כמובן - בקשה שאמורה להיות פרטית)
וכשהשרת מקבל את הטוקן, יש פונקציה שבודקת האם הטוקן הזה פעיל והיא מחזירה true/false.
נ.ב. ראיתי את ה בעבר בהדרכה של ליאור רבינוביץ,
רישום טוקן - שימוש בטוקן
אבל לא כ"כ התרשמתי ולא ראיתי בזה משהו מיוחד כי בעצם,
אם אני עושה טבלה של טוקנים, וכשנכנס משתמש עם השם משתמש והסיסמא שלו, והם נכונים אני מג'נרט לו טוקן, והוא שומר את זה בדפדפן, (אפשר ב LocalStorage) ובכל בקשה לשרת אני שולח, את טוקן, ובודק אם הוא פעיל, (אם לא ביטלו אותו, אם היה בו פעילות לאחרונה, אפשר גם להגביל לip ולסוג דפדפן ומערכת הפעלה ולחצי שנה או שנה מתאריך יצירת הטוקן, וכו'.).לגבי אבטחה של הטוקן: מה הבעיה לשמור אותו ב dataBase שלי הרי אם יפרצו לשם אז כבר לא יצטרכו טוקן יוכלו לגשת לכל הנתונים גם בלי,
לגבי ממשק מדובר בטבלה אחת וכמה פונקציות.
לגבי גישה מכל המכשירים: בכל מקרה בכל מכשיר יצטרכו להתחבר מחדש כי צריך לשמור את הטוקן במקום שהאפליקציה נותנת.
@clickone פיספסתי מידי הרבה דברים על jwt?
