अनुमति देना

ऐप्लिकेशन, OAuth का इस्तेमाल करके, 'पहले से तैयार डिवाइस' सुविधा के ग्राहक एपीआई को कॉल करने की अनुमति देते हैं. यह दस्तावेज़, एंटरप्राइज़ मोबिलिटी मैनेजमेंट (ईएमएम) सेवा देने वालों और एंटरप्राइज़ आईटी डेवलपर के लिए, एपीआई को मिलने वाली अनुमति के बारे में बताता है. इस दस्तावेज़ को पढ़ने के बाद, आपको पता चल जाएगा कि अपने ऐप्लिकेशन में एपीआई अनुरोधों को कैसे अनुमति दी जा सकती है. साथ ही, अपने ऐप्लिकेशन का इस्तेमाल करने वालों को खाते की ज़रूरी शर्तों के बारे में भी बताया जा सकता है.

अनुमति देने के लिए क्विकस्टार्ट

  • पहले से तैयार डिवाइस एपीआई और OAuth क्लाइंट सीक्रेट के साथ Google Cloud Platform प्रोजेक्ट सेट अप करने के लिए, यह विज़र्ड चलाएं.
  • Java, .NET या Python के लिए क्विकस्टार्ट सैंपल कोड बनाएं. दूसरी भाषाओं में काम करने के लिए Google की एपीआई क्लाइंट लाइब्रेरी का इस्तेमाल करें.

खास जानकारी

डिवाइस और ग्राहक संसाधन संबंध

  1. एक या एक से ज़्यादा आईटी एडमिन, 'पहले से तैयार डिवाइस' सुविधा वाले ग्राहक खाते के उपयोगकर्ता होते हैं.
  2. आईटी एडमिन खुद की पुष्टि करने के लिए Google खाते का इस्तेमाल करते हैं.
  3. आईटी एडमिन की तरफ़ से एपीआई अनुरोधों को अनुमति देने के लिए, एपीआई अनुरोध एक OAuth2 टोकन पास करते हैं.

ग्राहक खाते

किसी संगठन के कॉन्फ़िगरेशन, डिवाइस, और (आईटी एडमिन) के उपयोगकर्ता, ग्राहक खाते से जुड़े होते हैं. ग्राहक खाता, ग्रुप की तरह ही होता है. यह अलग-अलग उपयोगकर्ता नहीं होता. रीसेलर, ग्राहक को तब सेट अप करता है, जब संगठन पहली बार 'पहले से तैयार डिवाइस' सुविधा के लिए डिवाइस खरीदता है. आईटी एडमिन, 'पहले से तैयार डिवाइस' सुविधा वाले पोर्टल का इस्तेमाल करके, अपने संगठन के अन्य उपयोगकर्ताओं को मैनेज करते हैं.

खातों की पहचान करने के लिए, एपीआई संख्या वाली ग्राहक आईडी का इस्तेमाल करता है. एपीआई के तरीकों को कॉल करते समय, यूआरएल पाथ के हिस्से के तौर पर ग्राहक आईडी पास किया जाता है. किसी भी 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 खातों को प्रिंट करता है. ऐसा करने का तरीका जानने के लिए, पेज वाले नतीजे पढ़ें.

किसी संगठन में आम तौर पर एक ग्राहक खाता होता है, लेकिन बड़े संगठन हर डिवीज़न के लिए अलग-अलग ग्राहक खातों का इस्तेमाल कर सकते हैं. आईटी एडमिन अलग-अलग ग्राहक खातों का सदस्य हो सकता है. इसलिए, आपके ऐप्लिकेशन से उपयोगकर्ताओं को नए ग्राहक खाते खोजने और उनका इस्तेमाल करने में मदद मिलनी चाहिए. अपने ऐप्लिकेशन में, हर ग्राहक खाते को लेबल करने के लिए, companyName वैल्यू का इस्तेमाल करें.

उपयोगकर्ता

आईटी एडमिन उस एपीआई के अनुरोध को अनुमति देते हैं जो आपका ऐप्लिकेशन उनकी ओर से भेजता है. एपीआई अनुरोधों को अनुमति देने के लिए, आपके ऐप्लिकेशन के उपयोगकर्ता को ये काम करने होंगे:

  1. आपके ईमेल पते के साथ Google खाता जोड़ें.
  2. उसी ईमेल पते का इस्तेमाल करके, किसी ग्राहक खाते से जुड़ें.
  3. 'पहले से तैयार डिवाइस' सुविधा के तहत रजिस्टर करने वाले ग्राहक के लिए सेवा की शर्तें (सेवा की शर्तें) स्वीकार करें.

