זהויות, תקנים ופרוטוקולים OIDC

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

כאשר מתכננים ומפתחים אפליקציות, אתרי WEB ושירותי ענן שונים כדוגמת Managed Services וכן הלאה, אבטחת מידע אינה בראש סדר העדיפויות וקודם כל ממהרים להרים את האפליקציה בכדי שתהיה פעילה ורק לאחר מכן יגיעו נדבכים נוספים ורק בסוף תהיה התייחסות מתאימה לאבטחת מידע.

הסיבות לריבוי הפגיעויות הן רבות ובין היתר ניתן למנות את הבעיות הבאות:

Time to Market – שימוש במתודולוגיות פיתוח שונות, גורם לכך שבממוצע TTM לאפליקציות מובייל מקוריות הוא בין 15-20 שבועות, נתון אשר תלוי גם במורכבות וגורמים אחרים של היישום. פיתוח מהיר שכזה מקשה על שילוב אלמנטים של אבטחת מידע.

Code Reuse – מפתחי אפליקציות במובייל נוטים להשתמש באותם מנגנונים וקטעי קוד המכונים Reuse לקוד עצמו, דבר שאוטומטית מממש את קיומה של בעיית אבטחת המידע במגוון רחב של מוצרים דבר הגורר פגיעות רוחביות.

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

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

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

אם לקחת מספר מקרי קצה בודדים שנתקלתי בהם לאחרונה אפשר לומר שעדיין הזדהות מבוססת Basic היא "סבבה לגמרי", למשל חיבור אפליקציה מסוימת לשירות Exchange Online – הכוונה הראשונית היתה בוא נתחבר עם פרוטוקול IMAP איפה הבעיה? אנחנו בשנת 2020 עוד רגע ולכן Legacy Authentication אינו רלוונטי כלל!

המצב כיום ומעבר אל OIDC

המצב כיום עדיין כולל פרוטוקולים ותצורות אימות ישנות אשר קיימים בפיתוח, בין היתר נעבור על חלקם בקצרה:

הזדהות מבוססת Basic Authentication

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

במצב כזה נוכל לראות את הבקשה לפי פרמטרים: Authorization: Basic, "Some Secret Key"

הפרמטר הראשון מבטא סוג Authentication ובמקרה הזה – BA
הפרמטר השני הוא credentials ובמקרה הזה, מפתח הזיהוי מקודד באמצעות Base64 על מנת להעביר את המידע על פרוטוקול HTTP בצורה תקינה, הפרוטוקול מצפה לטקסט, ותווים מסוימים יכולים להתפרש אחרת לחלוטין.

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

Client to Server – בתהליך אשר נעשה בין לקוח ושרת או יותר נכון בין דפדפן לשרת, התהליך עובד באופן שונה מאשר שרת לשרת, בגלל אופן הפעולה:

• המשתמש (הדפדפן) יוזם את הגישה הראשונה לשרת
• הבקשה יכולה להיות שונה בין הפעולות
• לא נשלח מפתח זיהוי
• ברוב המקרים השרת יחזיר הודעה 401 שאינו יודע מיהו המשתמש או הבקשה וכאן נשלח Header לגבי צורת הזדהות
• במצב כזה יקפוץ שם משתמש וסיסמה – המשתמש יקליד פרטי הזדהות
• במקרים מסוימים הבקשה תעבור המרה של פרטי הזדהות ויקודד על גבי BASE64
• השרת ימיר את הקידוד ויזהה האם המשתמש אכן קיים
• פרטי הזדהות יישארו בדפדפן לפרק זמן מסוים
• בכל בקשה חדשה ישלח שוב אותו Header עם הסיסמה

גם כאן ישנה בעית אבטחה גדולה והיא שניתן ליירט את התעבורה בין המשתמש לשרת, ישנם מצבים בהם פרטי הזדהות יכולים לעבור אפילו על גבי Clear-Text, או שניתן להסניף בכל רגע את התקשורת מתוך הדפדפן אל השרת, וגרוע מכך תוקף יכול שניתן לבצע התקפת CSRF.

Client to Server מובייל – במצבים בהם ישנם מכשירים חכמים הבעיה גדולה עוד יותר שכן ניתן לבצע הסנפה על כל חלק בתקשורת בין המובייל לשרת המבוססות על התקפת איש-אמצע (MITM), בין אם מבצעים הדמיה של שרת וכך המובילל חושב שהוא ניגש לשרת או לחלופין להדמות רשת אחרת למובייל וכך להסניף את כל המידע שעובר.

