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