אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
מפתח API (שנקרא ב-Apigee Edge טוקן צרכן) הוא ערך מחרוזת שמועבר על ידי אפליקציית לקוח ל-proxy ל-API. המפתח מזהה באופן ייחודי את אפליקציית הלקוח.
אימות מפתח API הוא הצורה הפשוטה ביותר של אבטחה מבוססת-אפליקציה שאפשר להגדיר עבור API. אפליקציית לקוח פשוט שולחת מפתח API עם הבקשה שלה, ואז Apigee Edge בודק שמפתח ה-API נמצא במצב מאושר עבור המשאב המבוקש. באופן פנימי, ה-proxies משתמשים במדיניות כדי לאמת את האותנטיות של מפתחות ה-API.
כדי לתמוך בפשטות הזו, צריך לבצע הגדרה קצרה. כדי לתמוך במפתחות API, צריך:
- יוצרים מוצר API ב-Apigee Edge שכולל את שרתי ה-proxy ל-API שרוצים להגן עליהם באמצעות מפתח ה-API.
-
יוצרים אפליקציה למפתחים ב-Apigee Edge שמייצגת את מפַתח אפליקציות הלקוח שאתם רוצים לאמת.
כשיוצרים את אפליקציית המפתח, מציינים את מוצרי ה-API שאפליקציית המפתח תקבל גישה אליהם – ואת מוצרי ה-API שבהם היא תצטרך לספק מפתח API.
- לפרוקסי (זה שכללתם במוצר ה-API), מוסיפים מדיניות כדי לוודא שמפתח ה-API הנכנס תקין.
המדריך אבטחת API באמצעות דרישת מפתחות API הוא דרך מהירה ללמוד איך לשלוט בגישה ל-proxy ל-API באמצעות מפתח API.
איך מפתחות API פועלים
ב-Apigee Edge, מפתח API נקרא טוקן צרכן. כשרושמים אפליקציות למפתחים, מערכת Apigee Edge יוצרת אסימון צרכן וסוד צרכן. טוקן הצרכן מאוחסן ב-Apigee Edge לצורך אימות עתידי. כל טוקן צרכן הוא ייחודי בארגון. מפתחי האפליקציה מטמיעים את טוקן הצרכן באפליקציית הלקוח. אפליקציית הלקוח צריכה להציג את טוקן הצרכן בכל בקשה. שירותי ה-API מאמתים את טוקן הצרכן לפני שהם מאשרים את הבקשה של האפליקציה.
שלבים כלליים
בשלבים הבאים מוסבר איך Apigee Edge משתמש במפתחות API. השלבים האלה כוללים גם את האפשרות לנוכחות של אבטחת OAuth, כי לעיתים קרובות משתמשים בה בשילוב עם מפתחות API.
- יוצרים מוצר API שכולל שרתי proxy ל-API שצריך להגן עליהם באמצעות מפתח ה-API.
- רושמים אפליקציה למפתחים בארגון. כשעושים את זה, Apigee Edge יוצר טוקן צרכן וסוד צרכן.
- משייכים את האפליקציה למפתחים למוצר 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 Edge מאמת שהאסימון לא פג, ואז מחפש את טוקן הצרכן ששימש ליצירת האסימון.
- אם אתם משתמשים במפתח API – הטמעתם מדיניות VerifyAPIKey ואפליקציית הלקוח העבירה את מפתח הצרכן שלה:
- Apigee Edge בודק את רשימת מוצרי ה-API שאליהם משויך טוקן הצרכן.
- Edge בודק כל מוצר API כדי לראות אם ה-API Proxy הנוכחי כלול במוצר ה-API, ואם נתיב המשאב הנוכחי (נתיב כתובת ה-URL) מופעל במוצר ה-API.
- בנוסף, Edge מאמת שטוקן הצרכן לא פג או בוטל, בודק שהאפליקציה לא בוטלה ובודק שהמפתח לא לא פעיל.
- אם כל התנאים האלה מתקיימים – תוקף האסימון לא פג (אם רלוונטי), טוקן הצרכן תקף ומאושר, האפליקציה מאושרת, המפתח פעיל, ה-proxy זמין במוצר והמשאב זמין במוצר – אימות פרטי הכניסה מצליח.