सर्वर से सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का उपयोग करना

<0x ज़्यादा जानकारी के लिए, Google Cloud के दस्तावेज़ में पुष्टि करने की खास जानकारी देखें.

Google का OAuth 2.0 सिस्टम, सर्वर-टू-सर्वर इंटरैक्शन के साथ काम करता है. जैसे, वेब ऐप्लिकेशन और Google की किसी सेवा के बीच होने वाले इंटरैक्शन. इस स्थिति में, आपको सेवा खाते की ज़रूरत होगी. यह खाता, किसी असली उपयोगकर्ता के बजाय आपके ऐप्लिकेशन का होता है. आपका ऐप्लिकेशन, सेवा खाते की ओर से Google API को कॉल करता है. इसलिए, इसमें उपयोगकर्ता सीधे तौर पर शामिल नहीं होते. इस स्थिति को कभी-कभी "टू-लेग्ड OAuth" या "2LO" कहा जाता है. (इससे जुड़ा शब्द "तीन चरणों वाला OAuth" उन स्थितियों के बारे में बताता है जिनमें आपका ऐप्लिकेशन, असली उपयोगकर्ताओं की ओर से Google API को कॉल करता है. साथ ही, इनमें उपयोगकर्ता की सहमति कभी-कभी ज़रूरी होती है.)

ज़्यादा जानकारी के लिए, सेवा खातों के लिए सबसे सही तरीके देखें.

आम तौर पर, कोई ऐप्लिकेशन सेवा खाते का इस्तेमाल तब करता है, जब उसे Google API का इस्तेमाल करके, किसी उपयोगकर्ता के डेटा के बजाय अपने डेटा के साथ काम करना होता है. उदाहरण के लिए, डेटा को सेव करने के लिए Google Cloud Datastore का इस्तेमाल करने वाला कोई ऐप्लिकेशन, Google Cloud Datastore API को कॉल करने के लिए सेवा खाते का इस्तेमाल करेगा.

Google Workspace डोमेन के एडमिन, सेवा खातों को पूरे डोमेन के लिए अनुमति दे सकते हैं, ताकि वे डोमेन के उपयोगकर्ताओं की ओर से उनका डेटा ऐक्सेस कर सकें.

इस दस्तावेज़ में बताया गया है कि कोई ऐप्लिकेशन, Google APIs की क्लाइंट लाइब्रेरी (सुझाया गया) या एचटीटीपी का इस्तेमाल करके, सर्वर से सर्वर OAuth 2.0 फ़्लो को कैसे पूरा कर सकता है.

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

खास जानकारी

सर्वर से सर्वर के इंटरेक्शन के लिए, सबसे पहले API Consoleमें अपने प्रोजेक्ट के लिए सेवा खाता बनाएं. अगर आपको अपने Google Workspace खाते के उपयोगकर्ताओं का डेटा ऐक्सेस करना है, तो सेवा खाते को पूरे डोमेन का ऐक्सेस सौंपें.

इसके बाद, आपका ऐप्लिकेशन सेवा खाते के क्रेडेंशियल का इस्तेमाल करके, अनुमति वाले एपीआई कॉल करने के लिए तैयार होता है. इसके लिए, वह OAuth 2.0 पुष्टि करने वाले सर्वर से ऐक्सेस टोकन का अनुरोध करता है.

आखिर में, आपका ऐप्लिकेशन Google API को कॉल करने के लिए, ऐक्सेस टोकन का इस्तेमाल कर सकता है.

सुझाव: आपका ऐप्लिकेशन इन टास्क को पूरा कर सकता है. इसके लिए, अपनी भाषा के हिसाब से Google APIs क्लाइंट लाइब्रेरी का इस्तेमाल करें या एचटीटीपी का इस्तेमाल करके, सीधे तौर पर OAuth 2.0 सिस्टम से इंटरैक्ट करें. हालांकि, सर्वर-टू-सर्वर पुष्टि करने के तरीके में, ऐप्लिकेशन को JSON वेब टोकन (JWT) बनाने और उन्हें क्रिप्टोग्राफ़िक तरीके से साइन करने की ज़रूरत होती है. इसलिए, गड़बड़ियों की वजह से गंभीर समस्याएं हो सकती हैं. इनका असर आपके ऐप्लिकेशन की सुरक्षा पर पड़ सकता है.

इसलिए, हमारा सुझाव है कि आप Google APIs client libraries जैसी लाइब्रेरी का इस्तेमाल करें. ये लाइब्रेरी, आपके ऐप्लिकेशन कोड से क्रिप्टोग्राफ़ी को अलग करती हैं.

सेवा खाता बनाना

सेवा खाते के क्रेडेंशियल में, जनरेट किया गया एक ऐसा ईमेल पता शामिल होता है जो यूनीक होता है. साथ ही, इसमें कम से कम एक सार्वजनिक/निजी पासकोड का जोड़ा होता है. अगर डोमेन-वाइड डेलिगेशन की सुविधा चालू है, तो क्लाइंट आईडी भी सेवा खाते के क्रेडेंशियल का हिस्सा होता है.

अगर आपका ऐप्लिकेशन Google App Engine पर चलता है, तो प्रोजेक्ट बनाते समय सेवा खाता अपने-आप सेट अप हो जाता है.

अगर आपका ऐप्लिकेशन Google Compute Engine पर चलता है, तो प्रोजेक्ट बनाते समय सेवा खाता भी अपने-आप सेट अप हो जाता है. हालांकि, Google Compute Engine इंस्टेंस बनाते समय, आपको उन स्कोप के बारे में बताना होगा जिन्हें आपका ऐप्लिकेशन ऐक्सेस कर सकता है. ज़्यादा जानकारी के लिए, सेवा खातों का इस्तेमाल करने के लिए इंस्टेंस तैयार करना लेख पढ़ें.

अगर आपका ऐप्लिकेशन Google App Engine या Google Compute Engine पर नहीं चलता है, तो आपको Google API Consoleमें ये क्रेडेंशियल पाने होंगे. सेवा खाते के क्रेडेंशियल जनरेट करने या पहले से जनरेट किए गए सार्वजनिक क्रेडेंशियल देखने के लिए, यह तरीका अपनाएं:

