מבוא ל-OAuth 2.0

מוצג המסמך של 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. אם אתם לא מכירים את המונחים שמופיעים בתרשים, תוכלו לקרוא את הקטע הזה כדי מבוא.

מונחים שכדאי להכיר

• לקוח: נקרא גם "האפליקציה". זו יכולה להיות אפליקציה שפועלת בנייד במכשיר או באפליקציית אינטרנט רגילה. האפליקציה שולחת בקשות לשרת המשאבים עבור נכסים מטעם בעלי המשאב. הבעלים של המשאב צריך לתת לאפליקציה הרשאה ל לגשת למשאבים המוגנים.
• בעלי המשאב: נקרא גם 'משתמש קצה'. בדרך כלל מדובר אדם (או ישות אחרת) שיכול להעניק גישה למשאב מוגן. עבור לדוגמה, אם אפליקציה צריכה להשתמש בנתונים מאחד מאתרי המדיה החברתית שלכם, בעלי המשאב – האדם היחיד שיכול להעניק לאפליקציה גישה לנתונים שלכם.
• שרת משאבים: אפשר לחשוב על שרת המשאבים בתור שירות כמו Facebook, Google או Twitter. או שירות משאבי אנוש ברשת האינטראנט שלך; או בשירות שותף אקסטרנט B2B. Apigee Edge הוא שרת משאבים בכל פעם שנדרש אימות של אסימון OAuth כדי לעבד בקשות API. שרת המשאבים זקוק להרשאה כלשהי לפני שהוא יוצג משאבים מוגנים לאפליקציה.
• שרת הרשאות: שרת ההרשאות הוטמע בהתאם למפרט של OAuth 2.0, והוא אחראי אימות הענקת הרשאות והנפקת הגישה אסימונים שמעניקים לאפליקציה גישה לנתוני המשתמש בשרת המשאבים. שלך הוא יכול להגדיר 'נקודות קצה של אסימון' ב-Apigee Edge, ובמקרה כזה Edge מקבל את התפקיד שרת האימות.
• הענקת הרשאה: מעניקה לאפליקציה הרשאה לאחזר גישה אסימון בשם משתמש הקצה. ב-OAuth 2.0 מוגדרים ארבעה "סוגי הענקות" ספציפיים. מידע נוסף זמין במאמר מהם סוגי ההרשאות OAuth 2.0. שלמטה.
• אסימון גישה: מחרוזת ארוכה של תווים שמשמשת פרטי כניסה שמשמשים לגישה למשאבים מוגנים. אפשר לעיין גם במאמר מהי גישה אסימון?" שלמטה.
• משאב מוגן: נתונים שבבעלות הבעלים של המשאב. לדוגמה, רשימת אנשי הקשר, פרטי החשבון או מידע אישי רגיש אחר של המשתמשים.

איפה Apigee Edge נכנס

באמצעות OAuth 2.0 אפשר להגן על כל API שמועבר דרך שרת proxy דרך Apigee Edge. Edge כולל באמצעות שרת ההרשאות, ולכן אפשר ליצור ולאמת אסימוני גישה. מפתחים מתחילים ברישום האפליקציות שלהם ב-Apigee Edge. אפליקציות רשומות יכולות לבקש אסימוני גישה באמצעות כל אחת מארבעת המוענקים סוג.

ב-Apigee יש מדיניות OAuthV2 רבת מאפיינים שמטמיעה פרטים על כל סוג הענקת גישה, וכך קל יחסית להגדיר את OAuth ב-Apigee Edge. עבור לדוגמה, אפשר להגדיר מדיניות שמקבלת בקשה לאסימון גישה, ומעריכה את כל פרטי הכניסה הנדרשים, ומחזירה אסימון גישה אם פרטי הכניסה תקפים.

חשוב לשים לב שכל שרתי המשאבים שהקריאות שלהם לשרת ה-proxy המאובטחות ל-API צריכים להיות מאחורי חומת אש. (כלומר, אסור שהמשאבים יהיו נגישים דרך כל אמצעי מלבד שרת ה-proxy ל-API או API מאובטח היטב).

