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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

מה תלמדו

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

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

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

ב-OAuth, פרטי אבטחה (כמו שם משתמש/סיסמה או מפתח/סוד) מוחלפים בטוקן גישה. לדוגמה:

‫joe:joes_password (username:password) או
‫Nf2moHOASMJeUmXVdDhlMbPaXm2U7eMc:unUOXYpPe74ZfLEb (key:secret)

הופך למשהו כזה:

b0uiYwjRZLEo4lEu7ky2GGxHkanN

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

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

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

  • שולחים קריאה ל-proxy ל-API 1 כדי ליצור אסימון גישה מסוג OAuth מפרטי הכניסה של הלקוח. מדיניות OAuth v2.0 ב-proxy ל-API מטפלת בזה.
  • שליחת קריאה ל-proxy ל-API 2 כדי לשלוח את טוקן הגישה של OAuth בקריאה ל-API. פרוקסי ה-API מאמת את אסימון הגישה באמצעות מדיניות OAuth v2.0.

הדרישות

  • חשבון Apigee Edge. אם עדיין אין לכם חשבון, תוכלו להירשם באמצעות ההוראות שבמאמר יצירת חשבון Apigee Edge.
  • cURL מותקן במחשב כדי לבצע קריאות ל-API משורת הפקודה.

הורדה ופריסה של proxy ל-API ליצירת טוקנים

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

  1. מורידים את קובץ ה-ZIP של proxy ל-API לדוגמה oauth לכל ספרייה במערכת הקבצים.
  2. עוברים אל https://apigee.com/edge ונכנסים לחשבון.
  3. בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
  4. לוחצים על + שרת proxy.
    כפתור ליצירת שרת proxy
  5. באשף Create Proxy (יצירת שרת proxy), לוחצים על Upload proxy bundle (העלאת חבילת שרת proxy).
  6. בוחרים את קובץ oauth.zip שהורדתם ולוחצים על הבא.
  7. לוחצים על יצירה.
  8. אחרי שהבנייה מסתיימת, לוחצים על Edit proxy כדי לראות את ה-proxy ל-API החדש בכלי לעריכת proxy של API.
  9. בדף Overview (סקירה כללית) של הכלי לעריכת API Proxy, לוחצים על התפריט הנפתח Deployment (פריסה) ובוחרים באפשרות test (בדיקה). זו סביבת הבדיקה בארגון שלכם.

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

כל הכבוד! הורדתם ופרסתם בהצלחה פרוקסי של API ליצירת טוקן גישה בארגון Edge.

הצגת תהליך ה-OAuth והמדיניות

בואו נבחן מקרוב את מה שכלול ב-proxy ל-API.

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

  2. לוחצים על AccessTokenClientCredential בקטע Proxy Endpoints.

    בתצוגת קוד ה-XML, יופיע Flow בשם 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, ופועל ה-request הוא POST, אז תופעל מדיניות GenerateAccessTokenClient, שמייצרת את אסימון הגישה.

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

    הגדרת ה-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 millseconds, 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 <GrantType> שצפוי לשמש הוא client_credentials (החלפת טוקן צרכן וסוד באסימון OAuth).
    • רכיב <GrantType> השני מציין למדיניות איפה לחפש בקריאה ל-API את הפרמטר של סוג ההרשאה, כנדרש במפרט OAuth 2.0. (הפרטים האלה יופיעו בהמשך בקריאה ל-API). אפשר גם לשלוח את סוג ההרשאה בכותרת ה-HTTP (request.header.grant_type) או כפרמטר של טופס (request.formparam.grant_type).

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

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

יצירת proxy ל-API שמוגן באמצעות OAuth

מידע על 'mocktarget'

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

http://mocktarget.apigee.net/ip

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

אפשר גם להיכנס לכתובת http://mocktarget.apigee.net/help כדי לראות משאבי API אחרים שזמינים ב-mocktarget.

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

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

  1. בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
  2. לוחצים על + שרת proxy.
    כפתור ליצירת שרת proxy
  3. באשף Build a Proxy (יצירת שרת proxy), בוחרים באפשרות Reverse proxy (most common) (שרת proxy הפוך (הנפוץ ביותר)), ולוחצים על Next (הבא).
  4. מגדירים את ה-Proxy עם הפרטים הבאים:
    בשדה הזה do this
    שם שרת ה-Proxy מזינים: helloworld_oauth2
    Project Base Path

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

    נתיב הבסיס של הפרויקט הוא חלק מכתובת ה-URL שמשמשת לשליחת בקשות לשרת ה-proxy של ה-API.
    API קיים

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

    ההגדרה הזו מגדירה את כתובת ה-URL של היעד ש-Apigee Edge מפעיל בבקשה לשרת ה-proxy של ה-API.
    תיאור מזינים: hello world protected by OAuth
  5. לוחצים על הבא.
  6. בדף Common policies:
    בשדה הזה do this
    אבטחה: הרשאה בוחרים באפשרות OAuth 2.0.
  7. לוחצים על הבא.
  8. בדף Virtual Hosts, לוחצים על Next.
  9. בדף Build, מוודאים שסביבת test נבחרה ולוחצים על Create and Deploy.
  10. בדף סיכום מוצגת הודעה שה-proxy ל-API החדש נוצר בהצלחה, ושה-proxy ל-API נפרס בסביבת הבדיקה.
  11. לוחצים על Edit proxy (עריכת ה-proxy) כדי להציג את הדף Overview (סקירה כללית) של ה-proxy ל-API.
    שימו לב: הפעם ה-proxy ל-API נפרס אוטומטית. לוחצים על התפריט הנפתח Deployment (פריסה) כדי לוודא שיש נקודת פריסה ירוקה לצד סביבת ה-test (בדיקה).

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

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

  1. בכלי לעריכת proxy ל-API, לוחצים על הכרטיסייה פיתוח. אפשר לראות ששתי מדיניות נוספו לזרימת הבקשות של ה-API proxy:
    • ‫Verify OAuth v2.0 Access Token – בודק את הקריאה ל-API כדי לוודא שיש אסימון OAuth תקף.
    • ‫Remove Header Authorization – מדיניות AssignMessage שמסירה את אסימון הגישה אחרי שהוא נבדק, כדי שהוא לא יועבר לשירות היעד. (אם שירות היעד היה צריך את טוקן הגישה של OAuth, לא הייתם משתמשים במדיניות הזו).

  2. לוחצים על הסמל Verify OAuth v2.0 Access Token בתצוגת התהליך ומסתכלים על ה-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 תקין בבקשה.

