इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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 Workspace खाते में मौजूद उपयोगकर्ताओं का डेटा ऐक्सेस करना है, तो सेवा खाते को डोमेन के लिए ऐक्सेस दें.

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

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

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

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

सेवा खाता बनाया जा रहा है

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

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

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

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

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

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

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

सेवा खाते को डोमेन के सभी ऐप्लिकेशन के लिए अनुमतियां देना

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

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

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

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

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

एपीआई कॉल करने की तैयारी करना

Java

से क्लाइंट ईमेल पता और निजी कुंजी पाने के बाद, सेवा खाते के क्रेडेंशियल और उन स्कोप से GoogleCredential ऑब्जेक्ट बनाने के लिए, Java के लिए Google APIs क्लाइंट लाइब्रेरी का इस्तेमाल करें जिनका ऐक्सेस आपके ऐप्लिकेशन को चाहिए. उदाहरण के लिए:

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

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

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

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

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("workspace-user@example.com");

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

Python

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

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

SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
SERVICE_ACCOUNT_FILE = '/path/to/service.json'

credentials = service_account.Credentials.from_service_account_file(
        SERVICE_ACCOUNT_FILE, scopes=SCOPES)
```
अगर Google Cloud Platform पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो इसके बजाय ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल किया जा सकता है. इससे प्रोसेस को आसान बनाया जा सकता है.
पूरे डोमेन के लिए ऐक्सेस देना
अगर आपने सेवा खाते को डोमेन के सभी खातों का ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो किसी मौजूदा ServiceAccountCredentials ऑब्जेक्ट के with_subject तरीके का इस्तेमाल करें. उदाहरण के लिए:
```
delegated_credentials = credentials.with_subject('user@example.org')
```

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

एचटीटीपी/REST

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

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

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

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

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

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

ऐक्सेस टोकन की समयसीमा खत्म होने पर, आपका ऐप्लिकेशन एक और JWT जनरेट करता है, उस पर हस्ताक्षर करता है, और फिर एक और ऐक्सेस टोकन का अनुरोध करता है.

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

इस सेक्शन के बाकी हिस्से में, JWT बनाने, 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 हेडर बनाना

हेडर में तीन फ़ील्ड होते हैं. इनसे हस्ताक्षर करने वाले एल्गोरिद्म, एश्योरेशन के फ़ॉर्मैट, और JWT पर हस्ताक्षर करने के लिए इस्तेमाल किए गए [सेवा खाते की कुंजी का आईडी](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) के बारे में पता चलता है. एल्गोरिदम और फ़ॉर्मैट ज़रूरी है. साथ ही, हर फ़ील्ड में सिर्फ़ एक वैल्यू होनी चाहिए. नए एल्गोरिदम और फ़ॉर्मैट के ज़रिए, यह हेडर बदल जाएगा. कुंजी आईडी देना ज़रूरी नहीं है. अगर गलत कुंजी आईडी दिया जाता है, तो GCP टोकन की पुष्टि करने के लिए, सेवा खाते से जुड़ी सभी कुंजियों को आज़माएगा. अगर कोई मान्य कुंजी नहीं मिलती है, तो टोकन अस्वीकार कर दिया जाएगा. Google के पास, आने वाले समय में गलत कुंजी आईडी वाले टोकन को अस्वीकार करने का अधिकार सुरक्षित है.

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

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

इसका Base64url इस तरह दिखता है:

          eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

JWT क्लेम सेट बनाना

JWT क्लेम सेट में 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": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

अन्य दावे

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

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

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

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

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

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub": "some.user@example.com",
  "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": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "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 ऑथराइज़ेशन सर्वर पर, सिर्फ़ SHA-256 हैशिंग एल्गोरिदम का इस्तेमाल करके RSA, साइनिंग एल्गोरिदम के तौर पर काम करता है. इसे JWT हेडर में alg फ़ील्ड में RS256 के तौर पर दिखाया जाता है.

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

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

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

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

{"alg":"RS256","typ":"JWT"}.
{
"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
"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 वैल्यू से तय की गई समयावधि के दौरान किया जा सकता है.

Google API को कॉल करना

Java

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

GoogleCredential ऑब्जेक्ट का इस्तेमाल करके, उस एपीआई के लिए सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. उदाहरण के लिए:
```
SQLAdmin sqladmin =
    new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
```
सेवा ऑब्जेक्ट से मिले इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा के लिए अनुरोध करें. उदाहरण के लिए, exciting-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस की सूची बनाने के लिए:
```
SQLAdmin.Instances.List instances =
    sqladmin.instances().list("exciting-example-123").execute();
```

Python

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

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

sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
```
सेवा ऑब्जेक्ट से मिले इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा के लिए अनुरोध करें. उदाहरण के लिए, exciting-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस की सूची बनाने के लिए:
```
response = sqladmin.instances().list(project='exciting-example-123').execute()
```

एचटीटीपी/REST

