הדף הזה רלוונטי ל-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:
- קוד הרשאה – נחשב לסוג ההרשאה המאובטח ביותר. לפני ששרת ההרשאות מנפיק אסימון גישה, האפליקציה צריכה לקבל קוד הרשאה משרת המשאבים. אתם נתקלים בתהליך הזה בכל פעם שהאפליקציה פותחת דפדפן לדף הכניסה של שרת המשאבים ומזמינה אתכם להיכנס לחשבון שלכם (לדוגמה, פייסבוק או טוויטר).
אם תצליחו להתחבר, האפליקציה תקבל קוד הרשאה שבו היא יכולה להשתמש כדי לנהל משא ומתן על טוקן גישה עם שרת ההרשאות. בדרך כלל, סוג ההרשאה הזה משמש כשהאפליקציה נמצאת בשרת ולא בלקוח. סוג ההרשאה הזה נחשב למאובטח מאוד כי אפליקציית הלקוח אף פעם לא מטפלת בשם המשתמש או בסיסמה של המשתמש לשרת המשאבים, או רואה אותם (לדוגמה, האפליקציה אף פעם לא רואה את פרטי הכניסה שלכם לטוויטר או מטפלת בהם). תהליך סוג ההרשאה הזה נקרא גם 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 | יש משתמש קצה פרטי (משתמש בנייד) שמעורב, ופרטי הכניסה של המשתמש מאוחסנים במכשיר הנייד. |
|
|
אבטחה של מפתח API לעומת OAuth 2.0
כדי לאמת מפתח 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"