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

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

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

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

OAuth Term	Definition
Authorization Server	השרת האמון על ההרשאות והקצאת ה- Tokens
Client Application	האפליקציה אשר מבקשת בשם המשתמש גישה לנתונים
Resource Owner	המשתמש אשר מבקש הרשאת גישה לנתונים באמצעות האפליקציה
Resource Server	השרת אשר חושף נתונים באמצעות API ומסוגל לאמת Access Token שמגיעים משרת ההרשאות

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

מקורות:

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