הטמעת סוג המענק של פרטי הכניסה של הלקוח

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

בסוג הענקת פרטי הכניסה של הלקוח, אפליקציה שולחת את פרטי הכניסה שלה (ה-Client-ID סוד לקוח) לנקודת קצה ב-Apigee Edge שמוגדרת ליצירת אסימון גישה. אם פרטי הכניסה תקפים, דפדפן Edge מחזיר אסימון גישה לאפליקציית הלקוח.

מידע על נושא זה

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

תרחישים לדוגמה

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

תפקידים

תפקידים מציינים את "השחקנים" שמשתתפים בתהליך OAuth. סקירה כללית קצרה את התפקידים של פרטי הכניסה של הלקוח כדי להמחיש היכן Apigee Edge נכנס. לקבלת תמונה מלאה דיון על תפקידי OAuth 2.0 זמין במפרט OAuth 2.0 של IETF.

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

דוגמת קוד

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

תרשים זרימה

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

השלבים בתהליך פרטי הכניסה של הלקוח

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

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

1. הלקוח מבקש אסימון גישה

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

לדוגמה:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'

הערה: למרות שאפשר להעביר את הערכים client_id ו-client_secret כשאילתה מומלץ להעביר אותם כמחרוזת מקודדת של כתובת אתר base64 הכותרת Authorization לשם כך, עליך להשתמש בכלי קידוד או בכלי קידוד base64 כדי לקודד בין שני הערכים יחד עם נקודתיים שמפרידה ביניהם. כך: aBase64EncodeFunction(clientidvalue:clientsecret). הדוגמה שלמעלה תקודד כך: הזה:

result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // שימו לב ל נקודתיים שמפרידה בין שני הערכים.

התוצאה של קידוד ב-base64 למחרוזת שלמעלה היא: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==

לאחר מכן, יוצרים את בקשת האסימון כך:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='

2. Edge מאמת את פרטי כניסה

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

3. Edge מחזיר תשובה

אם פרטי הכניסה תקינים, Edge מחזיר אסימון גישה ללקוח. אם לא, השגיאה הוחזרו.

4. הלקוח קורא ל API מוגן

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

הגדרת תהליכים וכללי מדיניות

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

הגדרת תהליכי עבודה בהתאמה אישית

הדרך הקלה ביותר להראות איך מוגדר זרימת ה-Proxy ל-API היא להציג את זרימת ה-XML. להגדרה. לפניכם דוגמה לתהליך של שרת proxy ל-API שמיועד לעבד בקשה לאסימון גישה. עבור לדוגמה, כשבקשה מגיעה וסיומת הנתיב תואמת ל- /accesstoken, רכיב ה-GetAccessToken מופעלת. מידע נוסף זמין במאמר הגדרת OAuth נקודות קצה וכללי מדיניות כדי לקבל סקירה כללית מהירה של השלבים ליצירת תהליך מותאם אישית. ככה.

<Flows>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GetAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

הגדרת התהליך באמצעות מדיניות

צריך לצרף מדיניות לנקודת הקצה, באופן הבא. מידע נוסף זמין במאמר הגדרת OAuth נקודות קצה וכללי מדיניות כדי לקבל סקירה כללית מהירה של השלבים הנדרשים להוספת מדיניות OAuthV2 לנקודת קצה של שרת proxy.

קבלת אסימון גישה

המדיניות הזו מצורפת לנתיב /accesstoken. היא משתמשת ב-OAuthV2 המדיניות עם הפעולה GenerateAccessToken שצוינה.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse/>
</OAuthV2>

הקריאה ל-API לקבלת אסימון הגישה היא POST והיא כוללת כותרת Authorization עם פרמטר client_id + לקוח+סוד בקידוד base64 ופרמטר השאילתה grant_type=client_credentials. הוא יכול גם לכלול פרמטרים אופציונליים להיקף ולמצב. עבור דוגמה:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'

צירוף המדיניות לאימות אסימון הגישה

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

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

שליחת קריאה ל-API המוגן

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

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282 

למידע נוסף, ראו שליחת גישה .

מקורות מידע נוספים

• Apigee מציעה הדרכה אונליין למפתחי API, כולל קורס בנושא API , כולל OAuth.
• מדיניות OAuthV2 – כולל הרבה דוגמאות שמראות איך לשלוח בקשות לשרת ההרשאות ואיך להגדיר מדיניות OAuthV2.