आपके ऐप्लिकेशन के उपयोगकर्ताओं को सेट अप करने में मदद करने के लिए, शुरू करें में दिए गए आईटी एडमिन के लिए दिए गए हमारे दिशा-निर्देशों का फिर से इस्तेमाल करें और अपने दस्तावेज़ में Google खाता जोड़ें लेख में बताया गया तरीका अपनाएं.

यूज़र मैनेजमेंट

'पहले से तैयार डिवाइस' सुविधा वाले रजिस्ट्रेशन पोर्टल में, आईटी एडमिन अपने ग्राहक खातों के लिए उपयोगकर्ताओं को मैनेज करते हैं. ग्राहक खाते में मौजूद उपयोगकर्ताओं की भूमिका मालिक या एडमिन की होती है. दोनों भूमिकाओं में ग्राहक एपीआई का एक जैसा ऐक्सेस होता है, लेकिन मालिक दूसरे उपयोगकर्ताओं को मैनेज कर सकता है.

सेवा की शर्तों को स्वीकार करना

आपके ऐप्लिकेशन के उपयोगकर्ताओं को एपीआई कॉल की अनुमति देने से पहले, नई सेवा की शर्तों को स्वीकार करना होगा. ऐसा तब होता है, जब आईटी एडमिन पहली बार 'पहले से तैयार डिवाइस' सुविधा का इस्तेमाल करते हैं या जब हम सेवा की शर्तों को अपडेट करते हैं. जब कोई उपयोगकर्ता सेवा की नई शर्तों को स्वीकार नहीं करता है, तो एपीआई एक एचटीटीपी 403 Forbidden स्टेटस कोड दिखाता है और रिस्पॉन्स के मुख्य हिस्से में एक TosError शामिल होता है.

साइन इन करने पर पोर्टल, उपयोगकर्ताओं को सेवा की नई शर्तों को स्वीकार करने का अनुरोध अपने-आप देता है. आपके ऐप्लिकेशन में सुझाए गए तरीके देखने के लिए, ईएमएम इंटिग्रेशन गाइड में मौजूद सेवा की शर्तें मैनेज करें पढ़ें.

अपने ऐप्लिकेशन के लिए अनुमति जोड़ना

आपका ऐप्लिकेशन, ग्राहक एपीआई को जो भी अनुरोध भेजता है उसमें एक ऑथराइज़ेशन टोकन शामिल होना चाहिए. इस टोकन से Google आपके ऐप्लिकेशन की पहचान भी करता है. ग्राहक एपीआई, उपयोगकर्ता के डेटा को ऐक्सेस करता है, इसलिए डेटा के मालिक से अनुमति लेनी होगी. आपका ऐप्लिकेशन OAuth 2.0 प्रोटोकॉल का इस्तेमाल करके, आईटी एडमिन को एपीआई ऐक्सेस करने की अनुमति देता है.

निर्देश

हम Java, .NET, और Python ऐप्लिकेशन के लिए क्विकस्टार्ट गाइड उपलब्ध कराते हैं. अगर किसी दूसरी भाषा का इस्तेमाल किया जा रहा है, तो अपने ऐप्लिकेशन के लिए अनुमति सेट अप करने के लिए नीचे दिया गया तरीका अपनाएं.

अनुमति देने के बारे में ज़्यादा जानने के लिए, Google API ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

अनुमति देने के दायरे

OAuth 2.0 ऐक्सेस टोकन का अनुरोध करने के लिए, अपने ऐप्लिकेशन में एपीआई की अनुमति के स्कोप https://www.googleapis.com/auth/androidworkzerotouchemm का इस्तेमाल करें.

स्कोप पैरामीटर उन संसाधनों और कार्रवाइयों के सेट को कंट्रोल करता है जिन्हें ऐक्सेस टोकन, कॉल की अनुमति देता है. ऐक्सेस टोकन सिर्फ़ उन कार्रवाइयों और संसाधनों के लिए मान्य होते हैं जिनकी जानकारी टोकन के अनुरोध में दी गई है. इस एपीआई में, ऊपर बताए गए सिंगल-टच रजिस्ट्रेशन दायरे वाले सभी तरीकों और संसाधनों को शामिल किया गया है.