सबसे पहले, एक सेवा खाता बनाएं:

1. Service accounts pageखोलें.
2. If prompted, select a project, or create a new one.
3.  सेवा खाता बनाएं पर क्लिक करें.
4. सेवा खाते की जानकारी में, सेवा खाते का नाम, आईडी, और जानकारी डालें. इसके बाद, बनाएं और जारी रखें पर क्लिक करें.
5. ज़रूरी नहीं: इस सेवा खाते को प्रोजेक्ट का ऐक्सेस दें में जाकर, सेवा खाते को दी जाने वाली IAM भूमिकाएं चुनें.
6. जारी रखें पर क्लिक करें.
7. ज़रूरी नहीं: उपयोगकर्ताओं को इस सेवा खाते का ऐक्सेस दें में जाकर, उन उपयोगकर्ताओं या ग्रुप को जोड़ें जिन्हें सेवा खाते का इस्तेमाल और उसे मैनेज करने की अनुमति है.
8. हो गया पर क्लिक करें.

इसके बाद, सेवा खाते की कुंजी बनाएं:

1. आपने जिस सेवा खाते को बनाया है उसके ईमेल पते पर क्लिक करें.
2. कुंजियां टैब पर क्लिक करें.
3. कुंजी जोड़ें ड्रॉप-डाउन सूची में, नई कुंजी बनाएं चुनें.
4. बनाएं पर क्लिक करें.

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

ज़्यादा जानने के लिए, सेवा खाते की कुंजियों को मैनेज करने के सबसे सही तरीके देखें.

ईमेल पता, सार्वजनिक पासकोड के फ़िंगरप्रिंट, और अन्य जानकारी देखने के लिए, API Console पर कभी भी वापस जाया जा सकता है. इसके अलावा, सार्वजनिक/निजी पासकोड के अतिरिक्त जोड़े जनरेट करने के लिए भी ऐसा किया जा सकता है. API Consoleमें सेवा खाते के क्रेडेंशियल के बारे में ज़्यादा जानने के लिए, API Consoleकी सहायता फ़ाइल में सेवा खाते देखें.

सेवा खाते के ईमेल पते को नोट करें. साथ ही, सेवा खाते की निजी पासकोड फ़ाइल को किसी ऐसी जगह पर सेव करें जहां से आपका ऐप्लिकेशन इसे ऐक्सेस कर सके. आपके ऐप्लिकेशन को अनुमति वाले एपीआई कॉल करने के लिए इनकी ज़रूरत होती है.

ध्यान दें: आपको डेवलपमेंट और प्रोडक्शन, दोनों एनवायरमेंट में निजी कुंजियों को सुरक्षित तरीके से सेव और मैनेज करना होगा. Google आपकी निजी कुंजियों की कॉपी नहीं रखता. वह सिर्फ़ आपकी सार्वजनिक कुंजियों की कॉपी रखता है. ज़्यादा जानकारी के लिए, OAuth 2.0 की नीतियों में, क्लाइंट क्रेडेंशियल को सुरक्षित तरीके से मैनेज करने से जुड़ा सेक्शन देखें.

सेवा खाते को डोमेन-वाइड अथॉरिटी सौंपना

Google Workspace खाते का इस्तेमाल करके, संगठन का Workspace एडमिन किसी ऐप्लिकेशन को Google Workspace डोमेन में मौजूद उपयोगकर्ताओं की ओर से, Workspace उपयोगकर्ता डेटा ऐक्सेस करने की अनुमति दे सकता है. उदाहरण के लिए, Google Workspace डोमेन में मौजूद सभी उपयोगकर्ताओं के कैलेंडर में इवेंट जोड़ने के लिए, Google Calendar API का इस्तेमाल करने वाला कोई ऐप्लिकेशन, उपयोगकर्ताओं की ओर से Google Calendar API को ऐक्सेस करने के लिए सेवा खाते का इस्तेमाल करेगा. किसी सेवा खाते को डोमेन के उपयोगकर्ताओं की ओर से डेटा ऐक्सेस करने की अनुमति देने को, कभी-कभी सेवा खाते को "डोमेन-वाइड अथॉरिटी सौंपना" कहा जाता है.

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

ध्यान दें: Google Workspace डोमेन से चलने वाले ऐप्लिकेशन में सेवा खातों का इस्तेमाल किया जा सकता है. हालांकि, सेवा खाते आपके Google Workspace खाते के सदस्य नहीं होते हैं. साथ ही, इन पर Google Workspace एडमिन की सेट की गई डोमेन नीतियां लागू नहीं होती हैं. उदाहरण के लिए, Google Workspace Admin console में सेट की गई कोई ऐसी नीति, जो Google Workspace के असली उपयोगकर्ताओं को डोमेन से बाहर दस्तावेज़ शेयर करने से रोकती है, वह सेवा खातों पर लागू नहीं होगी.

किसी सेवा खाते को पूरे डोमेन पर अनुमति देने के लिए, Google Workspace डोमेन के सुपर एडमिन को यह तरीका अपनाना होगा:

1. अपने Google Workspace डोमेन के Admin console में जाकर, मुख्य मेन्यू > सुरक्षा > ऐक्सेस और डेटा कंट्रोल > एपीआई कंट्रोल पर जाएं.
2. पूरे डोमेन के लिए डेटा का ऐक्सेस दें पैनल में, पूरे डोमेन के लिए डेटा का ऐक्सेस मैनेज करें को चुनें.
3. नया जोड़ें पर क्लिक करें.
4. क्लाइंट आईडी फ़ील्ड में, सेवा खाते का क्लाइंट आईडी डालें. आपको अपने सेवा खाते का क्लाइंट आईडी, Service accounts pageमें मिल सकता है.
5. OAuth स्कोप (कॉमा लगाकर अलग किए गए) फ़ील्ड में, उन स्कोप की सूची डालें जिनका ऐक्सेस आपके ऐप्लिकेशन को दिया जाना चाहिए. उदाहरण के लिए, अगर आपके ऐप्लिकेशन को Google Drive API और Google Calendar API के लिए, पूरे डोमेन का पूरा ऐक्सेस चाहिए, तो यह डालें: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
6. अनुमति दें पर क्लिक करें.