जब आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाता है, तो किसी सेवा खाते या उपयोगकर्ता खाते की ओर से 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 में अनुमति नहीं दी गई है.	पक्का करें कि `sub` दावे (फ़ील्ड) में मौजूद उपयोगकर्ता के लिए, Admin console के पूरे डोमेन के लिए, ऐक्सेस देने की सुविधा पेज पर, सेवा खाते को अनुमति दी गई हो. आम तौर पर, अनुमति देने में कुछ मिनट लगते हैं. हालांकि, आपके 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 में क्लाइंट आईडी (संख्या) के बजाय, क्लाइंट ईमेल पते का इस्तेमाल करके, सेवा खाते को अनुमति दी गई थी.	Admin console में, डोमेन के लिए एडमिन ऐक्सेस देने की सुविधा पेज पर जाकर, क्लाइंट को हटाएं और उसे संख्या वाले आईडी के साथ फिर से जोड़ें.
`access_denied`	(कोई भी वैल्यू)	अगर डोमेन के लिए, किसी दूसरे व्यक्ति को अनुमति देने की सुविधा का इस्तेमाल किया जा रहा है, तो हो सकता है कि Admin console में, अनुरोध किए गए एक या उससे ज़्यादा स्कोप के लिए अनुमति न दी गई हो.	पक्का करें कि सेवा खाते को, `sub` दावे (फ़ील्ड) में मौजूद उपयोगकर्ता के लिए, Admin console के पूरे डोमेन के लिए डेलिगेशन पेज पर अनुमति दी गई हो. साथ ही, यह भी पक्का करें कि इसमें वे सभी स्कोप शामिल हों जिनका अनुरोध आपने अपने JWT के `scope` दावे में किया है. आम तौर पर, अनुमति देने में कुछ मिनट लगते हैं. हालांकि, आपके Google खाते के सभी उपयोगकर्ताओं को अनुमति भेजने में 24 घंटे लग सकते हैं.
`admin_policy_enforced`	(कोई भी वैल्यू)	Google खाता, अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे पा रहा है. ऐसा, Google Workspace एडमिन की नीतियों की वजह से हो रहा है.	Google Workspace एडमिन के सहायता लेख यह कंट्रोल करना कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले किन ऐप्लिकेशन से, Google Workspace का डेटा ऐक्सेस किया जा सकता है को पढ़ें. इससे आपको यह जानने में मदद मिलेगी कि एडमिन, सभी स्कोप या संवेदनशील और पाबंदी वाले स्कोप के ऐक्सेस पर पाबंदी कैसे लगा सकता है. ऐसा तब तक किया जा सकता है, जब तक आपके OAuth क्लाइंट आईडी को साफ़ तौर पर ऐक्सेस की अनुमति नहीं दी जाती.
`invalid_client`	(कोई भी वैल्यू)	OAuth क्लाइंट या JWT टोकन अमान्य है या गलत तरीके से कॉन्फ़िगर किया गया है. ज़्यादा जानकारी के लिए, गड़बड़ी के ब्यौरे को देखें.	पक्का करें कि JWT टोकन मान्य हो और उसमें सही दावे हों. देखें कि OAuth क्लाइंट और सेवा खाता सही तरीके से कॉन्फ़िगर किया गया हो और सही ईमेल पते का इस्तेमाल किया जा रहा हो. देखें कि JWT टोकन सही है या नहीं. साथ ही, यह भी देखें कि उसे अनुरोध में दिए गए क्लाइंट आईडी के लिए जारी किया गया है या नहीं.
`invalid_grant`	`Not a valid email.`	उपयोगकर्ता मौजूद नहीं है.	देखें कि `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 एश्योरेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी बंद है.	पर जाएं और आईएएम और एडमिन > सेवा खाते में जाकर, उस सेवा खाते को चालू करें जिसमें "की आईडी" है. इसका इस्तेमाल, एश्योरेशन पर हस्ताक्षर करने के लिए किया जाता है.
`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 रिपॉज़िटरी में पब्लिश की गई है, तो आपके पास ऐक्सेस टोकन के बजाय, JWT का इस्तेमाल करके एपीआई कॉल करने की अनुमति है. इसके लिए:

ऊपर बताए गए तरीके से सेवा खाता बनाएं. खाता बनाते समय मिलने वाली JSON फ़ाइल को ज़रूर सेव रखें.

jwt.io जैसी किसी स्टैंडर्ड JWT लाइब्रेरी का इस्तेमाल करके, हेडर और पेलोड के साथ JWT बनाएं. उदाहरण के लिए:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "abcdef1234567890"
}
.
{
  "iss": "123456-compute@developer.gserviceaccount.com",
  "sub": "123456-compute@developer.gserviceaccount.com",
  "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 फ़ील्ड के लिए, यूनिक्स का मौजूदा समय बताएं. साथ ही, exp फ़ील्ड के लिए, 3600 सेकंड बाद का समय बताएं, जब JWT की समयसीमा खत्म हो जाएगी.

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

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

Java

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

GoogleCredential credential =
        GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = credential.getServiceAccountPrivateKey();
String privateKeyId = credential.getServiceAccountPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("123456-compute@developer.gserviceaccount.com")
        .withSubject("123456-compute@developer.gserviceaccount.com")
        .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': '123456-compute@developer.gserviceaccount.com',
           'sub': '123456-compute@developer.gserviceaccount.com',
           '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')

साइन किए गए JWT को बियरर टोकन के तौर पर इस्तेमाल करके, एपीआई को कॉल करें:
```
GET /v1/projects/abc/databases/123/indexes HTTP/1.1
Authorization: Bearer SIGNED_JWT
Host: firestore.googleapis.com
```

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

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

Google की क्रॉस-खाता सुरक्षा सेवा, आपके ऐप्लिकेशन पर इस तरह के इवेंट भेजती है:

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

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

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

खास जानकारी

सेवा खाता बनाया जा रहा है

सेवा खाते को डोमेन के सभी ऐप्लिकेशन के लिए अनुमतियां देना

एपीआई कॉल करने की तैयारी करना

Java

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

Python

एचटीटीपी/REST

JWT बनाना

JWT हेडर बनाना

JWT क्लेम सेट बनाना

ज़रूरी दावे

अन्य दावे

JWT क्लेम सेट को एन्कोड करना

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

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

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

Google API को कॉल करना

Java

Python

एचटीटीपी/REST

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

curl के उदाहरण

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

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

अतिरिक्त जानकारी: OAuth के बिना सेवा खाते को अनुमति देना

Java

Python

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

`curl` के उदाहरण