Google API क्लाइंट लाइब्रेरी के साथ इस्तेमाल किए जाने वाले 'पहले से तैयार डिवाइस' के दायरे के उदाहरण के लिए, Java, .NET, और Python के क्विकस्टार्ट देखें. Google API के स्कोप का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Google API ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

एपीआई पासकोड के लिए सबसे सही तरीके

अपने ऐप्लिकेशन में एपीआई कुंजियों का इस्तेमाल करते समय, उन्हें सुरक्षित रखें. सार्वजनिक रूप से अपने क्रेडेंशियल दिखाने से आपके खाते के साथ छेड़छाड़ की जा सकती है जिससे आपके खाते पर अनपेक्षित शुल्क लागू हो सकते हैं. अपनी एपीआई कुंजियों को सुरक्षित रखने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं:

एपीआई कुंजियों को सीधे कोड में एम्बेड न करें
कोड में जोड़ी गई एपीआई कुंजियां, गलती से सार्वजनिक तौर पर सार्वजनिक हो सकती हैं. उदाहरण के लिए, अपने शेयर किए गए कोड से कुंजियों को हटाना भूल जाने पर. अपने ऐप्लिकेशन में एपीआई कुंजियां एम्बेड करने के बजाय, उन्हें एनवायरमेंट वैरिएबल या अपने ऐप्लिकेशन के सोर्स ट्री के बाहर की फ़ाइलों में सेव करें.
अपने ऐप्लिकेशन के सोर्स ट्री में मौजूद फ़ाइलों में एपीआई पासकोड सेव न करें
अगर आपकी फ़ाइलों में एपीआई कुंजियां सेव की जाती हैं, तो फ़ाइलों को ऐप्लिकेशन के सोर्स ट्री के बाहर रखें. इससे, यह पक्का करने में मदद मिलेगी कि पासकोड आपके सोर्स कोड कंट्रोल सिस्टम पर न जाएं. यह तब अहम होता है, जब GitHub जैसे पब्लिक सोर्स कोड मैनेजमेंट सिस्टम का इस्तेमाल किया जाता है.
अपनी एपीआई कुंजियों को सिर्फ़ ऐसे आईपी पतों, रेफ़रल देने वाले यूआरएल, और मोबाइल ऐप्लिकेशन को इस्तेमाल करने से रोकें जिन्हें इनकी ज़रूरत है
हर कुंजी का इस्तेमाल करने वाले आईपी पतों, रेफ़रल देने वाले यूआरएल, और मोबाइल ऐप्लिकेशन पर पाबंदी लगाकर, छेड़छाड़ की गई एपीआई पासकोड के असर को कम किया जा सकता है. आपके पास उन होस्ट और ऐप्लिकेशन की जानकारी देने का विकल्प होता है जो Google API कंसोल से, हर कुंजी का इस्तेमाल कर सकते हैं. इसके लिए, क्रेडेंशियल पेज खोलें. इसके बाद, अपनी पसंद की सेटिंग के हिसाब से नई एपीआई कुंजी बनाएं या किसी एपीआई कुंजी की सेटिंग में बदलाव करें.
ग़ैर-ज़रूरी एपीआई कुंजियां मिटाना
अटैक के खतरे को कम करने के लिए, उन सभी एपीआई कुंजियों को मिटा दें जिनकी अब आपको ज़रूरत नहीं है.
समय-समय पर अपनी एपीआई कुंजियां फिर से जनरेट करें
Google API कंसोल से एपीआई कुंजियां फिर से जनरेट की जा सकती हैं. इसके लिए, क्रेडेंशियल पेज खोलें, कोई एपीआई पासकोड चुनें, और हर कुंजी के लिए फिर से कुंजी जनरेट करें पर क्लिक करें. इसके बाद, जनरेट की गई नई कुंजियों का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन अपडेट करें. रीप्लेसमेंट कुंजियां जनरेट करने के बाद, आपकी पुरानी कुंजियां 24 घंटे तक काम करती रहेंगी.
अपने कोड को सार्वजनिक तौर पर रिलीज़ करने से पहले उसकी समीक्षा करें
अपना कोड सार्वजनिक रूप से उपलब्ध कराने से पहले, पक्का करें कि आपके कोड में एपीआई कुंजियां या कोई दूसरी निजी जानकारी न हो.