אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
דף הבית של OAuth: בדף הבית של OAuth אפשר לראות סקירה כללית של ההנחיות שאנחנו מספקים בנושא OAuth.
בנושא הזה מופיעה סקירה כללית בסיסית של OAuth 2.0 ב-Apigee Edge.
מה זה OAuth 2.0?
יש הרבה ספרים, בלוגים ואתרים שמוקדשים ל-OAuth 2.0. מומלץ מאוד להתחיל בעיון במפרט של IETF OAuth 2.0. ההגדרה של OAuth 2.0 מתוך המפרט של OAuth 2.0 IETF:
"מסגרת ההרשאות OAuth 2.0 מאפשרת לאפליקציה של צד שלישי לקבל גישה מוגבלת לשירות HTTP, או בשם בעל המשאב על ידי תיאום אינטראקציית אישור בין בעל המשאב לבין שירות ה-HTTP, או על ידי מתן אפשרות לאפליקציה של צד שלישי לקבל גישה בשם עצמה".
הדבר העיקרי שצריך לדעת הוא ש-OAuth 2.0 מספק לאפליקציות דרך לקבל גישה מוגבלת למשאבים מוגנים של משתמש (למשל, חשבון בנק או כל מידע רגיש אחר שהמשתמש עשוי לרצות לגשת אליו מאפליקציה) בלי שהמשתמש יצטרך לחשוף את פרטי הכניסה שלו לאפליקציה.
הרשאה באמצעות OAuth 2.0
זהו התהליך הכללי של מסגרת האבטחה OAuth 2.0. בהמשך הנושא הזה נסביר את התהליך הזה בפירוט רב יותר, ונתחיל בתרשים שממחיש הרבה על האופן שבו OAuth 2.0 פועל. אם אתם לא מכירים את המונחים שמופיעים בתרשים הזה, כדאי לקרוא את הסעיף הזה כדי לקבל הסבר קצר.
מונחים שכדאי להכיר
- לקוח: נקרא גם 'האפליקציה'. יכולה להיות אפליקציה שפועלת במכשיר נייד או אפליקציית אינטרנט רגילה. האפליקציה שולחת בקשות לשרת המשאבים לגבי נכסים מוגנים בשם בעל המשאבים. בעל המשאב צריך לתת לאפליקציה הרשאה לגשת למשאבים המוגנים.
- בעלי המשאב: נקראים גם "משתמשי קצה". בדרך כלל זה האדם (או ישות אחרת) שיכול להעניק גישה למשאב מוגן. לדוגמה, אם אפליקציה צריכה להשתמש בנתונים מאחד האתרים שלכם ברשתות החברתיות, אתם בעלי המשאב – רק אתם יכולים להעניק לאפליקציה גישה לנתונים שלכם.
- שרת משאבים: אפשר לחשוב על שרת המשאבים כשירות כמו פייסבוק, Google או טוויטר, או כשירות משאבי אנוש באינטראנט, או כשירות של שותף באקסטראנט B2B. Apigee Edge הוא שרת משאבים בכל פעם שנדרש אימות של אסימון OAuth כדי לעבד בקשות API. לפני ששרת המשאבים יציג משאבים מוגנים לאפליקציה, הוא צריך לקבל הרשאה כלשהי.
- שרת ההרשאות: שרת ההרשאות מיושם בהתאם למפרט של OAuth 2.0, והוא אחראי לאימות הרשאות הגישה ולהנפקת אסימוני הגישה שמאפשרים לאפליקציה לגשת לנתוני המשתמש בשרת המשאבים. אתם יכולים להגדיר 'נקודות קצה של טוקנים' ב-Apigee Edge, ובמקרה כזה Edge מקבל את התפקיד של שרת הרשאות.
- הרשאת גישה: מאפשרת לאפליקציה לאחזר טוקן גישה בשם משתמש הקצה. פרוטוקול OAuth 2.0 מגדיר ארבעה סוגים ספציפיים של הרשאות. מידע נוסף זמין בקטע מהם סוגי ההרשאות של OAuth 2.0.
- טוקן גישה: מחרוזת ארוכה של תווים שמשמשת כפרטי כניסה לגישה למשאבים מוגנים. בהמשך מוסבר גם על מה זה טוקן גישה.
- משאב מוגן: נתונים שבבעלות בעל המשאב. לדוגמה, רשימת אנשי הקשר של המשתמש, פרטי החשבון או מידע אישי רגיש אחר.
איפה Apigee Edge משתלב
אפשר להגן על כל API שמועבר דרך Apigee Edge באמצעות OAuth 2.0. Edge כולל הטמעה של שרת הרשאות, ולכן יכול ליצור ולאמת אסימוני גישה. השלב הראשון למפתחים הוא רישום האפליקציות שלהם ב-Apigee Edge. אפליקציות רשומות יכולות לבקש טוקנים של גישה באמצעות כל אחת מארבע האינטראקציות של סוג ההרשאה.
Apigee מספק מדיניות OAuthV2 מורכבת שמיישמת את הפרטים של כל סוג הרשאה, ולכן יחסית קל להגדיר OAuth ב-Apigee Edge. לדוגמה, אפשר להגדיר מדיניות שמקבלת בקשה לאסימון גישה, מעריכה את כל האישורים הנדרשים ומחזירה אסימון גישה אם האישורים תקפים.
חשוב לשים לב שכל שרתי המשאבים שה-proxy ל-API המאובטח שלכם קורא להם צריכים להיות מאחורי חומת אש (כלומר, אסור שתהיה גישה למשאבים בשום דרך אחרת מלבד דרך ה-proxy ל-API או API אחר שמאובטח היטב).
מהם סוגי הרשאות ב-OAuth 2.0?
אפשר לחשוב על סוגי הרשאות כעל נתיבים או אינטראקציות שונים שאפליקציה יכולה לבצע כדי לקבל אסימון גישה. כל סוג מענק מתאים לתרחיש שימוש אחד או יותר, ותצטרכו לבחור את סוגי המענקים שמתאימים לצרכים שלכם. באופן כללי, לכל סוג מענק יש יתרונות וחסרונות, ותצטרכו לשקול את הפשרות בהתאם לתרחישי השימוש בעסק שלכם. שיקול חשוב הוא המהימנות של האפליקציות שיקבלו גישה לנתונים שלכם. באופן כללי, אפליקציות של צד שלישי נחשבות לפחות מהימנות מאפליקציות שמפותחות ומשמשות בתוך ארגון.
Apigee Edge תומך בארבעת סוגי ההרשאות העיקריים של OAuth 2.0:
- קוד הרשאה – נחשב לסוג ההרשאה המאובטח ביותר. לפני ששרת ההרשאות מנפיק אסימון גישה, האפליקציה צריכה קודם לקבל קוד הרשאה משרת המשאבים. התהליך הזה מוצג בכל פעם שהאפליקציה פותחת דפדפן כדי להציג את דף הכניסה של שרת המשאבים ומזמינה אתכם להיכנס לחשבון שלכם (לדוגמה, פייסבוק או טוויטר).
אם הכניסה תתבצע בהצלחה, האפליקציה תקבל קוד הרשאה שבאמצעותו היא תוכל לנהל משא ומתן עם שרת ההרשאות כדי לקבל אסימון גישה. בדרך כלל, סוג ההרשאה הזה משמש כשהאפליקציה נמצאת בשרת ולא בלקוח. סוג ההרשאה הזה נחשב למאובטח מאוד כי אפליקציית הלקוח אף פעם לא מטפלת בשם המשתמש או בסיסמה של המשתמש בשרת המשאבים (כלומר, לדוגמה, האפליקציה אף פעם לא רואה או מטפלת בפרטי הכניסה שלכם לטוויטר). תהליך ההרשאה הזה נקרא גם OAuth תלת-רגלי.
- implicit – נחשב לגרסה פשוטה של קוד הרשאה. בדרך כלל משתמשים בסוג ההרשאה הזה כשהאפליקציה נמצאת בלקוח. לדוגמה, הקוד של האפליקציה מוטמע בדפדפן באמצעות JavaScript או שפת סקריפטים אחרת (במקום להיות בשרת אינטרנט נפרד ולהיטמע בו). בתהליך הזה של סוג ההרשאה, שרת ההרשאות מחזיר אסימון גישה ישירות כשהמשתמש מאומת, במקום להנפיק קוד הרשאה קודם. במקרים מסוימים, מתן הרשאות משתמעות יכול לשפר את מהירות התגובה של האפליקציה, אבל צריך לשקול את היתרון הזה מול ההשלכות האפשריות על האבטחה, כפי שמתואר במפרט של IETF.
- פרטי כניסה של בעל המשאב (סיסמה) – בתהליך הזה, הלקוח מקבל אסימון גישה אחרי ששרת ההרשאות מאמת את שם המשתמש והסיסמה של המשתמש. התהליך הזה מומלץ לאפליקציות מהימנות מאוד. יתרון של התהליך הזה על פני אימות בסיסי, למשל, הוא שהמשתמש מזין את שם המשתמש והסיסמה שלו רק פעם אחת. מנקודה זו ואילך, נעשה שימוש בטוקן הגישה.
- פרטי כניסה של לקוח – מומלץ להשתמש בהם במצבים שבהם אפליקציית הלקוח פועלת בשם עצמה. כלומר, הלקוח הוא גם הבעלים של המשאב. בדרך כלל משתמשים בסוג ההרשאה הזה כשהאפליקציה צריכה לגשת לשירות אחסון נתונים בעורף, למשל. האפליקציה צריכה להשתמש בשירות כדי לבצע את העבודה שלה, והשירות לא שקוף למשתמש הקצה. בסוג ההרשאה הזה, אפליקציה יכולה לקבל אסימון גישה על ידי הצגת מזהה הלקוח ומפתחות סוד הלקוח לשרת ההרשאות. לא נדרשים שלבים נוספים. Edge מספק פתרון מוכן לשימוש של פרטי לקוח, שקל להטמיע בכל proxy ל-API.
מה זה טוקן גישה?
אסימון גישה הוא מחרוזת ארוכה של תווים שמשמשת כפרטי כניסה לגישה למשאבים מוגנים. אסימוני משאבים (נקראים גם אסימוני נושא) מועברים בכותרות Authorization, באופן הבא:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
שרת המשאבים מבין שטוקן הגישה מייצג פרטי כניסה כמו שם משתמש וסיסמה. בנוסף, אפשר להנפיק את טוקני הגישה עם הגבלות, כך שהאפליקציה תוכל לקרוא נתונים בשרת המשאבים, אבל לא לכתוב או למחוק אותם. חשוב לדעת שאפשר לבטל את הגישה של טוקן גישה אם, לדוגמה, האפליקציה נפרצה. במקרה כזה, תצטרכו לקבל טוקן גישה חדש כדי להמשיך להשתמש באפליקציה. עם זאת, לא תצטרכו לשנות את שם המשתמש או הסיסמה בשרת המשאבים המוגנים (לדוגמה, פייסבוק או טוויטר).
בדרך כלל יש תוקף לאסימוני גישה (מסיבות אבטחה). חלק מסוגי ההרשאות מאפשרים לשרת ההרשאות להנפיק אסימון רענון, שמאפשר לאפליקציה לאחזר אסימון גישה חדש כשתוקף האסימון הישן פג. פרטים נוספים על אסימוני גישה ורענון זמינים במפרט IETF OAuth 2.0.
גישה מוגבלת באמצעות היקפי הרשאות
באמצעות מנגנון ההיקפים, פרוטוקול OAuth 2.0 יכול להעניק לאפליקציה גישה מוגבלת למשאבים מוגנים. לדוגמה, יכול להיות שלאפליקציה תהיה גישה רק למשאבים ספציפיים, שהיא תוכל לעדכן משאבים או שתהיה לה גישה לקריאה בלבד. בתהליכי OAuth שנקראים "שלושה שלבים", המשתמש בדרך כלל מציין את רמת הגישה דרך דף הסכמה (למשל, דף אינטרנט שבו המשתמש בוחר את ההיקף באמצעות תיבת סימון או מנגנון אחר).
רישום אפליקציה
כל הלקוחות (האפליקציות) צריכים להירשם בשרת ההרשאות של OAuth 2.0, שממנו הם מתכוונים לבקש אסימוני גישה. כשרושמים אפליקציה, מקבלים בחזרה קבוצה של מפתחות. אחד מהם הוא מפתח ציבורי שנקרא מזהה הלקוח, והשני הוא מפתח סודי שנקרא הסוד של הלקוח. ללא המפתחות האלה, אפליקציה לא יכולה להנפיק בקשות לקודי הרשאה או לטוקנים של גישה לשרת ההרשאה. שימו לב: למרות שבמפרט OAuth של IETF המפתחות האלה נקראים מזהה לקוח וסוד לקוח, בממשק המשתמש של Apigee Edge הם נקראים מזהה צרכן וסוד צרכן. הם שווים.
סיכום תרחישי השימוש ב-OAuth 2.0
סוג תהליך ההרשאה של OAuth 2.0 שתבחרו להטמיע תלוי בתרחיש השימוש הספציפי שלכם, כי יש סוגים של הרשאות שהם מאובטחים יותר מאחרים. הבחירה של סוגי ההרשאות תלויה במידת המהימנות של אפליקציית הלקוח, וצריך לשקול אותה בקפידה רבה, כפי שמתואר בטבלה הבאה:
| תרחיש לדוגמה | אמינות | סוגי הרשאות מומלצים ב-OAuth 2.0 | תיאור |
|---|---|---|---|
| B2B (extranet), intranet, other |
אפליקציות שזוכות לאמון רב, שנכתבו על ידי מפתח פנימי או על ידי מפתחים שיש להם קשר עסקי מהימן עם ספק ה-API. אפליקציות שצריכות לגשת למשאבים בשמן. |
|
|
| אתרי אינטראנט, פורטלים |
אפליקציות מהימנות שנכתבו על ידי מפתחים פנימיים או מפתחי צד שלישי מהימנים. דוגמה טובה היא התחברות לאתר משאבי האנוש של החברה כדי לבחור ביטוח, לשלוח ביקורות או לשנות מידע אישי. |
|
|
| אפליקציות שזמינות לכולם | אפליקציות לא מהימנות נכתבות על ידי מפתחים של צד שלישי שאין להם קשר עסקי מהימן עם ספק ה-API. לדוגמה, בדרך כלל לא כדאי לסמוך על מפתחים שנרשמים לתוכניות של API ציבורי. |
|
|
| B2C | יש משתמש קצה פרטי (משתמש בנייד), ופרטי הכניסה של המשתמש מאוחסנים במכשיר הנייד. |
|
|
אבטחה של מפתח API לעומת OAuth 2.0
כדי לאמת מפתח API, האפליקציה צריכה לשלוח מפתח ל-Edge. המפתח צריך להיות טוקן צרכן תקף מאפליקציית מפתחים ב-Apigee Edge שמשויכת ל-proxy ל-API. אם מסיבה כלשהי אתם צריכים לבטל את ההרשאה של אפליקציית לקוח להתקשר לשרת proxy, אתם צריכים לבטל את טוקן הצרכן הזה. גם אפליקציות לקוח שמשתמשות במפתח הזה לא יוכלו לגשת ל-proxy ל-API. לעומת זאת, אפשר לבטל אסימון OAuth בכל שלב בלי לבטל את המפתחות של האפליקציה. האפליקציה יכולה פשוט לבקש טוקן חדש בשם המשתמש, ואם טוקן מאושר, האפליקציה יכולה להמשיך להשתמש ב-proxy ל-API.
הבדל נוסף בין מפתח API לבין אסימון הוא שאסימון יכול לכלול מאפייני מטא-נתונים שאפשר לאחזר ולהשתמש בהם בהמשך. לדוגמה, אפשר לאחסן את המזהה של המשתמש שמבצע את הקריאה ל-API ולהשתמש בו כדי להתאים אישית את הקריאות לשירות היעד של העורף.
פרטים על אימות מפתחות API זמינים במאמר מפתחות API. מידע על שימוש במאפיינים מותאמים אישית עם אסימוני OAuth זמין במאמר התאמה אישית של אסימונים וקודי הרשאה.