רשומת החלטה ארכיטקטונית: אפשרויות אימות והרשאה

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

אימות הוא התהליך של אימות זהותם של משתמש או מערכת.
הרשאה היא התהליך של קביעה לאילו משאבים או פעולות המשתמש או המערכת המאומתים יכולים לגשת.

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

1. OAuth (Open Authorization)

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

זרימה: OAuth פועל בדרך כלל בזרימה מבוססת אסימונים, שבה שרת הרשאות מנפיק אסימון גישה ליישום הצד השלישי. האסימון הזה מייצג את הרשאות המשתמש, והיישום משתמש בו כדי לגשת לנתוני המשתמש או למשאביו מתוך API.
דוגמה: משתמש מתחבר ליישום של צד שלישי באמצעות חשבון Google שלו. Google מאמתת את זהות המשתמש ואז מעניקה אסימון שמאפשר ליישום הצד השלישי לגשת לנתונים מסוימים של Google (למשל Google Calendar).

OAuth אינו מטפל באימות ישירות; הוא עוסק בהענקת גישה. לצורך אימות, OAuth מצורף לעיתים קרובות לפרוטוקולים אחרים, כמו OpenID Connect.

2. OpenID Connect (OIDC)

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

זרימה: כשמשתמש מתחבר באמצעות OpenID Connect, יישום הצד השלישי מבקש אסימון זהות (ID token) בנוסף לאסימון הגישה של OAuth. אסימון הזהות מכיל מידע על המשתמש (כמו שם המשתמש, הדוא"ל וטענות נוספות). כך היישום יכול לדעת מי המשתמש והאם הוא מאומת.
דוגמה: התחברות לשירות כמו Slack באמצעות חשבון Google שלכם (כש-Google היא ספקית OpenID Connect) כרוכה באימות באמצעות OpenID Connect, בעוד ש-OAuth מנהל את הגישה למשאבי Google שלכם.

OIDC מקל על יישומי צד שלישי לאמת משתמשים ועדיין מאפשר שליטה מדויקת במשאבים שהיישומים האלה יכולים לגשת אליהם.

3. SAML (Security Assertion Markup Language)

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

זרימה: המשתמש מזדהה תחילה מול ספק זהות (IdP). ה-IdP מפיק טענת SAML חתומה שכוללת את זהות המשתמש ומאפיינים קשורים. הטענה נשלחת לספק השירות (SP), שמשתמש בה כדי לאשר גישה ליישום.
דוגמה: עובד מתחבר לפורטל הארגוני שלו (ה-IdP) ומחובר אוטומטית למערכות אחרות כמו דוא"ל, CRM וכדומה, בלי להזין שוב פרטי זיהוי. תהליך האימות מבוסס על טענת ה-SAML שנשלחה מה-IdP.

SAML נפוץ בפתרונות SSO ארגוניים ופועל היטב ליישומי ווב בסביבות ארגוניות, אבל הוא פחות ידידותי למכשירים ניידים בהשוואה ל-OAuth/OIDC.

4. WS-Federation (Web Services Federation)

WS-Federation הוא פרוטוקול נוסף המשמש לכניסה יחידה (SSO), במיוחד בסביבות ארגוניות מבוססות Microsoft. הוא חלק ממשפחת המפרטים WS- (Web Services)* ומאפשר פדרציית זהויות בין תחומי אבטחה שונים (למשל בין ארגונים שונים או בין שירותים שונים).

זרימה: WS-Federation מאפשר לספק זהות מהימן (IdP) לאמת משתמשים ולהנפיק אסימונים שספק השירות יכול להשתמש בהם להרשאה. הוא דומה ל-SAML אבל משמש לעיתים קרובות בתרחישים שנשענים בכבדות על טכנולוגיות Microsoft.
דוגמה: משתמש מתחבר ליישום ארגוני המתארח ב-Microsoft Azure Active Directory (AD), ואת זהותו אפשר להשתמש כדי לגשת לשירותים מאוחדים אחרים, כולל יישומים המתארחים אצל ספקי צד שלישי.

אף ש-WS-Federation הוחלף ברובו בפרוטוקולים חדשים יותר כמו OAuth2.0 ו-OpenID Connect בסביבות ווב מודרניות רבות, הוא עדיין בשימוש במערכות מורשת, במיוחד בארגונים שממוקדים ב-Microsoft.

5. LDAP (Lightweight Directory Access Protocol)

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

אימות: LDAP מאפשר ליישום לאמת משתמשים על ידי שאילתה לשירות הספרייה לגבי פרטי זיהוי (כמו סיסמאות).
הרשאה: הוא גם מנהל תפקידים והרשאות של משתמשים, ועוזר לקבוע אם למשתמש יש גישה למשאבים מסוימים.
דוגמה: ארגונים רבים משתמשים בספריות מבוססות LDAP (למשל Active Directory) לאימות ולהרשאה, במיוחד בסביבות Windows.

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

6. ספקי SSO חברתיים

ספקי כניסה יחידה (SSO) חברתיים כמו Facebook, Google, Twitter, GitHub ואחרים מאפשרים למשתמשים להזדהות ביישומי צד שלישי באמצעות פרטי הזיהוי שלהם ברשתות החברתיות. זהו סוג של אימות מבוסס OAuth, שבו שירות הצד השלישי (למשל Google) הוא ספק הזהות.

זרימה: המשתמש לוחץ על "התחבר עם Google" (לדוגמה). היישום מפנה ל-Google, שם המשתמש מתחבר (אם עדיין לא מחובר). Google מספקת אז אסימון גישה או אסימון זהות ליישום הצד השלישי, שאפשר להשתמש בו כדי לאמת את המשתמש ואולי לגשת לנתוניו.
דוגמה: יישומים רבים מאפשרים להתחבר באמצעות פרטי הזיהוי של Google או Facebook. היישום ישתמש ב-OAuth או ב-OpenID Connect מאחורי הקלעים כדי לאמת את זהותכם ובמקרים מסוימים לגשת לנתונים מסוימים ברשתות החברתיות.

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

סיכום ההבדלים:

OAuth: משמש להרשאה, מאפשר ליישומי צד שלישי לגשת לנתוני משתמש בלי לחשוף פרטי זיהוי.
OpenID Connect: מרחיב את OAuth כדי לספק אימות, ומאפשר ליישומים לאמת את זהות המשתמש.
SAML: פרוטוקול מבוסס XML המשמש ל-SSO, לעיתים קרובות בסביבות ארגוניות.
WS-Federation: פרוטוקול ייחודי ל-Microsoft לפדרציית זהויות, המשמש במערכות מורשת.
LDAP: פרוטוקול לשאילתות בשירותי ספרייה לצורך אימות משתמשים וניהול הרשאות.
ספקי SSO חברתיים: מערכות מבוססות OAuth (כמו Google, Facebook) שמאפשרות ליישומי צד שלישי לאמת משתמשים באמצעות פרטי הזיהוי שלהם ברשתות החברתיות.

לכל אחת מהטכנולוגיות האלה יש חוזקות ומקרי שימוש משלה, וביישומים מודרניים אפשר לראות שילוב שלהן המשמש להיבטים שונים של אבטחה (למשל OAuth/OIDC לגישת API, SAML ל-SSO ארגוני).