सर्वर से सर्वर ऐप्लिकेशन के लिए 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 फ़्लो को कैसे पूरा कर सकता है.

खास जानकारी

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

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

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

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

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

अगर आपका ऐप्लिकेशन 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 Workspace खाते का इस्तेमाल करके, संगठन का Workspace एडमिन किसी ऐप्लिकेशन को Google Workspace डोमेन में मौजूद उपयोगकर्ताओं की ओर से, Workspace उपयोगकर्ता डेटा ऐक्सेस करने की अनुमति दे सकता है. उदाहरण के लिए, Google Calendar API का इस्तेमाल करने वाला कोई ऐप्लिकेशन, 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 डोमेन के उपयोगकर्ताओं के तौर पर एपीआई कॉल करने का अधिकार है. ऐसा उपयोगकर्ताओं की "पहचान चुराने" के लिए किया जाता है. डेलिगेट किए गए इन एपीआई कॉल को करने के लिए, आपको साफ़ तौर पर उस उपयोगकर्ता के बारे में बताना होगा जिसके नाम पर कॉल किए जा रहे हैं.

डेलिगेट किए गए एपीआई कॉल की तैयारी की जा रही है

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("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

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

पूरे डोमेन के लिए, ऐक्सेस करने का अधिकार सौंपना

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

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

ऊपर दिए गए कोड में, GoogleCredentials ऑब्जेक्ट का इस्तेमाल करके, उसके createDelegated() तरीके को कॉल किया गया है. 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/service.json'

credentials = service_account.Credentials.from_service_account_file(
        SERVICE_ACCOUNT_FILE, scopes=SCOPES)

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

  2. पूरे डोमेन के लिए, ऐक्सेस करने का अधिकार सौंपना

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

    delegated_credentials = credentials.with_subject('user@example.org')

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

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

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 हेडर बनाना

हेडर में तीन फ़ील्ड होते हैं. इनमें हस्ताक्षर करने के एल्गोरिदम, दावे का फ़ॉर्मैट, और [सेवा खाते की कुंजी का आईडी](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) शामिल होता है. इस कुंजी का इस्तेमाल, JWT पर हस्ताक्षर करने के लिए किया गया था. एल्गोरिदम और फ़ॉर्मैट की जानकारी देना ज़रूरी है. साथ ही, हर फ़ील्ड की सिर्फ़ एक वैल्यू होनी चाहिए. नए एल्गोरिदम और फ़ॉर्मैट के आने पर, यह हेडर उसी के हिसाब से बदल जाएगा. कुंजी का आईडी देना ज़रूरी नहीं है. अगर गलत कुंजी का आईडी दिया जाता है, तो GCP सेवा खाते से जुड़ी सभी कुंजियों का इस्तेमाल करके टोकन की पुष्टि करने की कोशिश करेगा. अगर कोई मान्य कुंजी नहीं मिलती है, तो टोकन को अस्वीकार कर दिया जाएगा. 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": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
अन्य दावे

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

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

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

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

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 ऑथराइज़ेशन सर्वर, सिर्फ़ 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":"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 को कॉल करने के लिए, 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 में, क्लाइंट आईडी (संख्या) के बजाय क्लाइंट के ईमेल पते का इस्तेमाल करके सेवा खाते को अनुमति दी गई थी. Admin console में, पूरे डोमेन के लिए उपयोगकर्ता की भूमिका सौंपना पेज पर जाकर, क्लाइंट को हटाएं और उसे संख्या वाले आईडी के साथ फिर से जोड़ें.
access_denied (कोई भी वैल्यू) अगर डोमेन-वाइड डेलिगेशन का इस्तेमाल किया जा रहा है, तो Admin console में अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दी गई है.

पक्का करें कि सेवा खाते को Admin console के डोमेन-वाइड डेलिगेशन पेज पर, sub दावे (फ़ील्ड) में मौजूद उपयोगकर्ता के लिए अनुमति मिली हो. साथ ही, इसमें वे सभी स्कोप शामिल हों जिनके लिए आपने अपने JWT के scope दावे में अनुरोध किया है.

आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके 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. उपयोगकर्ता मौजूद नहीं है. देखें कि 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 डेटाबेस में पब्लिश की गई है, तो ऐक्सेस टोकन के बजाय JWT का इस्तेमाल करके, अनुमति वाले एपीआई कॉल किए जा सकते हैं. इसके लिए:

  1. ऊपर बताए गए तरीके से, एक सेवा खाता बनाएं. खाता बनाते समय मिली JSON फ़ाइल को सुरक्षित रखें.
  2. 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 फ़ील्ड के लिए, ठीक 3,600 सेकंड बाद का समय बताएं, जब 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("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')
  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 का इस्तेमाल करके, Cross-Account Protection लागू करें. इस सेवा की मदद से, सुरक्षा से जुड़ी घटनाओं की सूचनाएं पाने के लिए सदस्यता ली जा सकती है. इससे आपके ऐप्लिकेशन को, उपयोगकर्ता के खाते में हुए बड़े बदलावों के बारे में जानकारी मिलती है. इसके बाद, इस जानकारी का इस्तेमाल करके कार्रवाई की जा सकती है. यह इस बात पर निर्भर करता है कि आपको इवेंट का जवाब कैसे देना है.

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

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