תהליך אימות #

בקשות ל-API מאובטחות באמצעות אסימון גישה של JWT. יש ליצור את האסימון באמצעות זרימת האישור של קוד הרשות OAuth v2.

התמונה למטה מספקת מתווה של התהליך הנדרש ליצירת האסימונים הנדרשים ולשמירתם בחיים:

אנא עיינו בקישורים למטה למידע טכני מפורט ודוגמאות קוד לזרימת הענקת קוד ההרשאה:

• הענקת קוד הרשאה
• זרימה לדוגמה

כדי להתקדם בשלבים הבאים, תצטרכו:

• ה-Request_URL, Client_ID & Client_Secret (אלו יסופקו לך כאשר תבקש API access)
• כניסת משתמש ל-~.Dimensions.~ פורטל משווק לאישור ההרשאה.

tip
אם יש לכם בעיות בכל שלב וזקוקים לעזרה, אנא צרו קשר בטלפון [email protected] או התקשרו אלינו בטלפון (+1) 480 207 7920.

1. בקשת אישור #

השלב הראשון הוא לבקש אישור. בנו URL המכיל את הפריטים הבאים:

• Client_Id: ה-client_id מסופק כאשר מבקשים לראשונה גישה API.
• Response_Type: השתמש ב"קוד".
• State: ספק מצב שניתן להשתמש בו לזיהוי ההפניה
• Redirect_URI: זה קובע את ההפניה URL שמשמש לאחר הנפקת טוקן. ברירת המחדל היא https://127.0.0.1:8000.
• Scope: זוהי רשימת הסקופים שצריך לספק בעת בקשת טוקן. יש להגדיר זאת כ-"openid offline_access inboarding".

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

ההפניה URL הייתה אמורה לקבל כעת 'קוד אישור' שניתן להשתמש בו בשלב 2.

בקשה לדוגמה

 
\/connect/authorize?client_id=987654&response_type=code&state=5ca75bd30&redirect_uri=https%3A%2F%2Fexample.com%2Fauth&scope=open%20id%20offline_access%20onboarding

2. בקשת גישה ורענון אסימונים #

כעת יש להחליף את 'קוד האימות' לטוקנים של גישה ורענון - https://login.eu.xarios.cloud/connect/token.

• Access Token, משמש לגישה לתכונות API ולביצוע בקשות קליטה.
• Refresh Token, המשמש ליצירת אסימוני גישה מתמשכים

ניתן לעשות זאת על ידי ביצוע בקשת POST לשרת ההרשאות המכיל את הפריטים הבאים:

• Code: קוד האימות שנאסף בשלב 1.
• Grant_Type: מוגדר על authorization_code. (בהתאם למפרט https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type).
• Client_Id: ה-client_id מסופק כאשר מבקשים לראשונה גישה API.
• Client_Secret: ה-client_secret מסופק כאשר מבקשים לראשונה גישה API.
• Redirect_URI: זה קובע את ההפניה URL שמשמש לאחר הנפקת טוקן. ברירת המחדל היא https://127.0.0.1:8000.

בקשה לדוגמה

 
פוסט /connect/token HTTP/1.1
סוג תוכן: application/x-www-form-urlencoded
אורך תוכן: xx
code=98765&grant_type=code&client_id=123456&client_secret=987654321&redirect_uri=https%3A%2f%2fexample.com%2fauth

שרת האימות מאשר את הבקשה ומגיב עם אסימון גישה ואסימון רענון:

דוגמה לתגובה

 
{\
  "access_token": "AYjcyMzY3ZDhiNmJkNTY",\
  "refresh_token": "RjY2NjM5NzA2OWJjuE7c",\
  "token_type": "נושא",\
  "פג תוקף": 5400\
}\

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

למידע על השימוש ב-API, יש לעיין ב-API Reference.

3. רענון אסימון הגישה #

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

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

ניתן לעשות זאת על ידי ביצוע בקשת POST לשרת ההרשאה המכיל את הפריטים הבאים (זה זהה לשלב 2 אך משתמש ב-Refresh Token במקום Auth Code):

• Refresh_Token: אוסף refresh_token המאוחסן בשלב 2.
• Grant_Type: השתמש ב"refresh_token".
• Client_Id: ה-client_id מסופק כאשר מבקשים לראשונה גישה API.
• Client_Secret: ה-client_secret מסופק כאשר מבקשים לראשונה גישה API.

בקשה לדוגמה

 
פוסט /connect/token HTTP/1.1
סוג תוכן: application/x-www-form-urlencoded
אורך תוכן: xx
refresh_token=RjY2NjM5NzA2OWJjuE7c&grant_type=refresh_token&client_id=123456&client_secret=987654321

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

warning
אסימוני רענון יפוגו אם לא משתמשים בהם למשך תקופה של 90 יום. זמן התפוגה ימשיך להיות מאופס ל-90 יום בכל פעם שמשתמשים באסימון הרענון.

ביטול אסימונים #

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