הזדהות מבוססת פרוטוקול OAuth

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

מידע נוסף על פרוטוקול OAuth 2.0 בקישור הבא RFC 6749.

תצורת העבודה של OAuth נעשה לפי מאפיינים שונים ותהליך (flow) מוגדר מראש לפי הדגשים הבאים שבהם הוא עובד עם טוקן, מבצע אישור (Grant) ומשתמש בטוקן לאורך הדרך.

המאפיינים העיקריים בתהליך הזדהות של OAuth הם:

Resource Owner – מבטא את מבקש הגישה או המשתמש

Resource Server – או לחלופין Protected Resource ולמעשה השירות אשר מאחסן את הנתונים של מבקש הגישה או המשתמש

Authentication Server – השירות שאליו מבקש הגישה או המשתמש מבצע הזדהות ובשירות הזה נעשה תהליך AUthnetication ומונפק טוקן אשר מאמת את  זהות המשתמש

Client – השירות הראשוני שאליו פונה מבקש הגישה או המשתמש, ושירות זה הינו לקוח של Reource Server ולמעשה שם מבוצעת גישה למשאבים השייכים למבקש הגישה או המשתמש

Authorization Code Grant – תפקידו של Authorization Code grant הוא לבצע החלפה של הטוקן עצמו, ולאחר שהמשתמש קיבל בחזרה את הקישור הוא יכול לבצע העברה של האפליקציה בכדי שיוכל לקבל את הערך של Authorization Code ובכדי שיוכל להשתמש שוב בטוקן.

נצלול מעט. המשתמש נרשם אצל Resource Server (למשל Facebook) ובמהלך הרישום הוא מקבל מפתח זיהוי (Client Secret) ואת המפתח הוא שומר באופן מאובטח.

כעת המשתמש רוצה להתחבר לשירות אחר (למשל Spotify)

• שירות Spotify מבקש מהמשתמש להזדהות, ומאפשר לו לעשות את זה בעזרת שירות Facebook.
• המשתמש בוחר בשירות Facebook, ומופנה ל Authentication Server המתאים
  • שירות Spotify סומך על הגורם של Authentication Server ומבצע אימות מאובטח שלאחריו מנפיק טוקן
  • ברוב המקרים מוצג למשתמש מהי רת ההרשאה הנדרשת ומהם הנתונים שהוא הולך למסור, או לחלופין יכול להחילט שאינו מסכים להרשאה הנדרשת. במצב כזה כל הרשאה והגדרת נתונים מוגדרת על בסיס Scope
  • המשתמש מזדהה בעזרת שם משתמש וסיסמה ואם ישנו MFA אז יהיה חלק מאותו אימות ושם הוא למעשה מאשר את Scope
• מכאן הבקשה מבצעת Redirect חזרה למשתמש עם הבקשה המקורית להזדהות שעמם עובד המשתמש וכל זאת לוודא שאכן זאת התשובה לבקשה המקורית וכאן מתבצע Authorization
• לאחר מכן המשתמש פונה אל השירות שאליו הוא מבצע Authentication ושולח אליו Authorization Code, שם מתבצעים סט בדיקות של Client ID, Client Secret.
• בסיום מתקבל אובייקט ונתונים אודות JSON עם תאריכי תפוגה, ערכי Token Refresh ולאן הוא יכול לגשת
• בשלב החארון ולאחר אישור הנתונים נעשית גישה אל המידע הרלוונטי

העקרון מאחורי המנגנון של טוקן נקרא של Trust On First Use, שמטרתו לצמצם את החשיפה לתקשורת הראשונה, ולכן אנו סומכים בפעולה הראשונה על הצד השני, וכם אנו פחות חשופים להסנפות החל מהתקשרות הראשונית.

גם במקרים בהם Access Token נחשף הפגישה תהיה מוגבלת לזמן מסוים כי הפרמטרים של Refresh Token ושל Client Secret אינם נחשפים.

בנוסף לתצורת Authorization Code Grant ישנם עוד מספר סוגים של אישור אפליקציות למינהם הן ברמת המובייל והן ברמת אתרי WEB:

Implicit Grant – מאפשר דלגציה בין מערכות ושירותי רשת שונים, במצב כזה הפרמטרים של Refresh Token אינם באים לידי ביטוי ולכן מתבצע Access Token מחדש בכל פעם, ובנוסף לכך לא מועבר Authentication Code ושוב ישר שולחים Access Token.

