הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
מפתח API (שנקרא ב-Apigee טוקן צרכן) הוא ערך מחרוזת שמועבר על ידי אפליקציית לקוח ל-proxy ל-API. המפתח מזהה באופן ייחודי את אפליקציית הלקוח.
אימות מפתח API הוא הצורה הפשוטה ביותר של אבטחה מבוססת-אפליקציה שאפשר להגדיר עבור API. אפליקציית לקוח פשוט שולחת מפתח API עם הבקשה שלה, ואז Apigee בודק שמפתח ה-API נמצא במצב מאושר עבור המשאב המבוקש. באופן פנימי, ה-proxies משתמשים במדיניות כדי לאמת את האותנטיות של מפתחות ה-API.
כדי לתמוך בפשטות הזו, תצטרכו לבצע הגדרה קצרה. כדי לתמוך במפתחות API, צריך:
- יוצרים מוצר Apigee API שכולל את שרתי ה-proxy ל-API שרוצים להגן עליהם באמצעות מפתח ה-API.
-
יוצרים אפליקציית מפתחים ב-Apigee שמייצגת את מפתח אפליקציית הלקוח שאותה תאמתו.
כשיוצרים את אפליקציית המפתח, מציינים את מוצרי ה-API שאליהם תהיה לאפליקציה של המפתח גישה – ושעבורם היא תצטרך לספק מפתח API.
- לפרוקסי (אלה שכללתם במוצר ה-API), מוסיפים מדיניות כדי לוודא שמפתח ה-API הנכנס תקין.
המדריך אבטחת API באמצעות דרישת מפתחות API הוא דרך מהירה ללמוד איך לשלוט בגישה ל-proxy ל-API באמצעות מפתח API.
איך מפתחות API פועלים
ב-Apigee, מפתח API נקרא מפתח צרכן. כשרושמים אפליקציות למפתחים, Apigee יוצר טוקן צרכן וסוד. מערכת Apigee שומרת את טוקן הצרכן לצורך אימות עתידי. כל טוקן צרכן הוא ייחודי בארגון. מפתחי האפליקציה מטמיעים את טוקן הצרכן באפליקציית הלקוח. אפליקציית הלקוח צריכה להציג את טוקן הצרכן בכל בקשה. שירותי ה-API מאמתים את טוקן הצרכן לפני שהם מאשרים את הבקשה של האפליקציה.
שלבים כלליים
בשלבים הבאים מתואר השימוש במפתחות API ב-Apigee. השלבים האלה כוללים גם את האפשרות של אבטחת OAuth, כי לרוב משתמשים בה בשילוב עם מפתחות API.
- יוצרים מוצר API שכולל שרתי proxy ל-API שצריך להגן עליהם באמצעות מפתח ה-API.
- רושמים אפליקציה למפתחים בארגון. כשעושים את זה, Apigee יוצר טוקן צרכן וסוד צרכן.
- משייכים את האפליקציה למפתחים למוצר API אחד לפחות. הוא המוצר שמקשר בין נתיבי משאבים ובין שרתי proxy של API לאישור מפתח.
- בזמן הריצה, כשאפליקציית הלקוח שולחת בקשה ל-API, אפליקציית הלקוח שולחת את טוקן הצרכן כשהיא שולחת את הבקשה. בפועל, יכול להיות שטוקן הצרכן יועבר באופן מפורש או שיהיה אליו הפניה באופן מרומז דרך טוקן OAuth:
- אם ה-API משתמש באימות של מפתח API – למשל על ידי הטמעה של מדיניות VerifyAPIKey – אפליקציית הלקוח צריכה להעביר את טוקן הצרכן באופן מפורש.
- כשממשק ה-API משתמש באימות של טוקן OAuth – למשל על ידי הטמעה של מדיניות OAuthV2 – אפליקציית הלקוח צריכה להעביר טוקן שנגזר ממפתח הצרכן.
- ה-API Proxy מאמת את פרטי הכניסה של הבקשה באמצעות מדיניות VerifyAPIKey או מדיניות OAuthV2 עם פעולת VerifyAccessToken. אם לא תכללו מדיניות לאכיפת אישורים ב-API Proxy, כל מי שיבצע קריאה ל-API יוכל להפעיל את ממשקי ה-API שלכם בהצלחה. מידע נוסף זמין במאמר בנושא אימות מדיניות מפתח API.
אימות פרטי הכניסה של הבקשה
זו סקירה כללית. פרטים ודוגמאות קוד זמינים במאמר בנושא הגדרת אימות של מפתח API.
- אם אתם משתמשים באימות של טוקנים מסוג OAuth – הטמעתם מדיניות OAuth כדי לאמת
ואפליקציית הלקוח העבירה טוקן מסוג OAuth:
- Apigee בודק שהתוקף של האסימון לא פג, ואז מחפש את טוקן הצרכן ששימש ליצירת האסימון.
- אם אתם משתמשים במפתח API – הטמעתם מדיניות VerifyAPIKey ואפליקציית הלקוח העבירה את טוקן הצרכן שלה:
- Apigee בודק את רשימת מוצרי ה-API שאליהם משויך טוקן הצרכן.
- מערכת Apigee בודקת כל מוצר API כדי לראות אם ה-API Proxy הנוכחי כלול במוצר ה-API, ואם נתיב המשאב הנוכחי (נתיב כתובת האתר) מופעל במוצר ה-API.
- בנוסף, Apigee מוודא שתוקף טוקן הצרכן לא פג או שהוא לא בוטל, בודק שהאפליקציה לא בוטלה ומוודא שהמפתח לא לא פעיל.
- אם כל התנאים האלה מתקיימים – תוקף האסימון לא פג (אם רלוונטי), טוקן הצרכן תקף ומאושר, האפליקציה מאושרת, המפתח פעיל, ה-proxy זמין במוצר והמשאב זמין במוצר – אימות פרטי הכניסה יצליח.