מה זה OAuth 2.0 סוגי מענקים?

אפשר לחשוב על סוגי הענקות הגישה בתור אינטראקציות או מסלולים שונים שהאפליקציה יכולה לעבור כדי לקבל גישה ב-Assistant. כל סוג הענקה מיועד לתרחיש אחד או יותר לדוגמה, וצריך לבחור את סוג ההרשאה לשימושים בהתאם לצרכים שלכם. באופן כללי, לכל סוג מענק יש יתרונות ואת החסרונות שלו, ותצטרכו לשקול את האיזונים בהתאם לתרחישים לדוגמה העסקיים שלכם. אחת שיקול חשוב הוא "אמינות" של האפליקציות שניגשו לנתונים. באופן כללי, אפליקציות צד שלישי פחות אמינות מאשר אפליקציות שפותחו ונמצאות בשימוש של הארגון.

Apigee Edge תומכת בארבעת הסוגים העיקריים של הענקת OAuth 2.0:

• קוד הרשאה – זהו סוג המענק המאובטח ביותר. לפני שרת ההרשאות מנפיק אסימון גישה, האפליקציה צריכה קודם לקבל קוד הרשאה משרת המשאבים. ראית את התהליך הזה בכל פעם שהאפליקציה שלך פותחת דפדפן לדף ההתחברות של שרת המשאבים (Resource) והזמנה להתחבר לחשבון האמיתי שלך (לדוגמה, Facebook או Twitter).

אם התחברת בהצלחה, האפליקציה תקבל הרשאה הקוד שבו הוא יכול להשתמש כדי לנהל משא ומתן על אסימון גישה עם שרת ההרשאות. בדרך כלל, המערכת משתמשת בסוג ההענקה כאשר האפליקציה נמצאת בשרת ולא בלקוח. סוג ההרשאה הזה הוא נחשבת למאובטחת מאוד מכיוון שאפליקציית הלקוח אף פעם לא מטפלת בשם המשתמש של המשתמש או רואה אותו, הסיסמה של שרת המשאבים (לדוגמה, האפליקציה אף פעם לא רואה את פרטי כניסה ל-Twitter). תהליך סוג המענק הזה נקרא גם 'שלוש רגליים' OAuth.

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

OAuth 2.0 לעומת מפתח API אבטחה

כדי לאמת את מפתח API, האפליקציה צריכה לשלוח מפתח ל-Edge. המפתח חייב להיות מפתח צרכן תקף מאפליקציה למפתחים של Apigee Edge שמשויכת לשרת ה-proxy ל-API. אם מסיבה כלשהי צריך לבטל את ההרשאה שאפליקציית לקוח תוכל לבצע כדי להתקשר לשרת proxy, צריך לבטל את ההרשאה הזו קוד צרכן. גם אפליקציות לקוח שמשתמשות במפתח הזה לא יוכלו לגשת לשרת ה-proxy של ה-API. ב לעומת זאת, אפשר לבטל אסימון OAuth בכל שלב, בלי לבטל את מפתחות האפליקציה. האפליקציה יכול פשוט לבקש אסימון חדש בשם המשתמש, ואם ניתן אסימון, האפליקציה יכולה ממשיכים להשתמש ב-Proxy ל-API.

הבדל נוסף בין מפתח API לאסימון הוא שהאסימון יכול לכלול מטא-נתונים שבהם תוכלו לאחזר ולהשתמש בהם מאוחר יותר. לדוגמה, אפשר לשמור את מזהה המשתמש ביצוע הקריאה ל-API ולהשתמש בה כדי להתאים אישית קריאות לשירות היעד של הקצה העורפי.

מידע נוסף על אימות של מפתחות API זמין במאמר API . למידע על שימוש במאפיינים מותאמים אישית עם אסימוני OAuth, ראה התאמה אישית של אסימונים ו קודי הרשאות.

המלצות משאבים

קריאה

מידע נוסף זמין במאמר מידע על OAuth 2.0.