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