अब आपके ऐप्लिकेशन के पास, Workspace डोमेन के उपयोगकर्ताओं के तौर पर एपीआई कॉल करने का अधिकार है. इससे वह उपयोगकर्ताओं की "पहचान चुरा" सकता है. डेलिगेट किए गए इन एपीआई कॉल को करने के लिए, आपको उस उपयोगकर्ता के बारे में साफ़ तौर पर बताना होगा जिसकी पहचान का इस्तेमाल किया जाएगा.

ध्यान दें: क्लाइंट आईडी जोड़ने के बाद, आम तौर पर कुछ मिनटों में ही किसी दूसरे व्यक्ति के तौर पर खाते का ऐक्सेस मिल जाता है. हालांकि, कुछ मामलों में आपके Google खाते के सभी उपयोगकर्ताओं को ऐक्सेस मिलने में 24 घंटे लग सकते हैं.

किसी और को कॉल मैनेज करने का ऐक्सेस देकर एपीआई कॉल करना

यहां दिए गए सेक्शन में, Google APIs क्लाइंट लाइब्रेरी का इस्तेमाल करके या एचटीटीपी का इस्तेमाल करके सीधे तौर पर OAuth 2.0 सिस्टम के साथ इंटरैक्ट करके, अनुमति वाला एपीआई कॉल करने का तरीका बताया गया है.

अहम जानकारी: अगर Google Workspace API का इस्तेमाल किया जा रहा है, तो ज़्यादा जानकारी वाले उदाहरण GitHub पर Google Workspace डेवलपर के सैंपल और Google Workspace डेवलपर प्रॉडक्ट पेज पर उपलब्ध हैं.

Java

API Consoleसे क्लाइंट का ईमेल पता और निजी कुंजी पाने के बाद, Google Auth Library for Java का इस्तेमाल करें. इससे सेवा खाते के क्रेडेंशियल और उन स्कोप से GoogleCredentials ऑब्जेक्ट बनाया जा सकता है जिन्हें आपके ऐप्लिकेशन को ऐक्सेस करने की ज़रूरत है. उदाहरण के लिए:

