- בלוג
- מהו OAuth 2.0 וכיצד הוא משפר את אבטחת הגישה באינטרנט?
מהו OAuth 2.0 וכיצד הוא משפר את אבטחת הגישה באינטרנט?
- תפקידים (Roles)
- שלבי הפעולה
- היתרונות של פרוטוקול OAuth 2.0
- החסרונות של OAuth 2.0
- לסיכום...
מהו OAuth 2.0 וכיצד הוא משפר את אבטחת הגישה באינטרנט?
פורסם ב 26-10-2024
מה זה?
OAuth 2.0 – או בשמו המלא Open Authorization (גירסה 2.0) – כשמו, הוא פרוטוקול בתקן פתוח (כלומר, תקן אשר ניתן להטמיע ולעדכן באופן חופשי וחינמי) להענקת הרשאות גישה לשירותים ולשרתים שונים (בדרך כלל יישומים, אפליקציות או מכשירים) באינטגרציה עם שירותים או שרתים אחרים.
ל-OAuth 2.0 יש יתרון ברור על פני הענקת הרשאות "מסורתית" – בעוד האחרונה מצריכה הזנת שם משתמש וסיסמה, שיכולים להתגלות בדרכים שונות (למשל, באמצעות פישינג, חדירה לרשת הווייפיי שלכם, סוס טרויאני חמקמק ועוד לא מעט מרעין בישין),OAuth 2.0 מאפשר לבצע שיתוף הרשאות באמצעות שימוש באסימונים (Tokens) המוצפנים בזמן המעבר שלהם מנקודה אחת לשניה (Encryption of Data in Transit). כל אסימון הוא למעשה תעודת הרשאה, באמצעותה היישומים והשירותים השונים מוכיחים כי קיבלו הרשאות רלוונטיות להשתמש במשאבים מסויימים.
כך, נמנע הצורך בשיתוף פרטי לוגין, ומתן ההרשאות בין השירותים מתבצע בצורה יותר בטוחה למשתמש, לפחות פוטנציאלית.
כדי שהאסימונים יישארו בלעדיים ובטוחים לשימוש לאורך המעבר, הם חייבים להישאר מוצפנים. כדי שהאסימונים יישארו מוצפנים הן בזמן המעבר שלהם מהאפליקציה לשירות ממנו היא מבקש הרשאות, ההעברה והאחסון שלהם מתבצעים באמצעות חיבור מאובטח (SSL).
בנוסף, האסימונים הראשונים שנשלחים הם בעלי תוקף מוגבל, בדרך כלל לזמן קצר. כדי שלא נצטרך לעבור את תהליך הענקת ההרשאה כל פעם מחדש, האפליקציה שקיבלה את ההרשאה מייצרת אסימון-רענון (refresh token). כך מתאפשרים שני דברים: הראשון הוא שהתהליך נשאר מאובטח ואיננו מצריך את תשומת ליבו של המשתמש. השני הוא שניתן להשתמש בשירות המעניק את ההרשאות ללא צורך בחיבור מחדש כל פעם בינו לבין האפליקציה. לדוגמה, אם הענקנו לאפליקציה מסויימת גישה דרך הדפדפן למשאבים מסויימים בפייסבוק, משמע הזנו את שם המשתמש והסיסמה שלנו, מתן הרשאות לשירות אחר לא יצריך הזנת שם משתמש וסיסמה שוב.
במהלך התהליך, אסימון-הרענון מאבד גם הוא מתוקפו ונשלח אסימון-רענון חדש. בנוסף, האפליקציה יכולה לבטל את הגישה, או את משלוח האסימונים ואת החיבור לגורם ממנו היא מבקשת את ההרשאות, במידת הצורך.
דוגמה טובה לשימוש ב- OAuth 2.0 הוא מתן הרשאה לשירות כלשהו להשתמש בחשבון הפייסבוק שלכם. כאשר השירות מבקש שם משתמש וסיסמה לשם כך, שימו לב שנפתח עמוד שנראה כמו עמוד הכניסה לפייסבוק, אבל בקטן. כך, השירת בעצם מבקש מפייסבוק "אישור" לפרסם מידע בציר-הזמן שלכם בפייסבוק, ואתם מאשרים לפייסבוק "להרשות" לאפליקציה לעשות זאת, באמצעות "כניסה" לחשבון שלכם. פייסבוק, באישורכם, נותן לשירות אסימונים מוצפנים שמהווים אישור (הרשאה) לשירות לבצע פעולות מסויימות בחשבון הפייסבוק שלכם. וכל זה מתבצע בלי שתצטרכו לתת לשירות את פרטי המשתמש והסיסמה שלכם.
דוגמה נוספת, עליה כתבנו לא מזמן, היא המעבר של גוגל לשימוש ב"אפליקציות מאובטחות" עם Gmail. ה"אפליקציות המאובטחות" ( גוגל מגדירה אפליקציות מאובטחות כאפליקציות שמשתמשות ב-OAuth 2.0) יקבלו אסימונים מוצפנים מ-Gmail כהרשאות להשתמש בה ולהסתנכרן איתה. החלפת האסימונים תתבצע באמצעות "Sign-in With Google" – כלומר, האפליקציה תבקש אישור מגוגל להשתמש בחלקים מסויימים מהפלטפורמה שלה, וגוגל תעניק לה הרשאות בצורת אסימונים מוצפנים לעשות זאת. שוב, כל זה מבלי לחשוף את שם המשתמש והסיסמה בגוגל לאפליקציות.
כיום, מרבית השימוש הוא ב- OAuth 2.0 , הגירסה ה"מפותחת" של הפרוטוקול. זאת מאחר ויותר ויותר אפליקציות עוברות להשתמש בפרוטוקול, ו-OAuth 1.0 היה מיועד לאתרי אינטרנט בלבד.
לא ניתן "לשדרג" את OAuth 1.0 ל-OAuth 2.0, מפני ש-OAuth 2.0 הוא למעשה עיצוב-מחדש של OAuth 1.0, ולא שדרוג שלו.
בהתאם לכך, כתבנו בעיקר על OAuth 2.0, למרות שאפשר לייחס את מהות הדברים גם ל-OAuth 1.0 – הרעיון, בבסיסו, הוא דומה.
תפקידים (Roles)
OAuth 2.0 מגדיר ארבעה גורמים שצריכים לתקשר ביניהם בכדי ש"עסקת" OAuth 2.0 (כלומר, הענקת האסימונים לשם הרשאות) תתבצע. גורמים אלו מכונים "תפקידים".
הגורם הראשון הוא "בעל המשאבים" (Resource Owner) – ה"ישות" שמעניקה גישה למשאבים המוגנים (המצריכים הרשאות – אסימונים – כדי לגשת אליהם). במרבית המקרים, מדובר במשתמש-הקצה – כלומר, אנחנו.
הגורם השני הוא "שרת המשאבים" (Resource server) – או, השרת המאכלס את אותם משאבים מוגנים. בהשאלה מהדוגמה הראשונה שהבאנו שש פסקאות אחורה, אם אנחנו הגורם הראשון, הגורם השני יכול להיות פייסבוק.
גורם מספר שלוש הוא ה"לקוח" (Client) – האפליקציה או השירות שמבקשים, בשם בעל המשאבים, את הרשאות הגישה למשאבים המוגנים. החלפת האסימונים למעשה מתבצעת בין הלקוח לבין שרת המשאבים.
ישנם שני סוגי לקוח:
- חסוי (Confidential): לקוח שמסוגל לשמור על אבטחתם של אישורי הגישה שלו (לדוגמה, באמצעות אחסונם על שרת מאובטח בעל גישה מוגבלת), או בעל אמצעים אחרים לאבטחת אישורי האימות שלו.
- ציבורי (Public): לקוח ללא יכולת לשמור על אבטחתם של אישורי הגישה שלו, וללא יכולת להגן על אישורי האימות שלו. לדוגמה, אפליקציה מבוססת דפדפן נחשבת ללקוח ציבורי.
והגורם הרביעי, שרת ההרשאות (Authorization Server) – הוא השרת שמאמת כי בעל המשאבים (המשתמש) והלקוח הם מי שהם טוענים שהם, ומעניק את אסימוני ההרשאות ללקוח.
שרת ההרשאות מזהה את סוג הלקוח לפי הגדרתו מהו אימות מאובטח, ולפי רמת חשיפת אישורי הגישה של הלקוח.
שלבי הפעולה
1. הלקוח למעשה מתחיל את השלב הראשון, בו הוא מבקש מבעל המשאבים אישור לגשת למשאבים מסויימים הנמצאים עליו. למעשה, הוא מבקש מבעל המשאבים לבקש משרת ההרשאות להעניק את האסימונים הדרושים.
2. כאשר בעל המשאבים מזין את אישורי הגישה שלו (לנו זה בעיקר מוכר כהזנת שם המשתמש והסיסמה שלנו אצל שרת המשאבים ממנו הלקוח רוצה לבקש גישה), הלקוח מקבל את האישור אותו הוא היה צריך – את מענק ההרשאה.
מענקי גישה מתחלקים לארבעה סוגים:
קוד הרשאה (Authorization Code) – המתקבל באמצעות שימוש בשרת הרשאות המתווך בין הלקוח לבין בעל המשאבים. כאשר פרוטוקול האימות משתמש בקוד הרשאה, הלקוח "מבקש" מבעל המשאבים לפנות לשרת ההרשאות, ושרת ההרשאות מחזיר את בעל המשאבים ללקוח עם קוד ההרשאה, לאחר ביצוע אימות.
"מרומז" (Implicit) – מענק הרשאה בתהליך פשוט יחסית, המשמש לקוחות ש"יושבים" על דפדפן אינטרנט. מענק הרשאה זה משתמש בשפת תכנות, כמו Javascript. כאן, הלקוח מקבל אסימון אישור ישירות מבעל המשאבים. כלומר, שרת ההרשאות לא מאמת מיהו הלקוח.
מענק הרשאה "מרומז" הוא יותר מהיר ויעיל מצד אחד – הוא "חוסך" את כל שרשרת התיווך. מצד שני, הוא הרבה פחות בטוח – שכן, ניתן לקבל אליו גישה יותר בקלות.
אישורי גישת בעל משאבים באמצעות סיסמה (Resource Owner Password Credentials) – כאשר באמצעות שימוש באישורי ההרשאה של בעל המשאבים - לרוב שם משתמש וסיסמה - הלקוח מקבל את מענק ההרשאה.
אישורי גישת לקוח (Client Credentials) – כמשתמע מהשם, מענק הרשאה זה מתקבל כאשר הלקוח משתמש באישורי הגישה שלו. שימוש במענק גישה זה מתבצע כאשר ישנו צורך בגישה למשאבים מוגנים הנמצאים ב"בעלות" הלקוח, וכאשר הלקוח הוא גם בעל המשאבים.
3. הלקוח "מציג" לשרת ההרשאות את מענק-ההרשאה כדי לקבל אסימוני הרשאות למשאבים אותם הוא צריך (הממוקמים על שרת המשאבים). לרוב מדובר בקוד הרשאה.
4. שרת ההרשאות מבצע אימות של הלקוח ושל מענק ההרשאה. ברגע שהאימות מתבצע, אסימוני ההרשאות הרלוונטיים מוענקים ללקוח.
5. הלקוח פונה לשרת המשאבים כדי לבקש ממנו גישה למשאבים אותם הוא צריך. בתמורה לשימוש, הוא מציג את אסימוני ההרשאה שקיבל קודם משרת ההרשאות.
6. שרת המשאבים מבצע אימות של אסימוני ההרשאה – דמיינו סצינה בה רוכל חשדן בודק מטבעות זהב באמצעות השיניים. כאשר אסימוני ההרשאה מאומתים, שרת המשאבים מעניק ללקוח רשות להשתמש במשאבים הרלוונטיים.
היתרונות של פרוטוקול OAuth 2.0
אבטחה ופרטיות: כפי שציינו, הייתרון העיקרי של פרוטוקול OAuth 2.0 הוא פוטנציאל האבטחה המוגבר שגלום בו. המשתמשים אינם חושפים את פרטי האימות שלהם, מאחר וקבלת ההרשאות והאימות מתבצעים באמצעות אסימונים מוצפנים. ולא רק שהאסימונים מוצפנים, הם מתחלפים ומתחדשים. הימנעות ממתן פרטים לגורמי צד שלישי, שעשויים להיחשף לגורמים עויינים, טומנת בחובה שכבת אבטחה וחיסיון שיכולים לעכב או למנוע גישה לא מורשית.
פשטות: OAuth 2.0 מאפשרת להשתמש בהמון שירותים ללא צורך ליצור חשבון, שם משתמש וסיסמה בכל אחד (שלא נדבר על לזכור אותם, או ליצור רשימה בטוחה של כולם).
ליתרון זה יש בונוס נחמד ביומיום: לא מעט מהיישומים המאפשרים שימוש ב-OAuth 2.0 הם אלה שהמון אנשים משתמשים בהם באופן שוטף: גוגל, פייסבוק, לינקדין וכדומה. לא רק שבמרבית המקרים החשבונות האלה כבר רשומים למערכת באופן אוטומטי, הרי שאת שמות המשתמש והסיסמה לחשבונות אלה אנשים בדרך כלל זוכרים.
יתרון זה גם מייעל את שטף העבודה והגישה בסביבות פיתוח ובסביבות עבודה באופן כללי.
גמישות: מטבעו, פרוטוקול OAuth 2.0 הוא מאוד גמיש ו-וורסטילי. משמע, ניתן להטמיע אותו במגוון רחב מאוד של פלטפורמות וצורות. בשל גמישות זו, ניתן למצוא אותו באינטגרציה של שירותים ואפליקציות עם רשתות חברתיות, בשימוש לאימות של אפליקציות, במתן גישה של כלי פיתוח צד-שלישי לממשקים שונים, בפתרונות SSO (כניסה יחידה – Single Sign-In), באימות של מכשירי IoT, ועוד.
בנוסף, מאחר ו-OAuth 2.0 הוא סטנדרט פתוח, מפתחים יכולים לבצע בו אדפטציות המותאמות למוצרים שלהם ולצרכים של המשתמשים.
החסרונות של OAuth 2.0
פרוטוקול הרשאות, לא פרוטוקול אימות: אמנם זה לא חיסרון במובן הקלאסי, אך עדיין ניתן להחשיב אותו כחיסרון. זאת, מאחר ובלא מעט מקרים OAuth 2.0 נחשב לפרוטוקול אימות ומשמש בתפקיד זה, למרות שאין זה מתפקידו. שימוש בפרוטוקול OAuth 2.0 כפרוטוקול אימות יכול להוביל לאינספור בעיות אבטחה שונות. אמנם לא נדון בהן, אבל ניתן לדמות מצב כזה לשימוש בגרזן כדי לנעוץ מסמר בקיר.
פגיעויות שונות: למרות שמטרתו של פרוטוקול OAuth 2.0 הוא מתן הרשאות בצורה בטוחה יותר, הוא איננו חף מפגיעויות אבטחה.
שימוש במענק-גישה "מרומז", למשל, מאלץ את הלקוח למצוא מקום אחסון לפרטי המשתמש אם יש צורך להשאיר את הגישה פתוחה לאחר שהמשתמש סוגר את הדפדפן. לפרטי משתמש מאוכסנים, מן הסתם, ניתן להגיע.
ישנו מגוון לא קטן של מתקפות שניתן לבצע על תהליך האצלת ההרשאות שמתבצע באמצעות הפרוטוקול. מתקפות CRFS, גניבת ו"דליפת" אסימוני הרשאות באמצעות מתקפות XSS ,הזרקות HTML ומתקפות MITM, מהווים חלק קטן מרשימה ארוכה.
בנוסף, ה"תפקידים" השונים תלויים באבטחה אחד של השני. אם, לדוגמה, הלקוח פגיע או שמצויה בו פרצה כלשהי, כל השאר (בעיקר בעל המשאבים – המשתמש) נמצאים גם הם תחת סכנה.
גם להצפנת האסימונים אין הגדרה, ולא קיים סטנדרט מסויים כיצד אסימונים צריכים להיות מוצפנים בפועל. משמעות הדבר היא שמי שמצליח להשיג את האסימונים באמצעות מתקפה כלשהי יכול לדעת את תוכנם וגם להשתמש בהם.
הטמעה מורכבת: למרות שלא קשה במיוחד להטמיע את הפרוטוקול במערכת כלשהי, הוא עדיין בעל הסתעפויות, אופציות, קונפיגורציות , הרחבות ותוספות שונות. כאן, ה-וורסטיליות שלו מהווה חרב פיפיות, והייתרון הופך לחיסרון. מי שלא מכיר את הפרוטוקול היטב, ולא מבצע התאמה למוצר העתיד להשתמש ב-OAuth, יכול בקלות ליצור המון פגיעויות וחורי אבטחה בתהליך.
לסיכום...
פרוטוקול OAuth 2.0 הוא מטבע בעל שני צדדים.
מצד אחד, הוא מציע כמה נדבכים של אבטחה ופרטיות. הוא מסייע לשמור על פרטיותם של משתמשים ושל מערכות, באמצעות הענקת גישה סלקטיבית ובדרך שדואגת שפרטי המשתמש יישארו חסויים. הוא גמיש וניתן לאדפטציה על מערכות ומצבים שונים, ובזכותו, חיבור מאובטח נעשה פשוט ויעיל יותר עבור המשתמשים.
מצד שני, כמו כל מנגנון הגנה, גם לו יש את החולשות שלו. בגלל שדרך הפעולה שלו יחסית מסועפת, הוא חשוף ללא מעט סוגי מתקפות. כל אחד מה"שבילים" בין הגורמים השונים במערכת הוא גם הזדמנות לגורם עויין לתקוף את המערכת או למצוא איזו חולשה שניתן לנצל.
זאת ועוד – אם נשווה את כל הגורמים בו לשרשרת, הרי שחוזקה של כל שרשרת נמדד בחוליה החלשה ביותר שלה. התפקידים, בעיקר, תלויים זה באבטחתו של השני, ולכן כל חולשה באחד מהם יכולה לחשוף את האחרים לסכנות אבטחה שונות. נקווה שבגירסאותיו הבאות, יינתן מענה ראוי לכל (או לפחות לרוב) האתגרים שהוא מציב וניצבים בפניו.
הבאנו את עיקרי הדברים בלבד לגבי פרוטוקול OAuth 2.0, ואנו ממליצים הן למי שמעוניין לדעת יותר והן למי שהטמעת הפרוטוקול נוגעת אליו באופן "אישי" – מפתחים, בעלי שרתים וכדומה – להתעמק ולהכיר אותו יותר טוב כדי לשמור על אבטחה חזקה
לפרטים נוספים ולכל דבר אחר, נשמח אם תצרו איתנו קשר.
שאלות נפוצות של Jetserver – כל מה שצריך לדעת
OAuth 2.0 (או בשמו המלא, Open Authorization) הוא הגירסה השניה והמשופרת של פרוטוקול OAuth – פרוטוקול אימות בתקן פתוח, שנועד להעניק לשירותים ולשרתים ברשת האינטרנט הרשאות גישה לאינטגרציה והתממשקות עם שרתים ושירותים אחרים.
פרוטוקול בתקן פתוח (Open Standard Protocol) הוא פרוטוקול (כלומר, סט של חוקים ו"צעדים") שניתן להטמיע באופן חינמי וחופשי, ללא מגבלות וללא תשלום לספקים. ניתן להטמיע אותו על כל מערכת ועל כל מכשיר (בהתאם לפרוטוקול ולמטרתו), ללא תשלום או צורך באישור מִסַפָּק כלשהו.
פרוטוקול OAuth 2.0 נותן למשתמשים את האפשרות להשתמש בשירותים שונים מבלי לפתוח חשבונות משתמש נוספים, מבלי לספק פרטי זיהוי ופרטים אישיים אחרים, ומבלי לחשוף פרטי אימות כמו שם משתמש או סיסמה. נוסף על כך, הוא מאפשר גישה מהירה ופשוטה יותר לשירותים השונים – ניתן להשתמש בחשבון אחד (למשל, החשבון בגוגל) כדי להיכנס למגוון גדול של שירותים שונים.
כך, OAuth 2.0 מאפשר לנו לשמור על פרטיות ועל רמות אבטחת מידע מוגברות, ובו בזמן חוסך לנו זמן ומקנה לנו שימוש מהיר ופשוט יותר.
הפרוטוקול אינו מעניק הרשאות, אלא מאפשר הענקת הרשאות גישה משרת/יישום רשת אחד, לשרת/יישום רשת אחר, על מנת להתממשק עם שירות כלשהו או על מנת להעניק הרשאת גישה לנתון כלשהו של המשתמש, שנמצא "בידיו" שירות רשת מסוים.
הענקת הגישה באמצעות פרוטוקול OAuth 2.0 מתבססת על אסימוני הרשאות – תעודות דיגיטליות מוצפנות (קבצים) המאפשרות לצד השלישי (שירות, שרת, אפליקציה וכדומה) לקבל גישה למידע כלשהו של המשתמש, אשר נמצא "בידיו" של שירות רשת אחר, מבלי שהמשתמש יצטרך לחשוף פרטי כניסה או זיהוי כלשהם.
כל אסימון מעניק הרשאה רק למידע הנחוץ לשירות, על מנת שיוכל לבצע את הפעולה שהוא צריך.
- 1. בקרת גישה: האסימונים מאפשרים גישה למידע הנחוץ בלבד כדי שהשירות הרלוונטי יבצע את הפעולה שהוא צריך.
- 2. מוצפנים בזמן המעבר: אסימוני הגישה מוצפנים כשהם יוצאים מהשרת השולח, ומפוענחים רק כשהם מגיעים ליעדם.
- 3. בעלי תוקף מוגבל: תוקפם של אסימוני הגישה פג לאחר זמן קצר, כך שגורמים עוינים לא יכולים להשתמש בהם שוב.
- 4. השליטה בידיים של המשתמש: ניתן, דרך השרת/יישום ש"הנפיק" את האסימונים, לבטל אותם בכל עת.
פרוטוקול OAuth 2.0 מגדיר ארבעה "תפקידים", או ארבעה גורמים, שצריכים לתקשר ביניהם כדי שהענקת אסימוני ההרשאות תתבצע:
- 1. בעל המשאבים (Resource Owner) – המעניק גישה למשאבים המוגנים (לרוב, זהו משתמש הקצה).
- 2. שרת המשאבים (Resource Server) – השרת או השירות שמחזיק במשאבים המוגנים.
- 3. לקוח (Client) - האפליקציה או השירות שמבקשים, בשם בעל המשאבים, את הרשאות הגישה (האסימונים) למשאבים המוגנים.
- 4. שרת ההרשאות (Authorization Server) - השרת שמאמת את זהותם של בעל המשאבים ושל הלקוח, ומעניק את אסימוני ההרשאות ללקוח.
- 1. הלקוח מבקש מבעל המשאבים אישור לגשת למשאבים מסויימים בהם הוא מחזיק (כלומר, מבקש מבעל המשאבים לבקש משרת ההרשאות להעניק את האסימונים הדרושים לשם כך).
- 2. בעל המשאבים מזין את אישורי הגישה שלו (בדרך כלל שם המשתמש והסיסמה אצל שרת המשאבים ממנו הלקוח רוצה לבקש גישה), והלקוח מקבל את מענק-ההרשאה לו הוא זקוק.
- 3. הלקוח "מציג" לשרת ההרשאות את מענק-ההרשאה כדי לקבל אסימוני הרשאות למשאבים אותם הוא צריך (הממוקמים על שרת המשאבים).
- 4. שרת ההרשאות מאמת את זהותו של הלקוח ואת האותנטיות של מענק ההרשאה. לאחר שהשניים מאומתים ,שרת ההרשאות מעניק את אסימוני ההרשאות ללקוח.
- 5. הלקוח פונה לשרת המשאבים כדי לבקש ממנו גישה למשאבים אותם הוא צריך. לשם כך, הוא מציג את אסימוני ההרשאה שקיבל קודם משרת ההרשאות.
- 6. שרת המשאבים מאמת את ה"אותנטיות" אסימוני ההרשאה. כאשר אסימוני ההרשאה מאומתים, שרת המשאבים מעניק ללקוח רשות להשתמש במשאבים הרלוונטיים.
אבטחה ופרטיות – שימוש בפרוטוקול OAuth 2.0, הודות לשימוש באסימוני הרשאה מוצפנים, מאפשר להשתמש בשרותים שונים שמצריכים אימות זהות או מתן גישה לפרטים חשובים, מבלי לחשוף פרטים אישיים כמו שם משתמש וסיסמה.
פשטות וזמינות – OAuth 2.0 מאפשר להשתמש בהמון שירותים מבלי לפתוח חשבונות נוספים ולזכור את הפרטים שלהם – שירותים רבים נסמכים על מתן גישה באמצעות OAuth דרך פלטפורמות שכמעט כולם משתמשים בהן, כמו פייסבוק, גוגל, לינקדין וכדומה.
גמישות – OAuth 2.0 הוא פרוטוקול בתקן פתוח, כך שניתן להטמיע אותו במגוון רחב של פלטפורמות, מערכות ושירותים.
לא, OAuth 2.0 הוא לא פרוטוקול אימות. אימות (Authentication) הוא תהליך שנועד לאשר זהות – OAuth 2.0 לא מאשר את זהותו של המשתמש או של השירות. תהליך האימות עצמו, במסגרת הפרוטוקול, מתבצע על ידי שרת ההרשאות ועל ידי שרת המשאבים.
OAuth 2.0 הוא פרוטוקול להענקת הרשאות לשירות כלשהו לשימוש במידע שנמצא אצל שירות אחר, מבלי לחשוף את פרטי האימות והזיהוי שלנו.
בפירוש לא. זוהי אינה מטרת הפרוטקול, אף על פי שבהמון מקרים, בשגגה, הוא אכן משמש לכך. שימוש ב-OAuth 2.0 לשם אימות יכול להביא להמון בעיות אבטחה, ולכן, מומלץ להשתמש בו למטרה לשמה הוא נועד בלבד.
פגיעוּת להתקפות סייבר – פרוטוקול OAuth 2.0, בגלל אופן פעולתו, פגיע להתקפות סייבר שונות, כמו להתקפות XSS, הזרקות HTML, התקפות CRFS, התקפות אדם בתווך (MITM), ולגניבת או "דליפת" אסימוני הרשאות.
הגורמים תלויים האחד באבטחתו של השני – ניתן, דרך חדירה לאחד הגורמים בתהליך הענקת ההרשאות או באמצעות "זיהום" של אחד מהם, להגיע לגורמים האחרים (ולבסוף למשתמש עצמו).
אין (כרגע) סטנדרט להצפנת אסימוני ההרשאות - פוטנציאלית, בעלי שרתי הרשאות עשויים להשתמש בהצפנות חלשות או ישנות לאסימוני ההרשאות.
הטמעה מורכבת – יש להכיר את הפרוטוקול היטב על מנת להטמיע אותו כהלכה, שכן, הטמעה בלתי מושלמת עשויה ליצור "חורי אבטחה" בתהליך.
פרוטוקול OAuth 2.0 אינו חסין מהתקפות סייבר. תהליך הענקת והאצלת ההרשאות במסגרת הפרוטוקול פגיע בעיקר להתקפות XSS, הזרקות HTML, התקפות CRFS, התקפות אדם בתווך (MITM), ולגניבת או "דליפת" אסימוני הרשאות.
כמובן! לנוחיותכם, ניתן "לדלג" על הגדרת שם משתמש וסיסמה בעת הגישה לשירותינו, ולהיכנס באמצעות שימוש ב-OAuth 2.0. המערכת שלנו לא תיקח פרטי שם משתמש וסיסמה מכם, אלא רק תקבל גישה מהשירותים לפרטים שרלוונטיים להקמת חשבון משתמש.
לאיזור הלקוחות, דרך:
- • חשבון גוגל
למערכת הענן, דרך:
- • חשבון גוגל
- • חשבון פייסבוק
- • חשבון GitHub
השותפים שלנו
