אבטחת API באמצעות OAuth 2.0

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

במדריך הזה נסביר איך לאבטח proxy ל-API באמצעות אסימון גישה מסוג OAuth 2.0.

לפני שמתחילים

כדי להשלים את המדריך הזה, צריכה להיות לכם גישה לארגון Apigee שבו יש לכם הרשאה לבצע את הפעולות הבאות:

  • יצירה ופריסה של פרוקסי API
  • יצירת מוצרי API
  • יצירת אפליקציות למפתחים

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

פריסת שרת proxy של OAuth 2.0

אנחנו מספקים proxy ל-API ב-GitHub שמוגדר ליצירת אסימוני גישה מסוג OAuth 2.0. כדי להוריד ולפרוס את ה-proxy ל-API הזה בסביבה שלכם:

מורידים את oauth קובץ ה-proxy לדוגמה של ה-API לספרייה במערכת הקבצים.

  1. במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > API proxies.

    מעבר לשרתי proxy ל-API

  2. בחלונית API Proxies (שרתי proxy של API), לוחצים על + Create (יצירה).
  3. בחלונית יצירת שרת proxy, בקטע תבנית שרת proxy, בוחרים באפשרות העלאת חבילת שרת proxy.
  4. בוחרים את הקובץ oauth.zip שהורדתם ולוחצים על הבא.
  5. לוחצים על הבא.
  6. פריסה (אופציונלי):
    • סביבות פריסה: אופציונלי. משתמשים בתיבות הסימון כדי לבחור סביבה אחת או יותר שבהן רוצים לפרוס את ה-proxy. אם אתם לא רוצים לפרוס את ה-proxy בשלב הזה, אתם יכולים להשאיר את השדה סביבות פריסה ריק. תמיד אפשר לפרוס את ה-proxy מאוחר יותר.
    • חשבון שירות: אופציונלי. מצרפים חשבון שירות לפריסה כדי לאפשר לשרת ה-proxy לגשת Google Cloud לשירותים, כפי שמצוין בתפקיד ובהרשאות של חשבון השירות.
  7. לוחצים על יצירה.

הורדת ופרסת בהצלחה פרוקסי API ליצירת אסימון גישה בארגון Apigee שלך.

צפה בהרשאה באמצעות OAuth 2.0 ובמדיניות

כדאי להקדיש כמה רגעים לבדיקת הגדרת המדיניות של OAuth 2.0.

בשלב הבא נבדוק לעומק מה כלול ב-proxy ל-API.

  1. בעורך ה-proxy ל-API, לחץ על הכרטיסייה פיתוח.

    מדיניות מוצגת בכרטיסייה פיתוח.

    בחלונית הימנית, יוצגו שני כללי מדיניות. בקטע Proxy Endpoints (נקודות קצה של שרת proxy) יופיעו גם שני תהליכי POST.

  2. לוחצים על AccessTokenClientCredential בקטע Proxy Endpoints (נקודות קצה של שרת proxy). בכלי לעריכת טקסט מוצג קוד ה-XML של זרימת התנאים AccessTokenClientCredential: 
    <Flow name="AccessTokenClientCredential">
    <Description/>
    <Request>
        <Step>
            <Name>GenerateAccessTokenClient</Name>
        </Step>
    </Request>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/accesstoken") and (request.verb = "POST")</Condition>
</Flow>

    תהליך הוא שלב עיבוד ב-proxy ל-API. במקרה הזה, התהליך מופעל כשמתקיים תנאי מסוים (זה נקרא 'תהליך מותנה'). התנאי, שמוגדר ברכיב <Condition>, קובע שאם קריאת ה-proxy ל-API מתבצעת למשאב /accesstoken, ופועל הבקשה הוא POST, אז תופעל מדיניות GenerateAccessTokenClient, שמייצרת את אסימון הגישה.

  3. עכשיו נבדוק איזו מדיניות תופעל על ידי התהליך המותנה. לוחצים על המדיניות GenerateAccessTokenClient בחלונית Request: לוחצים על GenerateAccessTokenClient מתחת ל-AccessTokenClientCredential.

מוצגת הגדרת ה-XML הבאה:

<OAuthV2 name="GenerateAccessTokenClient">
    <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
    <Operation>GenerateAccessToken</Operation>
    <!-- This is in milliseconds, so expire in an hour -->
    <ExpiresIn>3600000</ExpiresIn>
    <SupportedGrantTypes>
        <!-- This part is very important: most real OAuth 2.0 apps will want to use other
         grant types. In this case it is important to NOT include the "client_credentials"
         type because it allows a client to get access to a token with no user authentication -->
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GrantType>request.queryparam.grant_type</GrantType>
    <GenerateResponse/>