import com.google.auth.oauth2.GoogleCredentials;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream("ServiceAccountKey.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

अगर Google Cloud पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो इसके बजाय ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल किया जा सकता है. इससे प्रोसेस को आसान बनाया जा सकता है.

पूरे डोमेन के लिए डेटा का ऐक्सेस देना

अगर आपने सेवा खाते को डोमेन-वाइड ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो GoogleCredentials ऑब्जेक्ट की createDelegated विधि का इस्तेमाल करके, उपयोगकर्ता खाते का ईमेल पता डालें. उदाहरण के लिए:

GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream("ServiceAccountKey.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("[e-mail]");

createDelegated() तरीके को कॉल करने के लिए, GoogleCredentials ऑब्जेक्ट का इस्तेमाल किया जाता है. createDelegated() तरीके के लिए, तर्क ऐसा उपयोगकर्ता होना चाहिए जो आपके Workspace खाते से जुड़ा हो. अनुरोध करने वाला आपका कोड, इस क्रेडेंशियल का इस्तेमाल करके Google API को कॉल करेगा. इसके लिए, आपके सेवा खाते का इस्तेमाल किया जाएगा.

Python

API Consoleसे क्लाइंट का ईमेल पता और निजी पासकोड पाने के बाद, Python के लिए Google APIs क्लाइंट लाइब्रेरी का इस्तेमाल करके, यह तरीका अपनाएं:

1. सेवा खाते के क्रेडेंशियल और आपके ऐप्लिकेशन को जिन स्कोप का ऐक्सेस चाहिए उनसे एक Credentials ऑब्जेक्ट बनाएं. उदाहरण के लिए:

   from google.oauth2 import service_account
   
   SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
   SERVICE_ACCOUNT_FILE = '/path/to/ServiceAccountKey.json'
   
   credentials = service_account.Credentials.from_service_account_file(
           SERVICE_ACCOUNT_FILE, scopes=SCOPES)

   अगर Google Cloud पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो इसके बजाय ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल किया जा सकता है. इससे प्रोसेस को आसान बनाया जा सकता है.

2. पूरे डोमेन के लिए डेटा का ऐक्सेस देना

   अगर आपने सेवा खाते को डोमेन-वाइड ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो मौजूदा with_subject ऑब्जेक्ट के with_subject तरीके का इस्तेमाल करें.ServiceAccountCredentials उदाहरण के लिए:

   delegated_credentials = credentials.with_subject('[e-mail]')

अपने ऐप्लिकेशन में Google API को कॉल करने के लिए, क्रेडेंशियल ऑब्जेक्ट का इस्तेमाल करें.

एचटीटीपी/रेस्ट

सुझाव: आपका ऐप्लिकेशन, एचटीटीपी का इस्तेमाल करके OAuth 2.0 सिस्टम के साथ सीधे तौर पर इंटरैक्ट करके इन टास्क को पूरा कर सकता है. हालांकि, सर्वर-टू-सर्वर पुष्टि करने के इंटरैक्शन के लिए, ऐप्लिकेशन को JSON Web Token (JWT) बनाने और उन्हें क्रिप्टोग्राफ़िक तरीके से साइन करने की ज़रूरत होती है. गलतियों की वजह से गंभीर गड़बड़ियां हो सकती हैं. इससे आपके ऐप्लिकेशन की सुरक्षा पर बुरा असर पड़ सकता है.

इसलिए, हमारा सुझाव है कि आप Google APIs जैसी क्लाइंट लाइब्रेरी का इस्तेमाल करें. ये लाइब्रेरी, आपके ऐप्लिकेशन कोड से क्रिप्टोग्राफ़ी को अलग करती हैं.

API Consoleसे क्लाइंट आईडी और निजी कुंजी पाने के बाद, आपके ऐप्लिकेशन को यह तरीका अपनाना होगा:

1. एक JSON Web Token (JWT, जिसे "जॉट" कहा जाता है) बनाएं. इसमें हेडर, दावा सेट, और हस्ताक्षर शामिल हो.
2. Google OAuth 2.0 की मदद से अनुमति देने वाले सर्वर से ऐक्सेस टोकन का अनुरोध करें.
3. ऑथराइज़ेशन सर्वर से मिले JSON रिस्पॉन्स को मैनेज करें.

यहां दिए गए सेक्शन में, इन चरणों को पूरा करने का तरीका बताया गया है.

अगर रिस्पॉन्स में ऐक्सेस टोकन शामिल है, तो Google API को कॉल करने के लिए, ऐक्सेस टोकन का इस्तेमाल किया जा सकता है. (अगर जवाब में ऐक्सेस टोकन शामिल नहीं है, तो हो सकता है कि आपका JWT और टोकन का अनुरोध सही तरीके से न बनाया गया हो. इसके अलावा, यह भी हो सकता है कि सेवा खाते के पास अनुरोध किए गए स्कोप को ऐक्सेस करने की अनुमति न हो.)

ऐक्सेस टोकन के काम न करने पर, आपका ऐप्लिकेशन एक और JWT जनरेट करता है. इसके बाद, वह उस पर हस्ताक्षर करता है और एक और ऐक्सेस टोकन का अनुरोध करता है.

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

इस सेक्शन के बाकी हिस्से में, JWT बनाने, उस पर हस्ताक्षर करने, ऐक्सेस टोकन का अनुरोध करने, और जवाब को मैनेज करने के बारे में बताया गया है.

JWT बनाना

JWT में तीन हिस्से होते हैं: हेडर, दावा सेट, और हस्ताक्षर. हेडर और दावा सेट, JSON ऑब्जेक्ट होते हैं. इन JSON ऑब्जेक्ट को UTF-8 बाइट में बदला जाता है. इसके बाद, Base64url एन्कोडिंग का इस्तेमाल करके कोड में बदला जाता है. इस एन्कोडिंग से, बार-बार एन्कोड करने की कार्रवाइयों की वजह से एन्कोडिंग में होने वाले बदलावों से बचने में मदद मिलती है. हेडर, दावा सेट, और हस्ताक्षर को एक साथ जोड़ा जाता है. इसके लिए, पीरियड (.) वर्ण का इस्तेमाल किया जाता है.

JWT इस तरह बनाया जाता है:

{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}

हस्ताक्षर के लिए बुनियादी स्ट्रिंग इस तरह से होती है:

{Base64url encoded header}.{Base64url encoded claim set}

JWT हेडर बनाना

हेडर में दो ज़रूरी फ़ील्ड होते हैं: हस्ताक्षर करने का एल्गोरिदम और दावे का फ़ॉर्मैट. साथ ही, इसमें एक वैकल्पिक कुंजी आईडी होता है:

• Algorithm एट्रिब्यूट की वैल्यू देना ज़रूरी है. इसकी सिर्फ़ एक वैल्यू होती है: "alg": "RS256".
• फ़ॉर्मैट की जानकारी देना ज़रूरी है. इसकी सिर्फ़ एक वैल्यू होती है: "typ": "JWT".
• कुंजी आईडी देना ज़रूरी नहीं है. यह JWT पर हस्ताक्षर करने के लिए इस्तेमाल की गई सेवा खाते की कुंजी का आईडी होता है. अगर गलत कुंजी आईडी दिया जाता है, तो सेवा खाते से जुड़ी सभी कुंजियों का इस्तेमाल किया जाता है. अगर कोई मान्य कुंजी नहीं मिलती है, तो टोकन अस्वीकार कर दिया जाता है. Google के पास, गलत कुंजी आईडी वाले टोकन अस्वीकार करने का अधिकार है.

सेवा खाते, RSA SHA-256 एल्गोरिदम और JWT टोकन फ़ॉर्मैट पर निर्भर करते हैं. इस वजह से, हेडर का JSON कोड इस तरह दिखता है:

{"alg":"RS256","typ":"JWT", "kid":"370ab79b4513eb9bad7c9bd16a95cb76b5b2a56a"}

इसका Base64url फ़ॉर्मैट यह है:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

JWT का दावा करने वाला सेट बनाएं

जेडब्ल्यूटी के दावे वाले सेट में, जेडब्ल्यूटी के बारे में जानकारी होती है. इसमें अनुरोध की जा रही अनुमतियां (स्कोप), टोकन का टारगेट, जारी करने वाला, टोकन जारी करने का समय, और टोकन की लाइफ़टाइम शामिल होती है. ज़्यादातर फ़ील्ड में जानकारी देना ज़रूरी है. JWT हेडर की तरह, JWT क्लेम सेट भी एक JSON ऑब्जेक्ट होता है. इसका इस्तेमाल सिग्नेचर का हिसाब लगाने के लिए किया जाता है.

ज़रूरी दावे

JWT के दावे वाले सेट में ज़रूरी दावे, किसी भी क्रम में दिख सकते हैं.

नाम	ब्यौरा
iss	सेवा खाते का ईमेल पता.
scope	ऐप्लिकेशन जिन अनुमतियों का अनुरोध करता है उनकी सूची. इस सूची में अनुमतियों के नामों के बीच में खाली जगह का इस्तेमाल किया जाता है.
aud	यह एक ऐसा डिस्क्रिप्टर है जो पुष्टि के लिए तय किए गए टारगेट के बारे में बताता है. ऐक्सेस टोकन का अनुरोध करते समय, यह वैल्यू हमेशा https://oauth2.googleapis.com/token होती है.
exp	यह असर्शन के खत्म होने का समय है. इसे 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद से सेकंड में दिखाया जाता है. यह वैल्यू, जारी किए जाने के समय के बाद ज़्यादा से ज़्यादा एक घंटे तक मान्य रहती है.
iat	दावा जारी करने का समय. इसे 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या के तौर पर दिखाया जाता है.

यहां JWT के दावे वाले सेट में ज़रूरी फ़ील्ड के JSON फ़ॉर्मैट का उदाहरण दिया गया है:

{
  "iss": "[e-mail]",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

अन्य दावे

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

अगर आपको ऐसा ऐक्सेस टोकन पाना है जो किसी ऐप्लिकेशन को किसी संसाधन का ऐक्सेस देता है, तो JWT के दावे में उपयोगकर्ता का ईमेल पता शामिल करें. इसे sub फ़ील्ड की वैल्यू के तौर पर सेट करें.

नाम	ब्यौरा
sub	उस उपयोगकर्ता का ईमेल पता जिसके लिए ऐप्लिकेशन, डेलिगेट किए गए ऐक्सेस का अनुरोध कर रहा है.

अगर किसी ऐप्लिकेशन के पास उपयोगकर्ता के तौर पर काम करने की अनुमति नहीं है, तो sub फ़ील्ड वाले ऐक्सेस टोकन के अनुरोध का जवाब गड़बड़ी होगा.

यह sub फ़ील्ड को शामिल करने वाले JWT दावे के सेट का उदाहरण है:

{
  "iss": "[e-mail]",
  "sub": "[e-mail]",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

JWT के दावे के सेट को एन्कोड करना

JWT हेडर की तरह, JWT के दावे वाले सेट को UTF-8 में क्रम से लगाया जाना चाहिए. साथ ही, इसे Base64url-safe में एन्कोड किया जाना चाहिए. यह JWT के दावे वाले सेट के JSON फ़ॉर्मैट का उदाहरण है:

{
  "iss": "[e-mail]",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

हस्ताक्षर की गणना करना

JSON वेब सिग्नेचर (JWS) एक ऐसा स्पेसिफ़िकेशन है जो JWT के लिए सिग्नेचर जनरेट करने के तरीके के बारे में बताता है. हस्ताक्षर के लिए इनपुट, इस कॉन्टेंट का बाइट ऐरे होता है:

{Base64url encoded header}.{Base64url encoded claim set}

हस्ताक्षर की गिनती करते समय, JWT हेडर में मौजूद हस्ताक्षर करने वाले एल्गोरिदम का इस्तेमाल किया जाना चाहिए. Google OAuth 2.0 ऑथराइज़ेशन सर्वर, सिर्फ़ RSA का इस्तेमाल करके हस्ताक्षर करने वाले एल्गोरिदम के साथ काम करता है. यह SHA-256 हैशिंग एल्गोरिदम का इस्तेमाल करता है. इसे JWT हेडर में मौजूद alg फ़ील्ड में RS256 के तौर पर दिखाया जाता है.

Google API Consoleसे मिले निजी पासकोड का इस्तेमाल करके, SHA256withRSA (इसे SHA-256 हैश फ़ंक्शन के साथ RSASSA-PKCS1-V1_5-SIGN भी कहा जाता है) का इस्तेमाल करके, इनपुट के UTF-8 वर्शन पर हस्ताक्षर करें. आउटपुट, बाइट ऐरे होगा.

इसके बाद, हस्ताक्षर को Base64url के कोड में बदलना ज़रूरी है. हेडर, दावा सेट, और हस्ताक्षर को एक साथ जोड़ा जाता है. इसके लिए, पीरियड (.) वर्ण का इस्तेमाल किया जाता है. इससे मिलने वाला नतीजा, JWT होता है. यह इस तरह होना चाहिए (लाइन ब्रेक को बेहतर तरीके से समझने के लिए जोड़ा गया है):

{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}

Base64url कोड में बदलने से पहले, JWT का उदाहरण यहां दिया गया है:

{"alg":"RS256","typ":"JWT"}.
{
"iss":"[e-mail]",
"scope":"https://www.googleapis.com/auth/prediction",
"aud":"https://oauth2.googleapis.com/token",
"exp":1328554385,
"iat":1328550785
}.
[signature bytes]

यह ऐसे JWT का उदाहरण है जिस पर हस्ताक्षर किया गया है और जिसे ट्रांसमिट किया जा सकता है:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ

ऐक्सेस टोकन का अनुरोध करना

साइन किया गया JWT जनरेट करने के बाद, कोई ऐप्लिकेशन इसका इस्तेमाल ऐक्सेस टोकन का अनुरोध करने के लिए कर सकता है. यह ऐक्सेस टोकन का अनुरोध, एचटीटीपीएस POST अनुरोध है. साथ ही, इसका मुख्य हिस्सा यूआरएल कोड में बदला गया है. उदाहरण के लिए:

https://oauth2.googleapis.com/token

एचटीटीपीएस POST अनुरोध में इन पैरामीटर का होना ज़रूरी है:

नाम	ब्यौरा
grant_type	ज़रूरत के मुताबिक, कोड में बदली गई इस स्ट्रिंग का इस्तेमाल करें: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion	हस्ताक्षर के साथ JWT.

यह एचटीटीपीएस POST अनुरोध का रॉ डंप है. इसका इस्तेमाल ऐक्सेस टोकन के अनुरोध में किया जाता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ

curl का इस्तेमाल करके किया गया यह अनुरोध भी ऐसा ही है:

curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU
' https://oauth2.googleapis.com/token

जवाब मैनेज करना

अगर JWT और ऐक्सेस टोकन का अनुरोध सही तरीके से किया गया है और सेवा खाते के पास कार्रवाई करने की अनुमति है, तो पुष्टि करने वाले सर्वर से मिले JSON रिस्पॉन्स में ऐक्सेस टोकन शामिल होता है. यहां जवाब का एक उदाहरण दिया गया है:

{
  "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M",
  "scope": "https://www.googleapis.com/auth/prediction"
  "token_type": "Bearer",
  "expires_in": 3600
}

expires_in वैल्यू में बताई गई अवधि के दौरान, ऐक्सेस टोकन का फिर से इस्तेमाल किया जा सकता है.

सुरक्षा से जुड़ी अहम जानकारी: किसी और के नाम पर काम करने के बारे में जानकारी

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

• उपयोगकर्ता की ओर से ऐक्सेस करना: आपके ऐप्लिकेशन को हर एपीआई अनुरोध के लिए, यह बताना होगा कि किस उपयोगकर्ता की पहचान का इस्तेमाल करना है. इसके बाद, ऐप्लिकेशन उस उपयोगकर्ता की अनुमतियों के साथ काम करता है. यह किसी भी तरह की बढ़ी हुई या पूरे डोमेन के लिए उपलब्ध सुविधाओं के साथ काम नहीं करता.
• अनुमतियां सीमित होती हैं: सेवा खाते का ऐक्सेस दो बातों पर निर्भर करता है: जिस उपयोगकर्ता के नाम पर सेवा खाता बनाया गया है उसकी अनुमतियां और Admin console में आपके दिए गए OAuth स्कोप. यह उस डेटा को ऐक्सेस नहीं कर सकता जिसे उपयोगकर्ता खुद ऐक्सेस नहीं कर सकता.
• कम से कम विशेषाधिकार का सिद्धांत: यह सुविधा, उपयोगकर्ता की सीधी सहमति के बिना उसके डेटा को ऐक्सेस करने की अनुमति देती है. इसलिए, सुरक्षा के सबसे सही तरीकों का पालन करना ज़रूरी है. सिर्फ़ ज़रूरी OAuth स्कोप की अनुमति दें. साथ ही, यह पक्का करें कि आपको सुरक्षा से जुड़ी समस्याओं के बारे में पता हो.

सुरक्षा से जुड़े दिशा-निर्देशों के बारे में ज़्यादा जानने के लिए, डोमेन-वाइड डेलिगेशन के सबसे सही तरीके लेख पढ़ें.

Google API को कॉल करना

Java

Google API को कॉल करने के लिए, GoogleCredentials ऑब्जेक्ट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

1. GoogleCredentials ऑब्जेक्ट का इस्तेमाल करके, उस एपीआई के लिए एक सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. उदाहरण के लिए:

   SQLAdmin sqladmin =
       new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credentials).build();

2. सेवा ऑब्जेक्ट की ओर से उपलब्ध कराए गए इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा से अनुरोध करें. उदाहरण के लिए, exciting-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस की सूची बनाने के लिए:

   SQLAdmin.Instances.List instances =
       sqladmin.instances().list("exciting-example-123").execute();

Python

Google API को कॉल करने के लिए, अनुमति वाले Credentials ऑब्जेक्ट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

1. उस एपीआई के लिए एक सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. एपीआई के नाम और वर्शन के साथ-साथ, अनुमति वाले Credentials ऑब्जेक्ट का इस्तेमाल करके, build फ़ंक्शन को कॉल करके एक सेवा ऑब्जेक्ट बनाया जाता है. उदाहरण के लिए, Cloud SQL Administration API के 1beta3 वर्शन को कॉल करने के लिए:

   import googleapiclient.discovery
   
   sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)

2. सेवा ऑब्जेक्ट की ओर से उपलब्ध कराए गए इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा से अनुरोध करें. उदाहरण के लिए, exciting-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस की सूची बनाने के लिए:

   response = sqladmin.instances().list(project='exciting-example-123').execute()

एचटीटीपी/रेस्ट

जब आपका ऐप्लिकेशन ऐक्सेस टोकन पा लेता है, तब आपके पास इस टोकन का इस्तेमाल करके, किसी सेवा खाते या उपयोगकर्ता खाते की ओर से Google API को कॉल करने का विकल्प होता है. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब एपीआई को ऐक्सेस करने के लिए ज़रूरी स्कोप दिए गए हों. इसके लिए, एपीआई को भेजे जाने वाले अनुरोध में ऐक्सेस टोकन शामिल करें. इसके लिए, access_token क्वेरी पैरामीटर या Authorization एचटीटीपी हेडर Bearer वैल्यू में से किसी एक को शामिल करें. जब मुमकिन हो, तब एचटीटीपी हेडर का इस्तेमाल करना बेहतर होता है, क्योंकि क्वेरी स्ट्रिंग, सर्वर लॉग में दिखती हैं. ज़्यादातर मामलों में, Google API को कॉल करने के लिए क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Drive Files API को कॉल करते समय.

OAuth 2.0 Playground पर जाकर, Google के सभी एपीआई आज़माए जा सकते हैं और उनके स्कोप देखे जा सकते हैं.

एचटीटीपी GET के उदाहरण

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, drive.files एंडपॉइंट (Drive Files API) को कॉल करने का तरीका यहां दिया गया है. ध्यान दें कि आपको अपना ऐक्सेस टोकन देना होगा:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

यहां पुष्टि किए गए उपयोगकर्ता के लिए, access_token क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, उसी एपीआई को कॉल किया गया है:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl के उदाहरण

curl कमांड-लाइन ऐप्लिकेशन की मदद से, इन कमांड की जांच की जा सकती है. यहां एचटीटीपी हेडर विकल्प (पसंदीदा) का इस्तेमाल करने वाला एक उदाहरण दिया गया है:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर का विकल्प भी इस्तेमाल किया जा सकता है:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

ऐक्सेस टोकन की समयसीमा खत्म होने पर

Google OAuth 2.0 ऑथराइज़ेशन सर्वर से जारी किए गए ऐक्सेस टोकन की समयसीमा, expires_in वैल्यू में दी गई अवधि के बाद खत्म हो जाती है. ऐक्सेस टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन को एक और JWT जनरेट करना चाहिए. साथ ही, उस पर हस्ताक्षर करना चाहिए और एक और ऐक्सेस टोकन का अनुरोध करना चाहिए.

JWT से जुड़ी गड़बड़ी के कोड

error फ़ील्ड	error_description फ़ील्ड	मतलब	समस्या कैसे हल करें
unauthorized_client	Unauthorized client or scope in request.	अगर आपको डोमेन-वाइड डेलिगेशन का इस्तेमाल करना है, तो सेवा खाते को उपयोगकर्ता के डोमेन की Admin console में अनुमति नहीं दी गई है.	पक्का करें कि सेवा खाते को Admin console के पूरे डोमेन के लिए उपयोगकर्ता की भूमिका सौंपने की सुविधा पेज पर, sub दावे (फ़ील्ड) में मौजूद उपयोगकर्ता के लिए अनुमति दी गई हो. आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके Google खाते के सभी उपयोगकर्ताओं के लिए अनुमति लागू होने में 24 घंटे लग सकते हैं.
unauthorized_client	Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.	Admin console में, क्लाइंट आईडी (संख्या) के बजाय क्लाइंट के ईमेल पते का इस्तेमाल करके सेवा खाते को अनुमति दी गई थी. इसके अलावा, अनुमति देने के लिए Google ग्रुप का इस्तेमाल किया गया था.	Admin console में, पूरे डोमेन के लिए उपयोगकर्ता की भूमिका सौंपने की सुविधा वाले पेज पर जाकर, क्लाइंट को हटाएं और उसे संख्या वाले आईडी के साथ फिर से जोड़ें. इसके अलावा, Google ग्रुप को हटाएं और उसे किसी सेवा या उपयोगकर्ता खाते से बदलें.
access_denied	(कोई भी वैल्यू)	अगर डोमेन-वाइड डेलिगेशन का इस्तेमाल किया जा रहा है, तो Admin console में अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दी गई है.	पक्का करें कि सेवा खाते को Admin console के डोमेन-वाइड डेलिगेशन पेज पर, sub दावे (फ़ील्ड) में मौजूद उपयोगकर्ता के लिए अनुमति मिली हो. साथ ही, इसमें वे सभी स्कोप शामिल हों जिनके लिए आपने अपने JWT के scope दावे में अनुरोध किया है. पुष्टि करें कि Google की सेवाओं का ऐक्सेस प्रतिबंधित नहीं है. इसके लिए, उन सेवाओं के ऐक्सेस को मैनेज करना जो अलग से कंट्रोल नहीं की जातीं लेख पढ़ें. आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके Google खाते के सभी उपयोगकर्ताओं के लिए अनुमति लागू होने में 24 घंटे लग सकते हैं.
admin_policy_enforced	(कोई भी वैल्यू)	Google Workspace एडमिन की नीतियों की वजह से, Google खाता अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे सकता.	Google Workspace एडमिन के सहायता लेख यह कंट्रोल करना कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले किन ऐप्लिकेशन की मदद से Google Workspace के डेटा को ऐक्सेस किया जा सकता है में जाकर, इस बारे में ज़्यादा जानें कि एडमिन, सभी स्कोप या संवेदनशील और प्रतिबंधित स्कोप के ऐक्सेस को तब तक कैसे सीमित कर सकता है, जब तक कि आपके OAuth क्लाइंट आईडी को साफ़ तौर पर ऐक्सेस करने की अनुमति नहीं दी जाती.
invalid_client	(कोई भी वैल्यू)	OAuth क्लाइंट या JWT टोकन अमान्य है या उसे गलत तरीके से कॉन्फ़िगर किया गया है. ज़्यादा जानकारी के लिए, गड़बड़ी का ब्यौरा देखें.	पक्का करें कि JWT टोकन मान्य हो और उसमें सही दावे शामिल हों. देखें कि OAuth क्लाइंट और सेवा खाता सही तरीके से कॉन्फ़िगर किए गए हों. यह भी पक्का करें कि आपने सही ईमेल पते का इस्तेमाल किया हो. जांच करें कि जेडब्ल्यूटी टोकन सही है और अनुरोध में दिए गए क्लाइंट आईडी के लिए जारी किया गया था.
deleted_client	(कोई भी वैल्यू)	अनुरोध करने के लिए इस्तेमाल किए जा रहे OAuth क्लाइंट को मिटा दिया गया है. जिन क्लाइंट खातों का इस्तेमाल नहीं किया जाता है उन्हें मैन्युअल तरीके से या अपने-आप मिटाया जा सकता है. मिटाए गए क्लाइंट को मिटाने के 30 दिनों के अंदर वापस लाया जा सकता है. ज़्यादा जानें.	ऐसे क्लाइंट आईडी का इस्तेमाल करें जो अब भी चालू हो.
invalid_grant	Not a valid email या Invalid email or User ID.	उपयोगकर्ता मौजूद नहीं है.	देखें कि sub दावे (फ़ील्ड) में दिया गया ईमेल पता सही हो.
invalid_grant	Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your 'iat' and 'exp' values and use a clock with skew to account for clock differences between systems.	आम तौर पर, इसका मतलब है कि लोकल सिस्टम का समय सही नहीं है. ऐसा तब भी हो सकता है, जब exp की वैल्यू, iat की वैल्यू से 65 मिनट से ज़्यादा हो या exp की वैल्यू, iat की वैल्यू से कम हो.	पक्का करें कि जिस सिस्टम पर JWT जनरेट किया गया है उसकी घड़ी सही हो. अगर ज़रूरी हो, तो अपने समय को Google NTP के साथ सिंक करें.
invalid_grant	Invalid JWT Signature.	JWT असर्शन पर ऐसी निजी कुंजी से हस्ताक्षर किया गया है जो सेवा खाते से जुड़ी नहीं है. इस सेवा खाते की पहचान क्लाइंट ईमेल से होती है. इसके अलावा, हो सकता है कि इस्तेमाल की गई कुंजी को मिटा दिया गया हो, बंद कर दिया गया हो या उसकी समयसीमा खत्म हो गई हो. इसके अलावा, हो सकता है कि JWT असर्शन को गलत तरीके से कोड में बदला गया हो. इसे Base64 की मदद से कोड में बदला जाना चाहिए. इसमें नई लाइनें या पैडिंग के बराबर के चिह्न नहीं होने चाहिए.	JWT के दावे वाले सेट को डिकोड करें. साथ ही, पुष्टि करें कि दावे पर हस्ताक्षर करने वाली कुंजी, सेवा खाते से जुड़ी है. JWT सही तरीके से जनरेट हो, इसके लिए Google की ओर से उपलब्ध कराई गई OAuth लाइब्रेरी का इस्तेमाल करें.
invalid_scope	Invalid OAuth scope or ID token audience provided.	किसी स्कोप का अनुरोध नहीं किया गया (स्कोप की खाली सूची) या अनुरोध किए गए स्कोप में से कोई एक मौजूद नहीं है (यानी कि अमान्य है).	पक्का करें कि JWT का scope दावा (फ़ील्ड) भरा गया हो. साथ ही, इसमें शामिल स्कोप की तुलना उन एपीआई के लिए दस्तावेज़ में दिए गए स्कोप से करें जिनका आपको इस्तेमाल करना है. इससे यह पक्का किया जा सकेगा कि कोई गड़बड़ी या टाइपिंग की गलती न हो. ध्यान दें कि scope दावे में स्कोप की सूची को कॉमा से नहीं, बल्कि स्पेस से अलग किया जाना चाहिए.
disabled_client	The OAuth client was disabled.	JWT दावे पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी बंद है.	Google API Consoleपर जाएं. इसके बाद, आईएएम और एडमिन > सेवा खाते में जाकर, उस सेवा खाते को चालू करें जिसमें "कुंजी का आईडी" मौजूद है. इस आईडी का इस्तेमाल, पुष्टि करने के लिए किया जाता है.
org_internal	This client is restricted to users within its organization.	अनुरोध में मौजूद OAuth क्लाइंट आईडी, ऐसे प्रोजेक्ट का हिस्सा है जो किसी Google Cloud संगठन में Google खातों के ऐक्सेस को सीमित करता है.	पुष्टि करने के लिए, संगठन के सेवा खाते का इस्तेमाल करें. अपने OAuth ऐप्लिकेशन के लिए, उपयोगकर्ता के टाइप का कॉन्फ़िगरेशन पक्का करें.

परिशिष्ट: OAuth के बिना सेवा खाते की पुष्टि करना

Google के कुछ एपीआई के साथ, OAuth 2.0 ऐक्सेस टोकन के बजाय, सीधे तौर पर हस्ताक्षर किए गए JWT का इस्तेमाल करके, एपीआई कॉल किए जा सकते हैं. ऐसा होने पर, एपीआई कॉल करने से पहले, आपको Google के अनुमति सर्वर को नेटवर्क अनुरोध नहीं भेजना पड़ता.

अगर आपको जिस एपीआई को कॉल करना है उसकी सेवा की परिभाषा, Google APIs GitHub repository में पब्लिश की गई है, तो ऐक्सेस टोकन के बजाय JWT का इस्तेमाल करके, अनुमति वाले एपीआई कॉल किए जा सकते हैं. इसके लिए:

1. सेवा खाता बनाएं. खाता बनाते समय आपको जो JSON फ़ाइल मिलती है उसे सुरक्षित रखें.
2. jwt.io पर मौजूद किसी भी स्टैंडर्ड JWT लाइब्रेरी का इस्तेमाल करके, हेडर और पेलोड वाला JWT बनाएं. जैसे, यहां दिए गए उदाहरण में दिखाया गया है:

   {
     "alg": "RS256",
     "typ": "JWT",
     "kid": "abcdef1234567890"
   }
   .
   {
     "iss": "[e-mail]",
     "sub": "[e-mail]",
     "aud": "https://firestore.googleapis.com/",
     "iat": 1511900000,
     "exp": 1511903600
   }

• हेडर में मौजूद kid फ़ील्ड के लिए, अपने सेवा खाते के निजी पासकोड का आईडी डालें. यह वैल्यू, आपको सेवा खाते की JSON फ़ाइल के private_key_id फ़ील्ड में मिल सकती है.
• iss और sub फ़ील्ड के लिए, अपने सेवा खाते का ईमेल पता डालें. यह वैल्यू, आपको सेवा खाते की JSON फ़ाइल के client_email फ़ील्ड में मिल सकती है. यह वैल्यू, क्लाइंट की पहचान करती है. यह क्लाइंट आईडी की तरह काम करती है.
• aud फ़ील्ड के लिए, एपीआई एंडपॉइंट की जानकारी दें. उदाहरण के लिए: https://SERVICE.googleapis.com/.
• iat फ़ील्ड के लिए, मौजूदा Unix epoch टाइम बताएं. साथ ही, exp फ़ील्ड के लिए, ठीक 3600 सेकंड बाद का समय बताएं, जब JWT की समयसीमा खत्म हो जाएगी.

अपने सेवा खाते की JSON फ़ाइल में मौजूद निजी कुंजी का इस्तेमाल करके, JWT पर RSA-256 से हस्ताक्षर करें.

उदाहरण के लिए:

Java

google-auth-library-java और java-jwt का इस्तेमाल करके:

import com.google.auth.oauth2.ServiceAccountCredentials;
...
GoogleCredentials credentials =
        GoogleCredentials.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = ((ServiceAccountCredentials) credentials).getPrivateKey();
String privateKeyId = ((ServiceAccountCredentials) credentials).getPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("[e-mail]")
        .withSubject("[e-mail]")
        .withAudience("https://firestore.googleapis.com/")
        .withIssuedAt(new Date(now))
        .withExpiresAt(new Date(now + 3600 * 1000L))
        .sign(algorithm);
} catch ...

Python

PyJWT का इस्तेमाल करके:

iat = time.time()
exp = iat + 3600
payload = {'iss': '[e-mail]',
           'sub': '[e-mail]',
           'aud': 'https://firestore.googleapis.com/',
           'iat': iat,
           'exp': exp}
additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}
signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers,
                       algorithm='RS256')

