הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge.
דף הבית של OAuth: בדף הבית של OAuth אפשר לראות סקירה כללית של ההנחיות שאנחנו מספקים בנושא OAuth.
הנושא הזה מספק סקירה כללית בסיסית על OAuth 2.0 ב-Apigee.
מה זה 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 הוא שרת משאבים בכל פעם שנדרש אימות של אסימון OAuth כדי לעבד בקשות API. שרת המשאבים צריך סוג כלשהו של הרשאה לפני שהוא יציג משאבים מוגנים לאפליקציה.
- שרת הרשאות: שרת ההרשאות מוטמע בהתאם למפרט של OAuth 2.0, והוא אחראי לאימות של הענקת ההרשאות ולהנפקת טוקני הגישה שמאפשרים לאפליקציה לגשת לנתוני המשתמש בשרת המשאבים. אפשר להגדיר נקודות קצה (endpoints) של אסימונים ב-Apigee, ובמקרה כזה Apigee מקבלת את התפקיד של שרת הרשאות.
- מתן הרשאה: נותן לאפליקציה הרשאה לאחזר אסימון גישה בשם משתמש הקצה. ב-OAuth 2.0 מוגדרים ארבעה "סוגי grant" ספציפיים. למידע נוסף, קראו את המאמר מהם סוגי ה-grant של OAuth 2.0.
- טוקן גישה: מחרוזת ארוכה של תווים שמשמשת כפרטי כניסה לגישה למשאבים מוגנים. מהו אסימון גישה?
- משאב מוגן: נתונים שבבעלות בעל המשאב. לדוגמה, רשימת אנשי הקשר של המשתמש, פרטי החשבון או מידע רגיש אחר.
איפה Apigee משתלבת
אתם יכולים להגן על כל proxy ל-API שמועבר דרך Apigee עם OAuth 2.0. Apigee כולל הטמעה של שרת הרשאות, ולכן יכול ליצור ולאמת טוקני גישה. המפתחים מתחילים ברישום האפליקציות שלהם ב-Apigee. אפליקציות רשומות יכולות לבקש טוקני גישה באמצעות כל אחת מארבע האינטראקציות של סוג grant.
ב-Apigee יש מדיניות OAuthV2 מרובת היבטים שמיישמת את הפרטים של כל סוג grant, כך שקל יחסית להגדיר OAuth ב-Apigee. לדוגמה, אפשר להגדיר מדיניות שמקבלת בקשה לטוקן גישה, בודקת את כל פרטי הכניסה הנדרשים ומחזירה טוקן גישה אם פרטי הכניסה תקינים.
חשוב לשים לב שכל שרתי המשאבים שה-proxy המאובטח ל-API קורא להם צריכים להיות מאחורי חומת אש (כלומר, אסור שתהיה גישה למשאבים באמצעים אחרים מלבד ה-proxy ל-API או API אחר שמאובטח היטב).
מהם סוגי ה-grant של OAuth 2.0?
אפשר לחשוב על סוגי grant כנתיבים או אינטראקציות שונים שאפליקציה יכולה לבצע כדי לקבל אסימון גישה. כל סוג grant מתאים לתרחיש אחד או יותר, ואתם צריכים לבחור באילו סוגי grant להשתמש בהתאם לצרכים שלכם. באופן כללי, לכל סוג grant יש יתרונות וחסרונות, וצריך לשקול את היתרונות והחסרונות בהתאם לתרחישי השימוש העסקיים. שיקול חשוב אחד הוא האמינות של האפליקציות שיקבלו גישה לנתונים שלכם. באופן כללי, אפליקציות של צד שלישי פחות מהימנות מאפליקציות שמפתחים ומשתמשים בהן בתוך הארגון.
Apigee תומך בארבעת הסוגים העיקריים של מענקי OAuth 2.0:
- קוד הרשאה – נחשב לסוג ה-grant המאובטח ביותר. לפני ששרת ההרשאות מנפיק טוקן גישה, האפליקציה צריכה לקבל קוד הרשאה משרת המשאבים. התהליך הזה מתרחש בכל פעם שהאפליקציה פותחת דפדפן לדף ההתחברות של שרת המשאבים ומזמינה אתכם להתחבר לחשבון שלכם (לדוגמה, פייסבוק או טוויטר).
אם ההתחברות תצליח, האפליקציה תקבל קוד הרשאה שבאמצעותו היא תוכל לנהל משא ומתן על טוקן גישה עם שרת ההרשאות. בדרך כלל משתמשים בסוג ה-grant הזה כשהאפליקציה נמצאת בשרת ולא בלקוח. סוג ה-grant הזה נחשב למאובטח מאוד כי אפליקציית הלקוח אף פעם לא מטפלת בשם המשתמש או בסיסמה של המשתמש בשרת המשאבים, או רואה אותם (לדוגמה, האפליקציה אף פעם לא רואה את פרטי הכניסה שלכם ל-Twitter או מטפלת בהם). תהליך הענקת ההרשאות הזה נקרא גם OAuth תלת-רגלי.
- implicit – נחשב לגרסה פשוטה יותר של קוד הרשאה. בדרך כלל משתמשים בסוג ה-grant הזה כשהאפליקציה נמצאת אצל הלקוח. לדוגמה, הקוד של האפליקציה מוטמע בדפדפן באמצעות JavaScript או שפת סקריפטים אחרת (במקום להיות מאוחסן ומופעל בשרת אינטרנט נפרד). בתהליך מסוג grant זה, שרת ההרשאה מחזיר טוקן גישה ישירות כשהמשתמש מאומת, במקום להנפיק קוד הרשאה קודם. במקרים מסוימים, הרשאות משתמעות יכולות לשפר את מהירות התגובה של האפליקציה, אבל צריך לשקול את היתרון הזה מול ההשלכות האפשריות על האבטחה, כפי שמתואר במפרט של IETF.
- פרטי כניסה באמצעות סיסמה של בעלי המשאב – בתהליך הזה, הלקוח מקבל אסימון גישה כששם המשתמש והסיסמה של המשתמש מאומתים על ידי שרת ההרשאות. התהליך הזה מומלץ לאפליקציות מהימנות מאוד. היתרון של התהליך הזה על פני אימות בסיסי, למשל, הוא שהמשתמש מציג את שם המשתמש והסיסמה שלו רק פעם אחת. מאותו רגע, משתמשים בטוקן הגישה.
- פרטי כניסה של לקוח – כדאי להשתמש בהם במצבים שבהם אפליקציית הלקוח פועלת בשם עצמה. כלומר, הלקוח הוא גם הבעלים של המשאב. בדרך כלל משתמשים בסוג ה-grant הזה כשהאפליקציה צריכה לגשת לשירות אחסון מאגר נתונים בקצה העורפי, למשל. האפליקציה צריכה להשתמש בשירות כדי לבצע את הפעולה שלה, והשירות לא גלוי למשתמש הקצה. עם סוג ה-grant הזה, אפליקציה יכולה לקבל טוקן גישה על ידי הצגת מזהה הלקוח ומפתחות סוד הלקוח לשרת ההרשאות. לא נדרשים שלבים נוספים. מספק פתרון מוכן לשימוש של פרטי כניסה של לקוח, שקל להטמיע בכל proxy ל-API.
מה זה טוקן גישה?
טוקן גישה הוא מחרוזת ארוכה של תווים שמשמשת כפרטי כניסה כדי לגשת למשאבים מוגנים. אסימוני משאבים (שנקראים גם טוקנים למוכ"ז) מועברים בכותרות Authorization, באופן הבא:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
שרת המשאבים מבין שטוקן הגישה מחליף את פרטי הכניסה, כמו שם המשתמש והסיסמה. בנוסף, אפשר להנפיק את טוקני הגישה עם הגבלות, כך שהאפליקציה תוכל לקרוא נתונים בשרת המשאבים, אבל לא לכתוב או למחוק אותם. חשוב לדעת שאפשר לבטל טוקן גישה, למשל אם האפליקציה נפרצה. במקרה כזה, תצטרכו לקבל טוקן גישה חדש כדי להמשיך להשתמש באפליקציה, אבל לא תצטרכו לשנות את שם המשתמש או הסיסמה בשרת המשאבים המוגנים (לדוגמה, פייסבוק או טוויטר).
בדרך כלל, לטוקני גישה יש תאריך תפוגה (מטעמי אבטחה). סוגי grant מסוימים מאפשרים לשרת ההרשאות להנפיק טוקן רענון, שמאפשר לאפליקציה לאחזר טוקן גישה חדש כשהתוקף של הטוקן הישן פג. למידע נוסף על אסימוני גישה ורענון, קראו את מפרט IETF OAuth 2.0.
גישה מוגבלת באמצעות היקפי הרשאות
באמצעות מנגנון ההיקפים, OAuth 2.0 יכול להעניק לאפליקציה גישה מוגבלת למשאבים מוגנים. לדוגמה, יכול להיות שלאפליקציה תהיה גישה רק למשאבים ספציפיים, שהיא תוכל לעדכן משאבים או שתהיה לה רק הרשאת קריאה בלבד. בתהליכי OAuth תלת-רגליים, המשתמש בדרך כלל מציין את רמת הגישה דרך דף הסכמה (לדוגמה, דף אינטרנט שבו המשתמש בוחר את ההיקף באמצעות תיבת סימון או מנגנון אחר).
רישום אפליקציה
כל הלקוחות (האפליקציות) חייבים להירשם בשרת ההרשאות של OAuth 2.0, שממנו הם מתכוונים לבקש טוקני גישה. כשרושמים אפליקציה, מקבלים קבוצה של מפתחות. אחד הוא מפתח ציבורי שנקרא מזהה הלקוח, והשני הוא מפתח סודי שנקרא סוד הלקוח. בלי המפתחות האלה, האפליקציה לא יכולה לשלוח בקשות לקודי הרשאה או לטוקני גישה לשרת ההרשאות. שימו לב: במפרט של IETF OAuth המפתחות האלה נקראים מזהה לקוח וסוד לקוח, אבל בממשק המשתמש של Apigee הם נקראים מספר צרכן וסוד צרכן. הם שווי ערך.
סיכום של תרחישים לדוגמה של OAuth 2.0
הבחירה בתהליך של סוג ה-grant של OAuth 2.0 שאתם רוצים להטמיע תלויה בתרחיש לדוגמה הספציפי שלכם, כי סוגי grant מסוימים מאובטחים יותר מאחרים. הבחירה בסוגי ה-grant תלויה במידת האמינות של אפליקציית הלקוח, וצריך לשקול אותה בזהירות רבה, כפי שמתואר בטבלה הבאה:
| תרחיש לדוגמה | אמינות | סוגי ה-Authorization Grant המומלצים של OAuth 2.0 | תיאור |
|---|---|---|---|
| B2B (אקסטרא-נט), אינטרא-נט, אחר |
אפליקציות מהימנות מאוד, שנכתבו על ידי מפתח פנימי או מפתחים שיש להם קשר עסקי מהימן עם ספק ה-API. אפליקציות שצריכות לגשת למשאבים בשמן. |
|
|
| אתרי אינטראנט, פורטלים |
אפליקציות מהימנות שפותחו על ידי מפתחים פנימיים או מפתחי צד שלישי מהימנים. דוגמה טובה לכך היא התחברות לאתר משאבי האנוש של החברה כדי לבחור ביטוח, לשלוח ביקורות או לשנות מידע אישי. |
|
|
| אפליקציות שזמינות לכולם | אפליקציות לא מהימנות נכתבות על ידי מפתחי צד שלישי שאין להם קשר עסקי מהימן עם ספק ה-API. לדוגמה, בדרך כלל לא כדאי לסמוך על מפתחים שנרשמים לתוכניות API ציבוריות. |
|
|
| B2C | יש משתמש קצה פרטי (משתמש בנייד) שמעורב בתהליך, ופרטי הכניסה של המשתמש מאוחסנים במכשיר הנייד. |
|
|
אבטחה של OAuth 2.0 לעומת מפתח API
כדי לאמת מפתח API, האפליקציה צריכה לשלוח מפתח ל-Apigee. הטוקן חייב להיות טוקן צרכן תקף מאפליקציית מפתחים של Apigee שמשויכת ל-proxy ל-API. אם מסיבה כלשהי אתם צריכים לבטל את ההרשאה של אפליקציית לקוח לבצע קריאות לשרת proxy, אתם צריכים לבטל את טוקן הצרכן הזה. גם אפליקציות לקוח שמשתמשות במפתח הזה לא יוכלו לגשת ל-proxy ל-API. לעומת זאת, אפשר לבטל אסימון OAuth בכל שלב בלי לבטל את המפתחות של האפליקציה. האפליקציה יכולה פשוט לבקש טוקן חדש בשם המשתמש, ואם היא מקבלת טוקן, היא יכולה להמשיך להשתמש ב-proxy ל-API.
הבדל נוסף בין מפתח API לבין אסימון הוא שאסימון יכול לכלול מאפייני מטא-נתונים שאפשר לאחזר ולהשתמש בהם מאוחר יותר. לדוגמה, אתם יכולים לאחסן את המזהה של המשתמש שמבצע את הקריאה ל-API ולהשתמש בו כדי להתאים אישית את הקריאות לשירות היעד לקצה העורפי.
למידע נוסף על אימות מפתחות API, קראו את המאמר מפתחות API. למידע על שימוש במאפיינים מותאמים אישית עם אסימוני OAuth, קראו את המאמר התאמה אישית של אסימונים וקודי הרשאה.
ההשפעה של זמני התפוגה והמחיקה של טוקנים על נפח האחסון בדיסק
כשיוצרים אסימון OAuth חדש באמצעות מדיניות OAuthV2, אפשר להגדיר את זמן התפוגה של האסימון באמצעות המאפיין ExpiresIn. כברירת מחדל, אסימונים נמחקים מהאחסון שלושה ימים אחרי שהתוקף שלהם פג. אם מגדירים זמן תפוגה ארוך, למשל 48 שעות, יכול להיות שתראו עלייה לא צפויה בשימוש במקום בכונן של Cassandra. כדי להימנע משימוש עודף במקום בכונן, אפשר להגדיר זמן תפוגה קצר יותר (מומלץ שעה אחת) או להגדיר תצורה שמשנה את העיכוב של שלושה ימים לאחר התפוגה לתקופה קצרה יותר.
לקוחות Apigee hybrid יכולים לשנות את זמן המחיקה הסופית שמוגדר כברירת מחדל על ידי הגדרת התצורה הבאה בקובץ השינויים שלהם:
runtime:
cwcAppend:
"conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"כאשר SECONDS הוא מספר השניות ש-Apigee ימתין לפני שימחק את האסימונים אחרי שתוקפם יפוג. חשוב לכלול את הבית הזה בדיוק כפי שהוא כתוב, כולל המירכאות.
לדוגמה, כדי להגדיר את זמן המחיקה לשעה אחת אחרי התפוגה:
runtime:
cwcAppend:
"conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"