</OAuthV2>

ההגדרות כוללות את הפריטים הבאים:

  • המאפיין <Operation>, שיכול להיות אחד מכמה ערכים מוגדרים מראש, מגדיר מה המדיניות תעשה. במקרה הזה, היא תיצור אסימון גישה.
  • התוקף של הטוקן יפוג שעה אחת (3,600,000 מילישניות) אחרי שהוא נוצר.
  • ב-<SupportedGrantTypes>, קוד ה-OAuth 2.0 <GrantType> הצפוי לשימוש הוא client_credentials (החלפת טוקן צרכן וסוד באסימון OAuth 2.0).
  • רכיב <GrantType> השני מציין למדיניות איפה לחפש בקריאה ל-API את הפרמטר של סוג ההרשאה, כנדרש במפרט OAuth 2.0. (תראו זאת בקריאה ל-API בהמשך). ניתן לשלוח את סוג המענק גם בכותרת HTTP (request.header.grant_type) או כפרמטר טופס (request.formparam.grant_type).

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

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

צור proxy ל-API מוגן

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

ה-proxy ל-API שתיצרו כאן יכלול מדיניות שבודקת אם יש אסימון OAuth 2.0 בבקשה.

  1. במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > API proxies.

    מעבר לשרתי proxy ל-API

  2. בחלונית API Proxies (שרתי proxy של API), לוחצים על + Create (יצירה).
  3. בחלונית יצירת פרוקסי, תחת תבנית פרוקסי, בחר פרוקסי הפוך (הנפוץ ביותר).
  4. מגדירים את ה-Proxy עם הפרטים הבאים:
    בשדה הזה תעשה את זה
    שם שרת ה-Proxy מזינים: helloworld_oauth2
    נתיב בסיסי

    החלפה בהגדרה: /hellooauth2

    נתיב הבסיס של הפרויקט הוא חלק מכתובת ה-URL שמשמשת לשליחת בקשות לשרת ה-proxy של ה-API.
    תיאור מזינים: hello world protected by OAuth 2.0
    יעד (API קיים)

    מזינים: https://mocktarget.apigee.net/ip

    זה מגדיר את כתובת ה-URL היעד ש-Apigee מפעילה בבקשה לפרוקסי ה-API.
  5. לוחצים על הבא.
  6. פריסה (אופציונלי):
    • סביבות פריסה: אופציונלי. משתמשים בתיבות הסימון כדי לבחור סביבה אחת או יותר שבהן רוצים לפרוס את ה-proxy. אם אתם מעדיפים לא לפרוס את ה-proxy בשלב זה, השאירו את השדה סביבות פריסה ריק. תמיד ניתן לפרוס את הפרוקסי מאוחר יותר.
    • חשבון שירות: אופציונלי. צרף חשבון שירות לפריסה שלך כדי לאפשר לשרת הפרוקסי שלך גישה Google Cloud שירותים, כפי שצוין בתפקיד ובהרשאות של חשבון השירות.
  7. לוחצים על יצירה.
  8. לחץ על הכרטיסייה פיתוח של הפרוקסי helloworld_oauth2.
  9. בתפריט מדיניות, לחצו על הוספת מדיניות.
  10. בחלונית Create policy (יצירת מדיניות), בוחרים באפשרות OAuth 2.0.
  11. לוחצים על יצירה.

צפייה במדיניות

בואו נבדוק את מה שיצרתם.

  1. בעורך ה-proxy ל-API, לחץ על הכרטיסייה פיתוח. אפשר לראות ששתי מדיניות נוספו לזרימת הבקשות של ה-API proxy:
    • אימות אסימון גישה של OAuth גרסה 2.0 – בדיקת קריאה ל-API כדי לוודא שקיים אסימון OAuth 2.0 תקף.
    • Remove Header Authorization (הסרת הרשאת הכותרת) – מדיניות Assign Message (הקצאת הודעה) שמסירה את אסימון הגישה אחרי שהוא נבדק, כדי שהוא לא יועבר לשירות היעד. (אם שירות היעד היה זקוק לאסימון גישה של OAuth 2.0, לא הייתם משתמשים במדיניות זו).

  2. לחץ על הסמל אימות אסימון גישה של OAuth גרסה 2.0 בחלונית הימנית ועיין בקובץ ה-XML שמתחתיו בעורך הטקסט.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="verify-oauth-v2-access-token">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <Operation>VerifyAccessToken</Operation>