הוספת מוצר API

כדי להוסיף מוצר API באמצעות ממשק המשתמש של Apigee:

  1. בוחרים באפשרות פרסום > מוצרי API.
  2. לוחצים על +API product.
  3. מזינים את פרטי המוצר של מוצר ה-API.
    שדה תיאור
    שם השם הפנימי של מוצר ה-API. אל תציינו תווים מיוחדים בשם.
    הערה: אי אפשר לערוך את השם אחרי שיוצרים את מוצר ה-API. לדוגמה, helloworld_oauth2-Product
    השם המוצג השם המוצג של מוצר ה-API. השם המוצג משמש בממשק המשתמש, ואפשר לערוך אותו בכל שלב. אם לא מציינים ערך, המערכת משתמשת בערך של המאפיין Name. השדה הזה מתמלא אוטומטית לפי הערך בשדה 'שם'. אפשר לערוך או למחוק את התוכן שלו. השם המוצג יכול לכלול תווים מיוחדים. לדוגמה, helloworld_oauth2-Product.
    תיאור תיאור של מוצר ה-API.
    סביבה סביבות שמוצר ה-API יאפשר גישה אליהן. בוחרים את הסביבה שבה פרסתם את proxy ל-API. לדוגמה, test.
    גישה בוחרים באפשרות ציבורי.
    אישור אוטומטי של בקשות גישה הפעלת אישור אוטומטי של בקשות למפתחות למוצר ה-API הזה מכל אפליקציה.
    מכסה אפשר להתעלם מההודעה הזו במדריך הזה.
    היקפי הרשאות מותרים של OAuth אפשר להתעלם מההודעה הזו במדריך הזה.
  4. בשדה API proxies, בוחרים את שרת ה-proxy ל-API שיצרתם.
  5. בשדה נתיב מזינים '/'. מתעלמים מהשדות האחרים.
  6. לוחצים על שמירה.

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

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

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

יצירת מפתח

ניצור מפתח בשם Nigel Tufnel.

  1. בתפריט, בוחרים באפשרות פרסום > מפתחים.
  2. לוחצים על + Developer (מפתח).
  3. מזינים את הפרטים הבאים בחלון New Developer (מפתח חדש):
    בשדה הזה Enter
    שם פרטי Nigel
    שם משפחה Tufnel
    שם משתמש nigel
    אימייל nigel@example.com
  4. לוחצים על יצירה.

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

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

  1. בוחרים באפשרות פרסום > אפליקציות.
  2. לוחצים על + App (הוספת אפליקציה).
  3. מזינים את הפרטים הבאים בחלון New App (אפליקציה חדשה):
    בשדה הזה do this
    שם ושם לתצוגה מזינים: nigel_app
    מפתח לוחצים על Developer (מפתח) ובוחרים באחת מהאפשרויות הבאות: Nigel Tufnel (nigel@example.com)
    כתובת URL להתקשרות חזרה והערות להשאיר ריק
  4. בקטע מוצרים, לוחצים על הוספת מוצר.
  5. בוחרים באפשרות helloworld_oauth2-Product.
  6. לוחצים על יצירה.

קבלת טוקן צרכן וסוד לשימוש עם טוקן צרכן

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

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

  2. בדף nigel_app, לוחצים על Show בעמודות Key ו-Secret. שימו לב שהמפתח והסוד משויכים ל-helloworld_oauth2-Product שנוצר אוטומטית קודם לכן.

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

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

רק בשביל הכיף, נסו לקרוא ל-proxy ל-API המוגן שאמור להחזיר את כתובת ה-IP שלכם. מריצים את פקודת cURL הבאה בחלון מסוף, ומחליפים את שם הארגון שלכם ב-Edge. המילה test בכתובת ה-URL היא סביבת הבדיקה של הארגון, זו שפרסתם בה את שרתי ה-proxy. נתיב הבסיס של ה-proxy הוא /hellooauth2, אותו נתיב בסיס שציינתם כשנוצר ה-proxy. שימו לב שלא מועבר אסימון גישה של OAuth בקריאה.

curl https://ORG_NAME-test.apigee.net/hellooauth2

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

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

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

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

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

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

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
"https://ORG_NAME-test.apigee.net/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. מעתיקים את הערך של access_token (ללא המירכאות) ומדביקים אותו בקובץ הטקסט. תשתמשו בו עוד מעט.

מה קרה עכשיו?

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

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

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

curl https://ORG_NAME-test.apigee.net/hellooauth2 -H "Authorization: Bearer TOKEN"

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

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

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

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

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