सर्वर से सर्वर ऐप्लिकेशन के लिए 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में ये क्रेडेंशियल पाने होंगे. सेवा खाते के क्रेडेंशियल जनरेट करने या पहले से जनरेट किए गए सार्वजनिक क्रेडेंशियल देखने के लिए, यह तरीका अपनाएं:

First, create a service account:

1. Open the Service accounts page.
2. If prompted, select a project, or create a new one.
3. Click add Create service account.
4. Under Service account details, type a name, ID, and description for the service account, then click Create and continue.
5. Optional: Under Grant this service account access to project, select the IAM roles to grant to the service account.
6. Click Continue.
7. Optional: Under Grant users access to this service account, add the users or groups that are allowed to use and manage the service account.
8. Click Done.

Next, create a service account key:

1. Click the email address for the service account you created.
2. Click the Keys tab.
3. In the Add key drop-down list, select Create new key.
4. Click Create.

Your new public/private key pair is generated and downloaded to your machine; it serves as the only copy of the private key. You are responsible for storing it securely. If you lose this key pair, you will need to generate a new one.

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

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

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

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

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

1. अपने Google Workspace डोमेन के Admin console में, मुख्य मेन्यू menu > सुरक्षा > ऐक्सेस और डेटा कंट्रोल > एपीआई कंट्रोल पर जाएं.
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से क्लाइंट ईमेल पता और निजी कुंजी पाने के बाद, सेवा खाते के क्रेडेंशियल और उन स्कोप से 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

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. पूरे डोमेन के लिए ऐक्सेस देना

   अगर आपने सेवा खाते को डोमेन के सभी खातों का ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो किसी मौजूदा 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 और टोकन अनुरोध सही तरीके से न बनाया गया हो या सेवा खाते के पास, अनुरोध किए गए स्कोप को ऐक्सेस करने की अनुमति न हो.)

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

इस सेक्शन के बाकी हिस्से में, 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 हैश फ़ंक्शन का इस्तेमाल किया जाता है. साथ ही, Google API Consoleसे मिली निजी कुंजी का इस्तेमाल करें. आउटपुट, बाइट ऐरे के तौर पर होगा.

इसके बाद, हस्ताक्षर को 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 को कॉल करना

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

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

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

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

अतिरिक्त जानकारी: 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 फ़ील्ड के लिए, 3600 सेकंड बाद का समय बताएं, जब JWT की समयसीमा खत्म हो जाएगी.

अपने सेवा खाते की JSON फ़ाइल में मौजूद निजी कुंजी का इस्तेमाल करके, RSA-256 के साथ 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 ...

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

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

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