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

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

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

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

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

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

आपके ऐप्लिकेशन को अब अपने डोमेन में उपयोगकर्ताओं के रूप में API कॉल करने का अधिकार है ("उपयोगकर्ताओं का प्रतिरूपण" करने के लिए). जब आप एपीआई कॉल की अनुमति देने के लिए तैयार होते हैं, तब आप उपयोगकर्ता के नाम पर काम करने की जानकारी देते हैं.

आधिकारिक एपीआई कॉल करने की तैयारी की जा रही है

Java

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

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("user@example.com");

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

Python

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

  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. पूरे डोमेन के लिए डेलिगेट करें

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

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

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

एचटीटीपी/REST

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

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

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

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

जब ऐक्सेस टोकन समय-सीमा खत्म हो जाती है, तब आपका ऐप्लिकेशन एक और 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 हेडर बनाना

हेडर में दो फ़ील्ड होते हैं, जो हस्ताक्षर के एल्गोरिदम और दावे के फ़ॉर्मैट की जानकारी देते हैं. दोनों फ़ील्ड ज़रूरी हैं और हर फ़ील्ड की सिर्फ़ एक वैल्यू होती है. जैसे-जैसे अतिरिक्त एल्गोरिदम और फ़ॉर्मैट लॉन्च किए जाएंगे, वैसे-वैसे हेडर में भी बदलाव होगा.

सेवा खाते, RSA SHA-256 एल्गोरिदम और JWT टोकन प्रारूप पर निर्भर करते हैं. नतीजे के तौर पर, हेडर को JSON के तौर पर दिखाने का तरीका यहां बताया गया है:

{"alg":"RS256","typ":"JWT"}

इस Base64url का प्रतिनिधित्व इस तरह है:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
JWT दावा सेट बनाना

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

ज़रूरी दावे

JWT दावे के सेट में ज़रूरी दावे नीचे दिखाए गए हैं. ये दावे सेट में किसी भी क्रम में दिख सकते हैं.

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

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 फ़ील्ड शामिल है.

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

{
  "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-सुरक्षित कोड में बदला गया होना चाहिए. 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 हैशिंग एल्गोरिदम का इस्तेमाल करने वाला आरएसए है. JWT हेडर के alg फ़ील्ड में, इसे RS256 के तौर पर दिखाया जाता है.

Google API Consoleसे मिली निजी कुंजी से SHA256withRSA (जिसे SHA-256 हैश फ़ंक्शन का इस्तेमाल करके RSASSA-MARGIN1-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 के एपीआई को कॉल करने के लिए, GoogleCredential ऑब्जेक्ट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

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

Python

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

  1. एपीआई के लिए ऐसा सर्विस ऑब्जेक्ट बनाएं जिसे कॉल करना है. एपीआई फ़ंक्शन के नाम और वर्शन के साथ build फ़ंक्शन और Credentials ऑब्जेक्ट को कॉल करके, सेवा ऑब्जेक्ट बनाया जाता है. उदाहरण के लिए, Cloud SQL एडमिन एपीआई के 1बीटा3 वर्शन को कॉल करने के लिए:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. सेवा ऑब्जेक्ट से मिले इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा के लिए अनुरोध करें. उदाहरण के लिए, example-123 के रोमांचक प्रोजेक्ट में, Cloud SQL डेटाबेस के इंस्टेंस दिए गए हैं:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

एचटीटीपी/REST

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

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

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

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

जब ऐक्सेस टोकन की समयसीमा खत्म हो जाती है

expires_in की ओर से दी गई अवधि के बाद, Google OAuth 2.0 के ऑथराइज़ेशन सर्वर से जारी किए गए ऐक्सेस टोकन की समयसीमा खत्म हो जाती है. जब ऐक्सेस टोकन की समयसीमा खत्म हो जाती है, तब ऐप्लिकेशन को एक और 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 दावे पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी बंद है.

Google API Consoleपर जाएं और IAM और एडमिन > सेवा खाते में जाकर, उस सेवा खाते को चालू करें जिसमें दावे पर हस्ताक्षर करने के लिए, "कुंजी आईडी" इस्तेमाल किया गया है.

org_internal This client is restricted to users within its organization. अनुरोध में मौजूद OAuth क्लाइंट आईडी, ऐसे प्रोजेक्ट का हिस्सा है जो Google Cloud के किसी खास संगठन में, Google खातों को ऐक्सेस नहीं करता.

पुष्टि करने के लिए, संगठन से मिले सेवा खाते का इस्तेमाल करें. अपने OAuth ऐप्लिकेशन के लिए, उपयोगकर्ता टाइप कॉन्फ़िगरेशन की पुष्टि करें.

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

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

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

  1. ऊपर बताए गए तरीके से सेवा खाता बनाएं. खाता बनाते समय मिलने वाली JSON फ़ाइल को ज़रूर रखें.
  2. किसी भी सामान्य JWT लाइब्रेरी, जैसे कि jwt.io पर मौजूद का इस्तेमाल करके, एक हेडर और पेलोड के साथ एक 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 फ़ील्ड के लिए, Unix के मौजूदा समय के बारे में बताएं. साथ ही, exp फ़ील्ड के लिए जेडब्ल्यूटी की समयसीमा खत्म होने के 3,600 सेकंड बाद का समय बताएं.

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

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

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')
  1. एपीआई में कॉल करें और साइन किए गए JWT को बेयर टोकन के तौर पर इस्तेमाल करें:
    GET /v1/projects/abc/databases/123/indexes HTTP/1.1
    Authorization: Bearer SIGNED_JWT
    Host: firestore.googleapis.com