</OAuthV2>

שימו לב ש<Operation> הוא VerifyAccessToken. הפעולה מגדירה מה המדיניות אמורה לעשות. במקרה הזה, היא תבדוק אם יש בבקשה אסימון OAuth 2.0 תקין.

הוספת מוצר API

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

  1. צור את מוצר ה-API:

    2. ב- Google Cloud קונסולה, עבור אלאפיגי> הֲפָצָה> מוצרי API עַמוּד.

    מעבר אל מוצרי API

  2. לוחצים על ‎+ Create.
  3. מזינים את פרטי המוצר של מוצר ה-API.
    שדה תיאור
    שם השם הפנימי של מוצר ה-API. אין לציין תווים מיוחדים בשם.
    פֶּתֶק: לא ניתן לערוך את השם לאחר יצירת מוצר ה-API.
    השם המוצג השם המוצג של מוצר ה-API. השם המוצג משמש בממשק המשתמש, ואפשר לערוך אותו בכל שלב. אם לא מציינים ערך, המערכת משתמשת בערך של המאפיין Name. השדה הזה מתמלא אוטומטית לפי הערך של השם. אפשר לערוך או למחוק את התוכן שלו. השם המוצג יכול לכלול תווים מיוחדים.
    תיאור תיאור של מוצר ה-API.
    סביבה סביבות שמוצר ה-API יאפשר גישה אליהן. בחר את הסביבה שאליה פרסת את proxy ל-API.
    גישה בוחרים באפשרות ציבורי.
    אישור אוטומטי של בקשות גישה הפעלת אישור אוטומטי של בקשות למפתחות למוצר ה-API הזה מכל אפליקציה.
    מכסה אפשר להתעלם מההודעה הזו במדריך הזה.
    היקפי OAuth 2.0 מותרים אפשר להתעלם מההודעה הזו במדריך הזה.
  4. במקטע פעולות, לחץ על הוסף פעולה.
  5. בשדה API Proxy (פרוקסי של API), בוחרים את הפרוקסי של ה-API שיצרתם.
  6. בשדה נתיב, הזן "/". התעלם מהשדות האחרים.
  7. לוחצים על שמירה כדי לשמור את הפעולה.
  8. לוחצים על שמירה כדי לשמור את מוצר ה-API.

הוספת מפתח ואפליקציה לארגון

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

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

יצירת מפתח

בואו ניצור מפתח בשם נייג'ל טאפנל.

  1. פותחים את העורך Developer.

  2. ב- Google Cloud קונסולה, עבור אלאפיגי> הֲפָצָה> מפתחים עַמוּד.

    מעבר אל Developers

  3. לוחצים על ‎+ Create.
  4. בחלון הוספת מפתח, מזינים את הפרטים הבאים:
    בתחום זה Enter
    שם פרטי Nigel
    שם משפחה Tufnel
    אימייל nigel@example.com
    שם משתמש nigel
  5. לוחצים על הוספה.

רישום אפליקציה

בואו ניצור אפליקציה עבור נייג'ל.

  1. ב- Google Cloud קונסולה, עבור אלאפיגי> הֲפָצָה> אפליקציות עַמוּד.

    מעבר אל 'אפליקציות'

  2. לוחצים על ‎+ Create.
  3. מזינים את הפרטים הבאים בחלון 'אפליקציה חדשה':
    בשדה הזה תעשה את זה
    שם ו-שם תצוגה מזינים: nigel_app
    מפתח לוחצים על Developer (מפתח) ובוחרים באחת מהאפשרויות הבאות: Nigel Tufnel (nigel@example.com)
    כתובת URL לקריאה חוזרת והערות להשאיר ריק
  4. לחץ על + הוסף אישורים.
  5. לחץ על + הוסף מוצרים.
  6. בוחרים את מוצר ה-API שיצרתם.
  7. לוחצים על הוספה.
  8. לוחצים על יצירה.

קבל את טוקן הצרכן ואת סוד הצרכן

