הדף הזה רלוונטי ל-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, והוא אחראי לאימות הרשאות הגישה ולהנפקת אסימוני הגישה שמאפשרים לאפליקציה לגשת לנתוני המשתמש בשרת המשאבים. אפשר להגדיר נקודות קצה של טוקנים ב-Apigee, ובמקרה כזה Apigee מקבל את התפקיד של שרת הרשאות.
- הרשאת גישה: מאפשרת לאפליקציה לאחזר טוקן גישה בשם משתמש הקצה. ב-OAuth 2.0 מוגדרים ארבעה סוגים ספציפיים של הרשאות. מהם סוגי ההרשאות ב-OAuth 2.0
- אסימון גישה: מחרוזת ארוכה של תווים שמשמשת כפרטי כניסה לגישה למשאבים מוגנים. מידע נוסף זמין במאמר מה זה אסימון גישה?
- משאב מוגן: נתונים שבבעלות בעל המשאב. לדוגמה, רשימת אנשי הקשר של המשתמש, פרטי החשבון או מידע אישי רגיש אחר.
איפה Apigee משתלב
אפשר להגן על כל API שמועבר דרך Apigee באמצעות OAuth 2.0. Apigee כולל הטמעה של שרת הרשאות, ולכן יכול ליצור ולאמת אסימוני גישה. השלב הראשון למפתחים הוא רישום האפליקציות שלהם ב-Apigee. אפליקציות רשומות יכולות לבקש טוקנים לגישה דרך כל אחת מארבע האינטראקציות של סוג ההרשאה.
Apigee מספקת מדיניות OAuthV2 מורכבת שמיישמת את הפרטים של כל סוג הרשאה, ולכן יחסית קל להגדיר OAuth ב-Apigee. לדוגמה, אפשר להגדיר מדיניות שמקבלת בקשה לאסימון גישה, מעריכה את כל פרטי הכניסה הנדרשים ומחזירה אסימון גישה אם פרטי הכניסה תקפים.
חשוב לשים לב שכל שרתי המשאבים שה-proxy ל-API המאובטח שלכם קורא להם צריכים להיות מאחורי חומת אש (כלומר, אסור שתהיה גישה למשאבים בשום דרך אחרת מלבד דרך ה-proxy ל-API או API אחר שמאובטח היטב).
מהם סוגי ההרשאות ב-OAuth 2.0?
אפשר לחשוב על סוגי הרשאות כעל נתיבים או אינטראקציות שונים שאפליקציה יכולה לבצע כדי לקבל אסימון גישה. כל סוג מענק מתאים לתרחיש שימוש אחד או יותר, ותצטרכו לבחור את סוגי המענקים שבהם תרצו להשתמש בהתאם לצרכים שלכם. באופן כללי, לכל סוג של הרשאה יש יתרונות וחסרונות, ותצטרכו לשקול את הפשרות האפשריות בהתאם לתרחישי השימוש בעסק שלכם. שיקול חשוב הוא המהימנות של האפליקציות שיקבלו גישה לנתונים שלכם. באופן כללי, אפליקציות של צד שלישי נחשבות לפחות מהימנות מאפליקציות שמפותחות ומשמשות בתוך ארגון.
Apigee תומך בארבעת סוגי ההרשאות העיקריים של OAuth 2.0:
- authorization code (קוד הרשאה) – נחשב לסוג ההרשאה המאובטח ביותר. לפני ששרת ההרשאות מנפיק אסימון גישה, האפליקציה צריכה קודם לקבל קוד הרשאה משרת המשאבים. התהליך הזה קורה בכל פעם שהאפליקציה פותחת דפדפן לדף הכניסה של שרת המשאבים ומזמינה אתכם להיכנס לחשבון שלכם בפועל (לדוגמה, פייסבוק או טוויטר).
אם הכניסה תתבצע בהצלחה, האפליקציה תקבל קוד הרשאה שבאמצעותו היא תוכל לנהל משא ומתן עם שרת ההרשאות כדי לקבל אסימון גישה. בדרך כלל משתמשים בסוג ההרשאה הזה כשהאפליקציה נמצאת בשרת ולא בלקוח. סוג ההרשאה הזה נחשב למאובטח מאוד כי אפליקציית הלקוח אף פעם לא מטפלת בשם המשתמש או בסיסמה של המשתמש בשרת המשאבים (כלומר, לדוגמה, האפליקציה אף פעם לא רואה את פרטי הכניסה שלכם לטוויטר או מטפלת בהם). תהליך ההרשאה הזה נקרא גם OAuth תלת-רגלי.
- משתמע (Implicit) – נחשב לגרסה פשוטה של קוד הרשאה. בדרך כלל משתמשים בסוג ההרשאה הזה כשהאפליקציה נמצאת בצד הלקוח. לדוגמה, הקוד של האפליקציה מוטמע בדפדפן באמצעות JavaScript או שפת סקריפטים אחרת (במקום להיות בשרת אינטרנט נפרד ולהיטמע בו). בתהליך הזה של סוג ההרשאה, שרת ההרשאות מחזיר אסימון גישה ישירות כשהמשתמש מאומת, במקום להנפיק קוד הרשאה קודם. במקרים מסוימים, הרשאות משתמעות יכולות לשפר את מהירות התגובה של האפליקציה, אבל צריך לשקול את היתרון הזה מול ההשלכות האפשריות על האבטחה, כפי שמתואר במפרט של IETF.
- פרטי כניסה של סיסמה של בעל משאב – בתהליך הזה, הלקוח מקבל אסימון גישה כשהשרת לאישור הרשאות מאמת את שם המשתמש והסיסמה של המשתמש. התהליך הזה מומלץ לאפליקציות מהימנות מאוד. יתרון של התהליך הזה על פני אימות בסיסי, למשל, הוא שהמשתמש מזין את שם המשתמש והסיסמה רק פעם אחת. מנקודה זו ואילך, נעשה שימוש בטוקן הגישה.
- פרטי כניסה של לקוח – מומלץ להשתמש בהם במצבים שבהם אפליקציית הלקוח פועלת בשם עצמה. כלומר, הלקוח הוא גם הבעלים של המשאב. בדרך כלל משתמשים בסוג ההרשאה הזה כשהאפליקציה צריכה לגשת לשירות אחסון נתונים בעורף, למשל. האפליקציה צריכה להשתמש בשירות כדי לבצע את העבודה שלה, והשירות לא גלוי למשתמש הקצה. בסוג ההרשאה הזה, אפליקציה יכולה לקבל טוקן גישה על ידי הצגת מזהה הלקוח ומפתחות סוד הלקוח לשרת ההרשאות. לא נדרשים שלבים נוספים. מספק פתרון מוכן לשימוש של פרטי לקוח, שקל להטמיע בכל 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 שנקראים three-legged, המשתמש בדרך כלל מציין את רמת הגישה דרך דף הסכמה (לדוגמה, דף אינטרנט שבו המשתמש בוחר את ההיקף באמצעות תיבת סימון או מנגנון אחר).
רישום אפליקציה
כל הלקוחות (האפליקציות) חייבים להירשם בשרת ההרשאות של OAuth 2.0, שממנו הם מתכוונים לבקש אסימוני גישה. כשרושמים אפליקציה, מקבלים בחזרה קבוצה של מפתחות. אחד מהם הוא מפתח ציבורי שנקרא מזהה הלקוח, והשני הוא מפתח סודי שנקרא הסוד של הלקוח. ללא המפתחות האלה, אפליקציה לא יכולה להנפיק בקשות לקודי הרשאה או לטוקנים של גישה לשרת ההרשאות. שימו לב: למרות שבמפרט OAuth של IETF המפתחות האלה נקראים מזהה לקוח וסוד לקוח, בממשק המשתמש של Apigee הם נקראים מספר צרכן וסוד צרכן. הן שוות.
סיכום של תרחישי שימוש ב-OAuth 2.0
סוג תהליך ההרשאה של OAuth 2.0 שתבחרו להטמיע תלוי בתרחיש השימוש הספציפי שלכם, כי יש סוגים של הרשאות שהם מאובטחים יותר מאחרים. הבחירה שלכם בסוגי ההרשאות תלויה במידת המהימנות של אפליקציית הלקוח, וצריך לשקול אותה בקפידה רבה, כפי שמתואר בטבלה הבאה:
| תרחיש לדוגמה | אמינות | סוגי הרשאות מומלצים ב-OAuth 2.0 | תיאור |
|---|---|---|---|
| B2B (extranet), intranet, other |
אפליקציות שזוכות לאמון רב, שנכתבו על ידי מפתחים פנימיים או מפתחים שיש להם קשר עסקי מהימן עם ספק ה-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"