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में ये क्रेडेंशियल पाने होंगे. सेवा खाते के क्रेडेंशियल जनरेट करने या पहले से जनरेट किए गए सार्वजनिक क्रेडेंशियल देखने के लिए, यह तरीका अपनाएं:
सबसे पहले, एक सेवा खाता बनाएँ:
- Service accounts pageखोलें।
- If prompted, select a project, or create a new one.
- क्रिएट सर्विस अकाउंट पर क्लिक करें।
- सेवा खाते के विवरण के तहत, सेवा खाते के लिए एक नाम, आईडी और विवरण टाइप करें, फिर बनाएं और जारी रखें पर क्लिक करें।
- वैकल्पिक: इस सेवा खाते को प्रोजेक्ट तक पहुंच प्रदान करें के अंतर्गत, सेवा खाते को प्रदान करने के लिए IAM भूमिकाएं चुनें.
- जारी रखें पर क्लिक करें।
- वैकल्पिक: उपयोगकर्ताओं को इस सेवा खाते तक पहुंच प्रदान करें के तहत, उन उपयोगकर्ताओं या समूहों को जोड़ें जिन्हें सेवा खाते का उपयोग और प्रबंधन करने की अनुमति है।
- हो गया क्लिक करें.
अगला, एक सेवा खाता कुंजी बनाएँ:
- आपके द्वारा बनाए गए सेवा खाते के ईमेल पते पर क्लिक करें।
- कुंजी टैब पर क्लिक करें।
- कुंजी जोड़ें ड्रॉप-डाउन सूची में, नई कुंजी बनाएं चुनें.
- क्रिएट पर क्लिक करें ।
आपकी नई सार्वजनिक/निजी कुंजी जोड़ी तैयार की जाती है और आपकी मशीन पर डाउनलोड की जाती है; यह निजी कुंजी की एकमात्र प्रति के रूप में कार्य करता है। आप इसे सुरक्षित रूप से संग्रहीत करने के लिए जिम्मेदार हैं। यदि आप इस कुंजी जोड़ी को खो देते हैं, तो आपको एक नया बनाना होगा।
ज़्यादा जानने के लिए, सेवा खाते की कुंजियों को मैनेज करने के सबसे सही तरीके लेख पढ़ें.
ईमेल पता, सार्वजनिक कुंजी के फ़िंगरप्रिंट, और अन्य जानकारी देखने के लिए, किसी भी समय API Console पर वापस जाएं. इसके अलावा, सार्वजनिक/निजी कोड के अन्य जोड़े जनरेट करने के लिए भी इस पर वापस जाएं. API Consoleमें सेवा खाते के क्रेडेंशियल के बारे में ज़्यादा जानने के लिए, API Consoleकी सहायता फ़ाइल में सेवा खाते देखें.
सेवा खाते के ईमेल पते को नोट करें. साथ ही, सेवा खाते की निजी पासकोड फ़ाइल को किसी ऐसी जगह पर सेव करें जहां से आपका ऐप्लिकेशन इसे ऐक्सेस कर सके. आपके ऐप्लिकेशन को अनुमति वाले एपीआई कॉल करने के लिए इनकी ज़रूरत होती है.
सेवा खाते को डोमेन-वाइड अथॉरिटी सौंपना
Google Workspace खाते का इस्तेमाल करके, संगठन का Workspace एडमिन किसी ऐप्लिकेशन को Google Workspace डोमेन में मौजूद उपयोगकर्ताओं की ओर से, Workspace उपयोगकर्ता डेटा ऐक्सेस करने की अनुमति दे सकता है. उदाहरण के लिए, Google Calendar API का इस्तेमाल करने वाला कोई ऐप्लिकेशन, Google Workspace डोमेन में मौजूद सभी उपयोगकर्ताओं के कैलेंडर में इवेंट जोड़ने के लिए, सेवा खाते का इस्तेमाल करेगा. किसी सेवा खाते को डोमेन के उपयोगकर्ताओं की ओर से डेटा ऐक्सेस करने की अनुमति देने को, कभी-कभी सेवा खाते को "डोमेन-वाइड अथॉरिटी सौंपना" कहा जाता है.
किसी सेवा खाते को पूरे डोमेन पर अनुमति देने के लिए, Google Workspace डोमेन के सुपर एडमिन को यह तरीका अपनाना होगा:
- अपने Google Workspace डोमेन के Admin console में जाकर, मुख्य मेन्यू > सुरक्षा > ऐक्सेस और डेटा कंट्रोल > एपीआई कंट्रोल पर जाएं.
- पूरे डोमेन के लिए डेटा का ऐक्सेस दें पैनल में, पूरे डोमेन के लिए डेटा का ऐक्सेस मैनेज करें को चुनें.
- नया जोड़ें पर क्लिक करें.
- क्लाइंट आईडी फ़ील्ड में, सेवा खाते का क्लाइंट आईडी डालें. आपको अपने सेवा खाते का क्लाइंट आईडी, Service accounts pageमें मिल सकता है.
- OAuth स्कोप (कॉमा लगाकर अलग किए गए) फ़ील्ड में, उन स्कोप की सूची डालें जिनका ऐक्सेस आपके ऐप्लिकेशन को दिया जाना चाहिए. उदाहरण के लिए, अगर आपके ऐप्लिकेशन को Google Drive API और Google Calendar API के लिए, पूरे डोमेन का पूरा ऐक्सेस चाहिए, तो यह डालें: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
- अनुमति दें पर क्लिक करें.
अब आपके ऐप्लिकेशन के पास, आपके 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 पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो इसके बजाय ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल किया जा सकता है. इससे प्रोसेस को आसान बनाया जा सकता है.
पूरे डोमेन के लिए, ऐक्सेस करने का अधिकार सौंपना
अगर आपने सेवा खाते को डोमेन-वाइड ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो GoogleCredentials ऑब्जेक्ट के createDelegated तरीके का इस्तेमाल करके, उपयोगकर्ता खाते का ईमेल पता डालें. उदाहरण के लिए:
GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream("MyProject-1234.json")) .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN)) .createDelegated("[email protected]");
createDelegated() तरीके को कॉल करने के लिए, GoogleCredentials ऑब्जेक्ट का इस्तेमाल किया जाता है. createDelegated() तरीके के लिए, तर्क ऐसा उपयोगकर्ता होना चाहिए जो आपके Workspace खाते से जुड़ा हो. अनुरोध करने वाला आपका कोड, इस क्रेडेंशियल का इस्तेमाल करके Google API को कॉल करेगा. इसके लिए, वह आपके सेवा खाते का इस्तेमाल करेगा.
Python
API Consoleसे क्लाइंट का ईमेल पता और निजी पासकोड पाने के बाद, 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 पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो इसके बजाय ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल किया जा सकता है. इससे प्रोसेस को आसान बनाया जा सकता है.
- पूरे डोमेन के लिए, ऐक्सेस करने का अधिकार सौंपना
अगर आपने सेवा खाते को डोमेन-वाइड ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के तौर पर काम करना है, तो मौजूदा
with_subjectऑब्जेक्ट केwith_subjectतरीके का इस्तेमाल करें.ServiceAccountCredentialsउदाहरण के लिए:delegated_credentials = credentials.with_subject('[email protected]')
अपने ऐप्लिकेशन में Google API को कॉल करने के लिए, क्रेडेंशियल ऑब्जेक्ट का इस्तेमाल करें.
एचटीटीपी/रेस्ट
API Consoleसे क्लाइंट आईडी और निजी कुंजी पाने के बाद, आपके ऐप्लिकेशन को यह तरीका अपनाना होगा:
- एक JSON Web Token (JWT, जिसे "जॉट" कहा जाता है) बनाएं. इसमें हेडर, दावा सेट, और हस्ताक्षर शामिल हो.
- Google OAuth 2.0 ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन का अनुरोध करें.
- ऑथराइज़ेशन सर्वर से मिले JSON रिस्पॉन्स को मैनेज करें.
यहां दिए गए सेक्शन में, इन चरणों को पूरा करने का तरीका बताया गया है.
अगर रिस्पॉन्स में ऐक्सेस टोकन शामिल है, तो Google API को कॉल करने के लिए, ऐक्सेस टोकन का इस्तेमाल किया जा सकता है. (अगर जवाब में ऐक्सेस टोकन शामिल नहीं है, तो हो सकता है कि आपका 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 हेडर बनाना
हेडर में दो ज़रूरी फ़ील्ड होते हैं: हस्ताक्षर करने का एल्गोरिदम और दावे का फ़ॉर्मैट. साथ ही, एक वैकल्पिक कुंजी आईडी होता है:
- Algorithm एट्रिब्यूट की वैल्यू देना ज़रूरी है. इसकी सिर्फ़ एक वैल्यू होती है:
"alg": "RS256". - फ़ॉर्मैट की जानकारी देना ज़रूरी है. इसकी सिर्फ़ एक वैल्यू होती है:
"typ": "JWT". - कुंजी आईडी देना ज़रूरी नहीं है. यह JWT पर हस्ताक्षर करने के लिए इस्तेमाल की गई सेवा खाते की कुंजी का आईडी होता है. अगर गलत कुंजी आईडी दिया जाता है, तो सेवा खाते से जुड़ी सभी कुंजियों का इस्तेमाल किया जाता है. अगर कोई मान्य कुंजी नहीं मिलती है, तो टोकन अस्वीकार कर दिया जाता है. Google के पास, गलत कुंजी आईडी वाले टोकन अस्वीकार करने का अधिकार है.
सेवा खाते, RSA SHA-256 एल्गोरिदम और JWT टोकन फ़ॉर्मैट पर निर्भर करते हैं. इस वजह से, हेडर का JSON कोड इस तरह दिखता है:
{"alg":"RS256","typ":"JWT", "kid":"370ab79b4513eb9bad7c9bd16a95cb76b5b2a56a"}
इसका Base64url फ़ॉर्मैट यह है:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=
JWT का दावा करने वाला सेट बनाएं
जेडब्ल्यूटी के दावे वाले सेट में, जेडब्ल्यूटी के बारे में जानकारी होती है. इसमें अनुरोध की जा रही अनुमतियां (स्कोप), टोकन का टारगेट, जारी करने वाला, टोकन जारी करने का समय, और टोकन की लाइफ़टाइम शामिल होती है. ज़्यादातर फ़ील्ड में जानकारी डालना ज़रूरी है. JWT हेडर की तरह, JWT क्लेम सेट भी एक JSON ऑब्जेक्ट होता है. इसका इस्तेमाल सिग्नेचर की गिनती में किया जाता है.
ज़रूरी दावे
JWT के दावे वाले सेट में ज़रूरी दावे, किसी भी क्रम में दिख सकते हैं.
| नाम | ब्यौरा |
|---|---|
iss | सेवा खाते का ईमेल पता. |
scope | ऐप्लिकेशन जिन अनुमतियों का अनुरोध करता है उनकी सूची. इस सूची में अनुमतियों के नामों के बीच में खाली जगह का इस्तेमाल किया जाता है. |
aud | यह पुष्टि किए जाने वाले टारगेट का डेस्क्रिप्टर है. ऐक्सेस टोकन का अनुरोध करते समय, यह वैल्यू हमेशा https://oauth2.googleapis.com/token होती है. |
exp | यह असर्शन के खत्म होने का समय है. इसे 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या के तौर पर दिखाया जाता है. यह वैल्यू, जारी किए जाने के समय के बाद ज़्यादा से ज़्यादा एक घंटे तक मान्य रहती है. |
iat | दावा जारी किए जाने का समय. इसे 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या के तौर पर दिखाया जाता है. |
यहां JWT के दावे वाले सेट में ज़रूरी फ़ील्ड के JSON फ़ॉर्मैट का उदाहरण दिया गया है:
{ "iss": "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": "[email protected]", "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 वैल्यू में बताई गई अवधि के दौरान, ऐक्सेस टोकन का फिर से इस्तेमाल किया जा सकता है.
सुरक्षा से जुड़ी अहम जानकारी: किसी और के नाम पर काम करने के बारे में जानकारी
डोमेन-वाइड अथॉरिटी सौंपने का मतलब यह नहीं है कि आपने सेवा खाते को सभी उपयोगकर्ताओं के डेटा का ऐक्सेस दे दिया है. इसके बजाय, एपीआई कॉल करते समय, इसे कुछ उपयोगकर्ताओं के तौर पर काम करने की अनुमति दी जाती है.- उपयोगकर्ता की ओर से ऐक्सेस करना: आपके ऐप्लिकेशन को हर एपीआई अनुरोध के लिए, यह बताना होगा कि किस उपयोगकर्ता के तौर पर काम करना है. इसके बाद, ऐप्लिकेशन उस उपयोगकर्ता की अनुमतियों के साथ काम करता है. यह किसी भी तरह के डोमेन-वाइड विशेषाधिकारों के साथ काम नहीं करता.
- अनुमतियां सीमित होती हैं: सेवा खाते का ऐक्सेस दो बातों पर निर्भर करता है: उपयोगकर्ता की अनुमतियां और Admin console में आपके दिए गए OAuth स्कोप. यह उस डेटा को ऐक्सेस नहीं कर सकता जिसे उपयोगकर्ता खुद ऐक्सेस नहीं कर सकता.
- कम से कम विशेषाधिकार का सिद्धांत: यह सुविधा, उपयोगकर्ताओं की सीधी सहमति के बिना उनके डेटा को ऐक्सेस करने की अनुमति देती है. इसलिए, सुरक्षा के सबसे सही तरीकों का पालन करना ज़रूरी है. सिर्फ़ ज़रूरी OAuth स्कोप की अनुमति दें. साथ ही, यह पक्का करें कि आपको सुरक्षा से जुड़ी समस्याओं के बारे में पता हो.
Google API को कॉल करना
Java
Google API को कॉल करने के लिए, GoogleCredentials ऑब्जेक्ट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:
GoogleCredentialsऑब्जेक्ट का इस्तेमाल करके, उस एपीआई के लिए एक सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. उदाहरण के लिए:SQLAdmin sqladmin = new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credentials).build();
- सेवा ऑब्जेक्ट की ओर से उपलब्ध कराए गए इंटरफ़ेस का इस्तेमाल करके, एपीआई सेवा से अनुरोध करें. उदाहरण के लिए, exciting-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस की सूची बनाने के लिए:
SQLAdmin.Instances.List instances = sqladmin.instances().list("exciting-example-123").execute();
Python
Google API को कॉल करने के लिए, अनुमति वाले Credentials ऑब्जेक्ट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:
- उस एपीआई के लिए एक सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. एपीआई के नाम और वर्शन के साथ-साथ, अनुमति वाले
Credentialsऑब्जेक्ट का इस्तेमाल करके,buildफ़ंक्शन को कॉल करके एक सेवा ऑब्जेक्ट बनाया जाता है. उदाहरण के लिए, Cloud SQL Administration API के वर्शन 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()
एचटीटीपी/रेस्ट
जब आपका ऐप्लिकेशन ऐक्सेस टोकन पा लेता है, तब आपके पास इस टोकन का इस्तेमाल करके, किसी सेवा खाते या उपयोगकर्ता खाते की ओर से 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 के डोमेन-वाइड डेलिगेशन पेज पर, आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके 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 के डोमेन-वाइड डेलिगेशन पेज पर, पुष्टि करें कि Google की सेवाओं का ऐक्सेस प्रतिबंधित नहीं है. इसके लिए, उन सेवाओं के ऐक्सेस को मैनेज करना जो अलग से कंट्रोल नहीं की जातीं लेख पढ़ें. आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके Google खाते के सभी उपयोगकर्ताओं के लिए अनुमति लागू होने में 24 घंटे लग सकते हैं. |
admin_policy_enforced | (कोई भी वैल्यू) | Google Workspace एडमिन की नीतियों की वजह से, Google खाता अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे सकता. | Google Workspace एडमिन के लिए सहायता लेख यह कंट्रोल करना कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले किन ऐप्लिकेशन की मदद से Google Workspace के डेटा को ऐक्सेस किया जा सकता है पढ़ें. इसमें इस बारे में ज़्यादा जानकारी दी गई है कि एडमिन, सभी स्कोप या संवेदनशील और प्रतिबंधित स्कोप के ऐक्सेस को तब तक सीमित कैसे कर सकता है, जब तक आपके OAuth क्लाइंट आईडी को साफ़ तौर पर ऐक्सेस करने की अनुमति नहीं दी जाती. |
invalid_client | (कोई भी वैल्यू) | OAuth क्लाइंट या JWT टोकन अमान्य है या उसे गलत तरीके से कॉन्फ़िगर किया गया है. ज़्यादा जानकारी के लिए, गड़बड़ी का ब्यौरा देखें. | पक्का करें कि JWT टोकन मान्य हो और उसमें सही दावे शामिल हों. जांच करें कि OAuth क्लाइंट और सेवा खाता सही तरीके से कॉन्फ़िगर किए गए हों. यह भी पक्का करें कि आपने सही ईमेल पते का इस्तेमाल किया हो. जांच करें कि जेडब्ल्यूटी टोकन सही हो और अनुरोध में दिए गए क्लाइंट आईडी के लिए जारी किया गया हो. |
deleted_client | (कोई भी वैल्यू) | अनुरोध करने के लिए इस्तेमाल किए जा रहे OAuth क्लाइंट को मिटा दिया गया है. इस्तेमाल न किए गए क्लाइंट के मामले में, उन्हें मैन्युअल तरीके से या अपने-आप मिटाया जा सकता है. मिटाए गए क्लाइंट को मिटाने के 30 दिनों के अंदर वापस लाया जा सकता है. ज़्यादा जानें. | ऐसे क्लाइंट आईडी का इस्तेमाल करें जो अब भी चालू हो. |
invalid_grant | Not a valid email या Invalid email or User ID. | उपयोगकर्ता मौजूद नहीं है. | देखें कि sub दावे (फ़ील्ड) में दिया गया ईमेल पता सही हो. |
invalid_grant |
| आम तौर पर, इसका मतलब है कि लोकल सिस्टम का समय सही नहीं है. ऐसा तब भी हो सकता है, जब 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 का ध्यान दें कि |
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 का इस्तेमाल करके, अनुमति वाले एपीआई कॉल किए जा सकते हैं. इसके लिए:
- सेवा खाता बनाएं. खाता बनाते समय मिली JSON फ़ाइल को सुरक्षित रखें.
- jwt.io पर मौजूद किसी भी स्टैंडर्ड JWT लाइब्रेरी का इस्तेमाल करके, हेडर और पेलोड वाला JWT बनाएं. जैसे, यहां दिए गए उदाहरण में दिखाया गया है:
{ "alg": "RS256", "typ": "JWT", "kid": "abcdef1234567890" } . { "iss": "[email protected]", "sub": "[email protected]", "aud": "https://firestore.googleapis.com/", "iat": 1511900000, "exp": 1511903600 }
- हेडर में मौजूद
kidफ़ील्ड के लिए, अपने सेवा खाते के निजी पासकोड का आईडी डालें. यह वैल्यू, आपको सेवा खाते की JSON फ़ाइल केprivate_key_idफ़ील्ड में मिल सकती है. issऔरsubफ़ील्ड के लिए, अपने सेवा खाते का ईमेल पता डालें. यह वैल्यू, आपको सेवा खाते की JSON फ़ाइल केclient_emailफ़ील्ड में मिल सकती है. इस वैल्यू से क्लाइंट की पहचान की जाती है. यह क्लाइंट आईडी की तरह काम करती है.audफ़ील्ड के लिए, एपीआई एंडपॉइंट की जानकारी दें. उदाहरण के लिए:https://SERVICE.googleapis.com/.iatफ़ील्ड के लिए, मौजूदा Unix epoch टाइम बताएं. साथ ही,expफ़ील्ड के लिए, ठीक 3600 सेकंड बाद का समय बताएं, जब JWT की समयसीमा खत्म हो जाएगी.
अपने सेवा खाते की JSON फ़ाइल में मौजूद निजी कुंजी का इस्तेमाल करके, JWT पर RSA-256 से हस्ताक्षर करें.
उदाहरण के लिए:
Java
google-auth-library-java और java-jwt का इस्तेमाल करके:
import com.google.auth.oauth2.ServiceAccountCredentials; ... GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream("MyProject-1234.json")); PrivateKey privateKey = ((ServiceAccountCredentials) credentials).getPrivateKey(); String privateKeyId = ((ServiceAccountCredentials) credentials).getPrivateKeyId(); long now = System.currentTimeMillis(); try { Algorithm algorithm = Algorithm.RSA256(null, privateKey); String signedJwt = JWT.create() .withKeyId(privateKeyId) .withIssuer("[email protected]") .withSubject("[email protected]") .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': '[email protected]', 'sub': '[email protected]', '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 की 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
सभी खातों की सुरक्षा की सुविधा लागू करने के तरीके और उपलब्ध इवेंट की पूरी सूची के बारे में ज़्यादा जानने के लिए, सभी खातों की सुरक्षा की सुविधा की मदद से उपयोगकर्ता खातों को सुरक्षित रखें पेज देखें.