הטמעת IDM בפורטל הארגוני שלכם בקלות

פרוטוקול oauth 2.0 – בימינו, כשאתה שומע מישהו מדבר על OAuth, סביר להניח שהם מתכוונים ל- OAuth 2.0. גרסאות קודמות לתקן אינן מיושמות יותר.OAuth היא פרוטוקול הרשאה המאפשרת לך לעבוד עם מערכות חיצוניות בצורה מאובטחת באמצעות מזהים דיגיטליים הנקראים Tokens. סוג אחד של Tokens נקרא Access Token. תפקידו לאפשר לך לממש APIs בצורה מאובטחת. שירות ה- API יכול להשתמש ב- Access Token כדי לקבוע אם אתה רשאי לעשות את מה שאתה מנסה לעשות או לא.

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

הגדרות חשובות להבנת התהליך:

Authorization Flows

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

1. Implicit Flow – מותאם לאפליקציות ״דף בודד״ SPA לא מהימנות (כמו Angular או Vue.js)

2. Code Flow – עבור אפליקציות מהימנות (כמו Spring Boot או .NET)

3. Code Flow with PKCE – עבור אפליקציות Untrusted Native או Mobile Apps.

4. Client Credentials – עבור Server to Server בין שרתים מהימנים ללא משתמש קצה.

5. Resource Owner Password – לא מומלץ – שימש בעבר עבור שירותי אינטרנט מהימנים עם דף כניסה מותאם אישית שמעבירים את סיסמת משתמש הקצה אל שרת ההרשאות.

איזה תרחיש מתאים למערכת שאתם מפתחים? קבלו את עץ החלטה!

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

Authorization Code Flow

תרחיש זה מאפשר לשרת ההרשאות להתמודד עם ארכיטקטורה הכוללת רכיב דפדפן (שאינו מהימן) ורכיב מתווך מהימן כגון יישום Spring Boot או NET.

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

Okta Authentication and MFA

שרת ההרשאות סומך עליו לטפל באישורי ההזדהות של המשתמש בצורה מאובטחת. למערכת OKTA היכולת לא רק לשמור על סיסמת המשתמש בצורה מאובטחת אלא לאמת את התהליך באמצעות הזדהות מוכוונת הקשר Context כגון הרשת שממנה בוצעה ההזדהות, המכשיר שממנו בוצעה, הזמן והתנהגות המשתמש. בנוסף המערכת מכילה פקטור הזדהות נוסף להקשחת התהליך Multi-Factor authentication.

Access Token

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

אפליקציית התווך יכולה כעת בצורה מאובטחת ״ומאחורי הקלעים״, להשתמש בקוד שהתקבל בשילוב עם פרטי התצורה של שרת ההרשאות Client Secret ו- Client ID על מנת לבקש Access Token. על מפתח האפליקציה לוודא שהטוקן הזה לא ייחשף אל משתמשי הקצה ויישמר סודי. הוא מהווה תחליף לגיטימי לפרטי ההזדהות של המשתמש.

התהליך מתחיל בזיהוי המשתמש מדפדפן שאינו מהימן וממשיך בהחלפת טוקן מאחורי הקלעים

JSON Web Tokens

לאחר קבלת Access Token משרת ההרשאות, ינותב הקליינט למסור אותו אל שרת הנתונים. שרת הנתונים נדרש לאמת את הטוקן לפני השימוש בו.

הטוקנים הם בפורמט JSON Web Token או בקיצור JWT וחתומים על ידי מפתחות אסימטרים JSON Web Keys או בקיצור JWK אותם ניתן לקבל משרת ההרשאות ולשמור בשרת הנתונים. על מנת לפענח אותם ולאמת את מקורם ניתן להשוות את המפתח ששימש להצפנת הטוקן עם המפתח שנשמר בשרת ההרשאות מקומית או לחזור בקריאת API, אל שרת ההרשאות על מנת לאמת את הטוקן (פחות מומלץ בתרחישים הדורשים ביצועים גבוהים).

מקורות:

1. https://developer.okta.com/docs/guides/implement-auth-code/-/use-flow/
2. https://developer.okta.com/docs/concepts/auth-overview/#what-kind-of-client-are-you-building
3. https://developer.okta.com/blog/2018/12/13/oauth-2-for-native-and-mobile-apps