מהו OAuth 2.0 וכיצד הוא משפר את אבטחת הגישה באינטרנט?

מהו OAuth 2.0 וכיצד הוא משפר את אבטחת הגישה באינטרנט?

פורסם ב 26-10-2024

מה זה?

OAuth 2.0 – או בשמו המלא Open Authorization (גירסה 2.0) – כשמו, הוא פרוטוקול בתקן פתוח (כלומר, תקן אשר ניתן להטמיע ולעדכן באופן חופשי וחינמי) להענקת הרשאות גישה לשירותים ולשרתים שונים (בדרך כלל יישומים, אפליקציות או מכשירים) באינטגרציה עם שירותים או שרתים אחרים.

ל-OAuth 2.0 יש יתרון ברור על פני הענקת הרשאות "מסורתית" – בעוד האחרונה מצריכה הזנת שם משתמש וסיסמה, שיכולים להתגלות בדרכים שונות (למשל, באמצעות פישינג, חדירה לרשת הווייפיי שלכם, סוס טרויאני חמקמק ועוד לא מעט מרעין בישין), OAuth 2 מאפשר לבצע שיתוף הרשאות באמצעות שימוש באסימונים (Tokens) המוצפנים בזמן המעבר שלהם מנקודה אחת לשניה (Encryption of Data in Transit). כל אסימון הוא למעשה תעודת הרשאה, באמצעותה היישומים והשירותים השונים מוכיחים כי קיבלו הרשאות רלוונטיות להשתמש במשאבים מסויימים.
כך, נמנע הצורך בשיתוף פרטי לוגין, ומתן ההרשאות בין השירותים מתבצע בצורה יותר בטוחה למשתמש, לפחות פוטנציאלית.

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

דוגמה נוספת, עליה כתבנו לא מזמן, היא המעבר של גוגל לשימוש ב"אפליקציות מאובטחות" עם Gmail. ה"אפליקציות המאובטחות" ( גוגל מגדירה אפליקציות מאובטחות כאפליקציות שמשתמשות ב-OAuth 2.0) יקבלו אסימונים מוצפנים מ-Gmail כהרשאות להשתמש בה ולהסתנכרן איתה. החלפת האסימונים תתבצע באמצעות "Sign-in With Google" – כלומר, האפליקציה תבקש אישור מגוגל להשתמש בחלקים מסויימים מהפלטפורמה שלה, וגוגל תעניק לה הרשאות בצורת אסימונים מוצפנים לעשות זאת. שוב, כל זה מבלי לחשוף את שם המשתמש והסיסמה בגוגל לאפליקציות.

תפקידים (Roles)

OAuth 2.0 מגדיר ארבעה גורמים שצריכים לתקשר ביניהם בכדי ש"עסקת" OAuth 2.0 (כלומר, הענקת האסימונים לשם הרשאות) תתבצע. גורמים אלו מכונים "תפקידים".

הגורם הראשון הוא "בעל המשאבים" (Resource Owner) – ה"ישות" שמעניקה גישה למשאבים המוגנים (המצריכים הרשאות – אסימונים – כדי לגשת אליהם). במרבית המקרים, מדובר במשתמש-הקצה – כלומר, אנחנו.

הגורם השני הוא "שרת המשאבים" (Resource server) – או, השרת המאכלס את אותם משאבים מוגנים. בהשאלה מהדוגמה הראשונה שהבאנו שש פסקאות אחורה, אם אנחנו הגורם הראשון, הגורם השני יכול להיות פייסבוק.

גורם מספר שלוש הוא ה"לקוח" (Client) – האפליקציה או השירות שמבקשים, בשם בעל המשאבים, את הרשאות הגישה למשאבים המוגנים. החלפת האסימונים למעשה מתבצעת בין הלקוח לבין שרת המשאבים.
ישנם שני סוגי לקוח:
- חסוי (Confidential): לקוח שמסוגל לשמור על אבטחתם של אישורי הגישה שלו (לדוגמה, באמצעות אחסונם על שרת מאובטח בעל גישה מוגבלת), או בעל אמצעים אחרים לאבטחת אישורי האימות שלו.
- ציבורי (Public): לקוח ללא יכולת לשמור על אבטחתם של אישורי הגישה שלו, וללא יכולת להגן על אישורי האימות שלו. לדוגמה, אפליקציה מבוססת דפדפן נחשבת ללקוח ציבורי.

והגורם הרביעי, שרת ההרשאות (Authorization Server) – הוא השרת שמאמת כי בעל המשאבים (המשתמש) והלקוח הם מי שהם טוענים שהם, ומעניק את אסימוני ההרשאות ללקוח.
שרת ההרשאות מזהה את סוג הלקוח לפי הגדרתו מהו אימות מאובטח, ולפי רמת חשיפת אישורי הגישה של הלקוח.

שלבי הפעולה

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

2. כאשר בעל המשאבים מזין את אישורי הגישה שלו (לנו זה בעיקר מוכר כהזנת שם המשתמש והסיסמה שלנו אצל שרת המשאבים ממנו הלקוח רוצה לבקש גישה), הלקוח מקבל את האישור אותו הוא היה צריך – את מענק ההרשאה.

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 הוא מטבע בעל שני צדדים.
מצד אחד, הוא מציע כמה נדבכים של אבטחה ופרטיות. הוא מסייע לשמור על פרטיותם של משתמשים ושל מערכות, באמצעות הענקת גישה סלקטיבית ובדרך שדואגת שפרטי המשתמש יישארו חסויים. הוא גמיש וניתן לאדפטציה על מערכות ומצבים שונים, ובזכותו, חיבור מאובטח נעשה פשוט ויעיל יותר עבור המשתמשים.

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