1. साइन किए गए JWT को बियरर टोकन के तौर पर इस्तेमाल करके, एपीआई को कॉल करें:

   GET /v1/projects/abc/databases/123/indexes HTTP/1.1
   Authorization: Bearer SIGNED_JWT
   Host: firestore.googleapis.com

'सभी खातों की सुरक्षा' सुविधा लागू करना

अपने उपयोगकर्ताओं के खातों को सुरक्षित रखने के लिए, आपको एक और कदम उठाना चाहिए. इसके लिए, Google की Cross-Account Protection Service का इस्तेमाल करके, क्रॉस-अकाउंट सुरक्षा लागू करें. इस सेवा की मदद से, सुरक्षा से जुड़ी घटनाओं की सूचनाएं पाने के लिए सदस्यता ली जा सकती है. इससे आपके ऐप्लिकेशन को उपयोगकर्ता खाते में हुए अहम बदलावों के बारे में जानकारी मिलती है. इसके बाद, इस जानकारी का इस्तेमाल करके कार्रवाई की जा सकती है. यह इस बात पर निर्भर करता है कि आपको इवेंट का जवाब कैसे देना है.

Google की Cross-Account Protection Service, आपके ऐप्लिकेशन को इस तरह के इवेंट भेजती है:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

सभी खातों की सुरक्षा की सुविधा लागू करने के तरीके और उपलब्ध इवेंट की पूरी सूची के बारे में ज़्यादा जानने के लिए, सभी खातों की सुरक्षा की सुविधा की मदद से उपयोगकर्ता खातों को सुरक्षित रखें पेज देखें.