אישור

אפליקציות מאשרות קריאות ל-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 מנהלים את המשתמשים בחשבונות הלקוח שלהם דרך הארגון או פורטל ההרשמה. למשתמשים בחשבון לקוח יש תפקיד בעלים או אדמין. לשני התפקידים יש גישה זהה ל-API של הלקוח, אבל בעלים יכול לנהל משתמשים אחרים.

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

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

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

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

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

הוראות

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

למידע נוסף על הרשאה, אפשר לקרוא את המאמר שימוש ב-OAuth 2.0 לגישה ל-Google ממשקי API.

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

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

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

דוגמה להיקף ההרשמה דרך הארגון שבו נעשה שימוש ב-Google API ספריית הלקוח, עיין במדריכים למתחילים של Java , .NET Python. כדי לקבל מידע נוסף על השימוש בהיקפים של Google API, אפשר לקרוא את המאמר שימוש בהיקפים של 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 או אמצעים פרטיים אחרים מידע לפני הפיכת הקוד לזמין לציבור.