במצבים כאלה פשוט יותר לבצע Rever Engineering על אפליקציות ופשוט יותר לבצע זיוף של אפליקציות קופי WEB, בנוסף לכך הזדהות באמצעות MFA אינה מגנה על חשיפה של פרטי המשתמש והרשאות שניתנו.

Client Credentials – הוגדר עבור חלקים שונים של האפליקציה שבהם נותן אמון ואינו דורשת את התערבות המשתמש בגלל שמתבצע אימות בין מערכות.

פרוטוקול OAuth מביא איתו בעיות אבטחה בגלל שרוב האפליקציות כיום מתבססות עליו ועל ההגדרה הספצפית של Implicit כלומר המון אמון ומעט אבטחה, והפעול היוצא שלה הוא שניתן בקלות לזייף דפי WEB או אפליקציות מובייל ולבצע Reverse Engineering ומכאן לטייל במרחב הארגוני.

אפשר לומר שבמקרים מסוימים עשו מעבר מהיר אל Authorization Code Grant, כאשר משתמשים בהרשאות עם Native Browser ולא WebView. למשל: SFSafariViewController ולא WKWebView.

הזדהות מבוססת פרוטוקול OpenID Connect

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

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

דגשים בפרוטוקול OIDC:

• מחייב כללים רבים שהם בגדר המלצה בפרוטוקול OAuth 2.0
• מגדיר את מבנה הטוקן על בסיס JWT
• מאפשר Scopes שונים בהם כדוגמת מובייל או מייל – המאפשרים התנהגות סטנדרטית מסביב למידע בסיסי של המשתמש
• עובד עם ערכים נוספים למשל userInfo Endpoint ממנו ניתן לשאוב מידע בסיסי על המשתמש
• התפתח בתקופה בה אפליקציות מובייל הן מאוד משמעותיות, ויש התייחסות רחבה יותר למובייל בהגדרת הפרוטוקול
• החל מ 2015 יש הסמכה של OIDC, ויש רשימה של מימושים שהם Certified
• מגדיר סוג נוסף של טוקן הנקרא ID Token המאפשר לערך Client לדעת כמה פרטים על המשתמש ועל מצב פרמטרים כגון Authentication
• חשוב מכך מוסיף הגנה מפני התקפת Replay

בתהליך בסיסי של OIDC ניתן לראות כי התהליך אינו בהכרח מתבסס על הדפדפן, והמטרה שלו היא להשיג מידע על המשתמש ולא משאב כללי.

דגשים בפרוטוקול OpenID Connect

• פרוטוקול OIDC הווא פרוטוקול מאובטח יותר מאשר OAuth
• פרוטוקול OpenID מסומן היום כמחליף הטבעי של SAML 2.0 המסורבל וכזה שסובל מתיעוד לקוי
• כיום הינו חלק מתוכנית Certified ובשנים האחרונות לא היה אירוע חריג על גבי הפרוטוקול
• באפליקציות Native פרוטוקול ה OIDC עדיין לא נחשב למספיק טוב  בהתבסס על תקנים מרכזיים: Proof Of Possession + PKCE
• במידה ועדיין ישנו צורך בגישה למשאב ניתן להשיג זאת בפרוטוקול OIDC

קצת מהשטח

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

אם לקחת את מה שקורה עם OKTA, OneLogin וכמובן Mcirosoft ניתן להבחין באימוץ אשר עושים בימים אלה על גבי פרוטוקול OIDC. כבר כיום תצורת ההזדהות של משאבים רבים בענן של Microsoft זוכים למימושים של OIDC בין אם מדובר על תצורה של B2B או B2C.

אם אתה בונים, מתכננים או מאשרים אפליקציה עשו זאת עם OIDC בגלל השפטות ביישום וחשוב מכך המענה לבעיות אבטחה אשר קיימות בפרוטוקולים הישנים, וכאן Mcirosoft נכנסת חזק לתמונה עם Microsoft identity platform v2.0 ומספקים מטריקס לפתרונות מסוימים, תהליכי פעולה ובניית תרחישי הזדהות לדפי WEB, אפליקציות מובייל וכן הלאה.

מידע נוסף וקישורים

• יצירת תהליך הזדהות Single-page application
• מידע נוסף לגבי OIDC בקישור OpenID Connect