אישור

אפליקציות מאשרות קריאות ל-Customer API בהרשמה דרך הארגון באמצעות OAuth. מסמך זה מסביר את ההרשאה של ה-API עבור ספקים לניהול ניידות ארגונית (EMM) ומפתחי IT לארגונים. אחרי קריאת המסמך הזה, תוכלו להבין איך לאשר בקשות API באפליקציה ולהסביר למשתמשים באפליקציה את דרישות החשבון.

מדריך למתחילים בנושא הרשאות

  • הגדרת פרויקט ב-Google Cloud Platform באמצעות ממשק ה-API להרשמה דרך הארגון ואת סודות הלקוח ב-OAuth, מריצים את האשף הזה.
  • מריצים את הקוד לדוגמה במדריך למתחילים בשפות Java,‏ ‎.NET או Python. שימוש בספריות הלקוח של Google API כדי לתמוך בשפות שונות.

סקירה כללית

הקשר בין המכשיר למשאב הלקוח

  1. אחד או יותר מאדמינים ב-IT הם משתמשים בחשבון לקוח בהרשמה דרך הארגון.
  2. אדמינים ב-IT משתמשים בחשבון Google כדי לאמת את עצמם.
  3. בקשות API מעבירות אסימון OAuth2 כדי לאשר בקשות API מטעם אדמין ב-IT.

חשבונות של לקוחות

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

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

הדוגמה הבאה מראה איך לאחזר את חשבונות הלקוח של המשתמש מאשרת את הקריאה ל-API:

Java

AndroidProvisioningPartner.Customers.List accountRequest = service.customers().list();
accountRequest.setPageSize(100);
CustomerListCustomersResponse accountResponse = accountRequest.execute();

List<Company> customers = accountResponse.getCustomers();
if (customers == null || customers.isEmpty()) {
    // No accounts found for the user. Confirm the Google Account
    // that authorizes the request can access the zero-touch portal.
    System.out.println("No zero-touch enrollment account found.");
} else {
    // Print the customers in this page.
    for (Company customer : customers) {
        System.out.format("%s\tcustomers/%d\n",
              customer.getCompanyName(), customer.getCompanyId());
    }
}

‎.NET

CustomersResource.ListRequest accountRequest = service.Customers.List();
accountRequest.PageSize = 100;
CustomerListCustomersResponse accountResponse = accountRequest.Execute();
IList<Company> customers = accountResponse.Customers ?? new List<Company>();
if (customers.Count == 0)
{
    // No accounts found for the user. Confirm the Google Account
    // that authorizes the request can access the zero-touch portal.
    Console.WriteLine("No zero-touch enrollment account found.");
}
foreach (Company customer in customers)
{
    Console.WriteLine("{0}\tcustomers/{1}",
                      customer.CompanyName,
                      customer.CompanyId);
}

Python

response = service.customers().list(pageSize=100).execute()
if 'customers' not in response:
  # No accounts found for the user. Confirm the Google Account
  # that authorizes the request can access the zero-touch portal.
  print('No zero-touch enrollment account found.')
  response['customers'] = []

for customer in response['customers']:
  print('{0}\tcustomers/{1}'.format(
      customer['companyName'], customer['companyId']))

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

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

משתמשים

האדמינים ב-IT נותנים הרשאה לבקשות ה-API שהאפליקציה שולחת בשמם. שפת תרגום הרשאה של בקשות API, המשתמש באפליקציה שלך צריך לבצע את הפעולות הבאות:

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

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

ניהול משתמשים

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

אישור התנאים וההגבלות

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

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

הוספת הרשאה לאפליקציה

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

הוראות

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

מידע נוסף על הרשאות זמין במאמר שימוש ב-OAuth 2.0 כדי לגשת ל-Google APIs.

היקפי ההרשאות

שימוש בהיקף ההרשאה של ה-API https://www.googleapis.com/auth/androidworkzerotouchemm באפליקציה שלך כדי לבקש אסימון גישה מסוג OAuth 2.0.

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

דוגמה להיקף ההרשמה דרך הארגון שבו נעשה שימוש ב-Google API ספריית הלקוח, עיין במדריכים למתחילים של Java , .NET Python. מידע נוסף על השימוש בהיקפי הרשאות של Google API זמין במאמר שימוש ב-OAuth 2.0 לגישה ל-Google APIs.

שיטות מומלצות לשימוש במפתחות API

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

לא להטמיע מפתחות API ישירות בקוד
מפתחות API שמוטמעים בקוד עלולים להיחשף בטעות ציבורי – לדוגמה, אם שכחתם להסיר את המפתחות מקוד לשתף. במקום להטמיע את מפתחות ה-API באפליקציות שלכם, אחסנו אותם משתני סביבה או בקבצים מחוץ למקור של האפליקציה עץ.
לא לאחסן מפתחות API בקבצים בעץ המקור של האפליקציה
אם מאחסנים מפתחות API בקבצים, צריך לשמור את הקבצים מחוץ לאפליקציה עץ מקור כדי להבטיח שהמפתחות שלך לא יגיעו לבקרת קוד המקור המערכת. זו המלצה חשובה במיוחד למי שמשתמש במערכת ציבורית לניהול קוד מקור, כמו GitHub.
הגבלת השימוש במפתחות API רק לכתובות IP, כתובות URL מפנות ואפליקציות לנייד שזקוקות להם
על ידי הגבלת כתובות ה-IP, כתובות ה-URL המפנות ואפליקציות לנייד שיכולות באמצעות כל מפתח, אפשר לצמצם את ההשפעה של מפתח API שנמצא בסיכון. אפשר לציין את המארחים והאפליקציות שיוכלו להשתמש בכל מפתח מGoogle API Console פותחים את הדף 'פרטי כניסה' ואז יוצרים ממשק API חדש מקש עם ההגדרות הרצויות, או עריכת ההגדרות של API מקש.
מחיקת מפתחות API שלא נחוצים
כדי לצמצם את החשיפה שלך למתקפות, עליך למחוק מפתחות API שלא בדקת צריכים יותר.
מדי פעם ליצור מחדש את מפתחות ה-API
כדי ליצור מחדש מפתחות API דרך Google API Console, צריך לפתוח את הדף 'פרטי כניסה', בוחרים מפתח API ולוחצים על יצירה מחדש לכל מקש. לאחר מכן מעדכנים את האפליקציות כך שישתמשו מקשי קיצור. המפתחות הישנים ימשיכו לפעול למשך 24 שעות לאחר היצירה מפתחות חלופיים.
לבדוק את הקוד לפני שמפיצים אותו באופן ציבורי
לפני שהקוד הופך לזמין לציבור, חשוב לוודא שהוא לא מכיל מפתחות API או מידע פרטי אחר.