עכשיו תקבלו את אסימון הצרכן ואת סוד הצרכן שיוחלפו באסימון גישה מסוג OAuth 2.0.

  1. פתח את דף ה-nigel_app.
    1. ודא שדף ה-nigel_app מוצג. אם לא, עוברים לדף הפצה > אפליקציות.

      מעבר אל 'אפליקציות'

    2. בדף nigel_app, לחצו על בעמודות מפתח ו-סוד. שימו לב שהמפתח/סוד משויכים למוצר ה-API שיצרתם קודם לכן.

  2. בחר והעתק את הערכים Key ו-Secret. הדבק אותם בקובץ טקסט זמני. תשתמש בהם בשלב מאוחר יותר, שבו תקרא ל-API proxy שיחליף את האישורים הללו עבור אסימון גישה של OAuth 2.0.

מנסים לשלוח קריאה ל-API כדי לקבל את כתובת ה-IP (נכשל!)

מנסים לשלוח קריאה לשרת ה-proxy המוגן של ה-API שיצרתם. שים לב שאתה לא מעביר אסימון גישה של OAuth 2.0 בקריאה.

כאשר YOUR ENV_GROUP_HOSTNAME הוא שם המארח של קבוצת הסביבות. אפשר לעיין במאמר בנושא איתור שם המארח של קבוצת הסביבות.

מכיוון ש-proxy ל-API משתמש במדיניות Verify OAuth v2.0 Access Token שבודקת אם קיים טוקן OAuth 2.0 תקף בבקשה, הקריאה אמורה להיכשל עם ההודעה הבאה:

{"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}

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

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

בשלב הבא, תשתמשו במפתח ובסוד שהעתקתם והדבקתם לקובץ טקסט ותחליפו אותם באסימון גישה של OAuth 2.0. כעת תבצעו קריאה ל-API לפרוקסי לדוגמה של ה-API שייבאתם, oauth, שיפיק אסימון גישה ל-API.

באמצעות המפתח והסוד, בצע את קריאת ה-cURL הבאה (שימו לב שהפרוטוקול הוא https):

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
"https://YOUR ENV_GROUP_HOSTNAME/oauth/client_credential/accesstoken?grant_type=client_credentials" \
-d "client_id=CLIENT_KEY&client_secret=CLIENT_SECRET"

שימו לב: אם אתם משתמשים בלקוח כמו Postman כדי לבצע את הקריאה, הפרמטרים client_id ו-client_secret צריכים להיות בגוף הבקשה, והם חייבים להיות x-www-form-urlencoded.

אתה אמור לקבל תגובה כזו:

{
  "issued_at" : "1466025769306",
  "application_name" : "716bbe61-f14a-4d85-9b56-a62ff8e0d347",
  "scope" : "",
  "status" : "approved",
  "api_product_list" : "[helloworld_oauth2-Product]",
  "expires_in" : "3599", //--in seconds
  "developer.email" : "nigel@example.com",
  "token_type" : "BearerToken",
  "client_id" : "xNnREu1DNGfiwzQZ5HUN8IAUwZSW1GZW",
  "access_token" : "GTPY9VUHCqKVMRB0cHxnmAp0RXc0",
  "organization_name" : "myOrg",
  "refresh_token_expires_in" : "0", //--in seconds
  "refresh_count" : "0"
}

קיבלת את אסימון הגישה שלך ל-OAuth 2.0! מעתיקים את הערך access_token (ללא המירכאות) ומדביקים אותו בקובץ הטקסט. תשתמש בזה עוד רגע.

מה קרה עכשיו?

זוכרים שבעבר, כשבדקתם את ה "זרימה המותנית" הזו בפרוקסי של oauth, זו שאמרה שאם URI המשאב הוא /accesstoken ופועל הבקשה הוא POST, כדי לבצע את מדיניות OAuth 2.0 של GenerateAccessTokenClient שמייצרת אסימון גישה? פקודת ה-cURL שלך עמדה בתנאים האלה, ולכן מדיניות OAuth 2.0 הופעלה. המערכת אימתה את טוקן הצרכן ואת הסוד של הצרכן והחליפה אותם באסימון OAuth 2.0 שתוקפו יפוג תוך שעה.

שליחת קריאה ל-API עם אסימון גישה (הצלחה!)

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

curl https://YOUR ENV_GROUP_HOSTNAME/hellooauth2 -H "Authorization: Bearer TOKEN"

עכשיו אמורה להתקבל קריאה מוצלחת ל-proxy ל-API שמחזירה את כתובת ה-IP שלכם. לדוגמה:

{"ip":"::ffff:192.168.14.136"}

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

כל הכבוד! יצרתם proxy ל-API והגנתם עליו באמצעות דרישה לכלול בקריאה אסימון גישה תקף מסוג OAuth 2.0.

נושאים קשורים