json web token vs cookie auth
-
אני מאוד התפלאתי באמת ששמעתי שJWT אמורים/יכולים להחליף cookies.
כי קוקיז זה נתמך בדפדפן, כלומר זה פועל בלי שום ספריית צד לקוח נטו לפי ועל הכותרות של הבקשות.
בד"כ דברים שקופים כאלה עובדים טוב יותר, ובשימוש רחב יותר. השכלולים של הדפדפנים משכללים אותם וכולי.
לעומת זאת JWT זה אומר הכל לבד - צריך ספריית צד לקוח שתקבל את זה ותשלח את זה עם כל בקשה.אבל מחיפוש באינטרנט אני רואה שבהחלט חושבים להשתמש בJWT כתחליף לקוקיז, הוא מוצג כאלטרנטיבה ראשונה בויקיפדיה האנגלית, ויש כאלה באינטרנט שפשוט כותבים שביישום אינטרנטי מודרני חדש "צריך" להשתמש עם JWT.
אחת המעלות שאני רואה לJWT זה אינטגרציה בין מערכות שונות: בעוד הקוקיז הוא סה"כ פיסת זיהוי וצריך לברר שהיא אכן מזהה ואת מי, הJWT בעצם מכיל את הפרטים עצמם ואין צורך לסנכרן טבלאות שסנים בין מערכות שונות. הבעיה של חטיפת הטוקן נראה לי שהיא לא רלוונטית אם נצמדים להנחיות.
-
כמה שידוע לי זה מתחיל להיות סטנדרט, בעיקר בשימושים של REST API,
לבדוק בבנקים זה ודאי לא הראיה..
גוגל גם משתמשים עם זה, רק פחות בשימוש נרחב. אני חושב יותר במערכות API חיצוניות ולא בווב עצמו.(עריכה: אני רואה שדוד כבר הקדימני)
לפי מה שאני מבין הרציונל מאחורי JWT זה לחסוך את האחסון הנפרד של המידע כמו שקורא בעוגיות, (שבעוגיה נשמר UID כלשהו והדאטא מקושר) ובJWT הדאטא מוצפן בטוקן, כשבעצם רק השרת שמחזיק במפתח יכול לפענח.
זה מועיל במצבים שבהם יש יותר משרת בודד, וזה יותר נח מאשר לשתף סשנים של עוגיות בין סרברים..
(במיוחד בעולם הserverless והרצון לכתוב סרוויסים stateless)
בקיצור, הרבה משיטות הSSO מתבססות על זה.לגבי חטיפת טוקנים, לא חושב שיש סיכון יותר גדול מאשר הסיכון בעוגיות. (וכמובן על תשכח להגדיר תוקף לטוקן, אמנם התוקף הוא בתוך הטוקן, אבל אתה סומך על זה שהדאטא בטוקן לא יכול להשתנות כי אתה זה שחתמת אותו..)
-
@dovid אמר בjson web token vs cookie auth:
אני מאוד התפלאתי באמת ששמעתי שJWT אמורים/יכולים להחליף cookies.
כי קוקיז זה נתמך בדפדפן, כלומר זה פועל בלי שום ספריית צד לקוח נטו לפי ועל הכותרות של הבקשות.
בד"כ דברים שקופים כאלה עובדים טוב יותר, ובשימוש רחב יותר. השכלולים של הדפדפנים משכללים אותם וכולי.
לעומת זאת JWT זה אומר הכל לבד - צריך ספריית צד לקוח שתקבל את זה ותשלח את זה עם כל בקשה.מי בכלל משתמש היום בבקשות על בסיס הדפדפן??
הכל היום axios, האפליקציה עצמה לא דורשת בכלל אימות, מקומפלת מראש ונשלחת לדפדפן כערמת JS/CSS/HTML המידע בנפרד על גבי GraphQL, (מה? אתם עוד משתמשים בrest api??)
אז למה בכלל להשתמש בקוקיז?וברצינות, לדעתי JWT זה דרך הגיונית יותר מאשר ערימות הקוקיז שרואים היום באתרים, ויפתור למשל את הרידיירקטים מהסוג שקורה בכניסה לazure, (עוברים איזה 3 פעמים הלוך ושוב בין login.live.com לכל מיני סאבדומיינים) רק כדי להשחיל את הקוקיז כדי שכל הAPI יעבוד..
מתכנתים רוצים שליטה בידים, תן לי את היכולת לשלוט מה נשלח מתי ואיפה..aaron.tchumim@gmail.com
Hetzner - שרתים וירטואליים ופיזיים במחירים מעולים (קישור שותפים)ווצאפ API - תיעוד שירות API לא רשמי.
-
לא רציתי להכנס לדברי המומחים אבל אכן ב 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 אחר.
נכון.
למה שתרצה לשמור את רשימת הקניות בשרת שלך? לא חבל להעמיס עליו? המטרה שלך היא לנצל את כח העיבוד של הקליינט ולהעביר אליו כמה שיותר משימות שהוא יבצע, כדי שהשרת שלך יתמקד במה שהוא צריך לעשות.את הסטייט תנהל בקליינט.
