Google OAuth 2.0 सिस्टम, सर्वर-टू-सर्वर इंटरैक्शन के साथ काम करता है. जैसे, वेब ऐप्लिकेशन और Google सेवा के बीच होने वाले इंटरैक्शन. इस स्थिति में, आपको एक सेवा खाते की ज़रूरत होगी. यह खाता एक ऐसा खाता होता है जो किसी असली उपयोगकर्ता के बजाय, आपके ऐप्लिकेशन से जुड़ा हो. आपका ऐप्लिकेशन, सेवा खाते की ओर से Google API को कॉल करता है. इसलिए, इसमें उपयोगकर्ता सीधे तौर पर शामिल नहीं होते हैं. इस स्थिति को कभी-कभी "दो पैरों वाला OAuth" या "2LO" कहा जाता है. (इससे मिलता-जुलता शब्द "तीन पैरों वाला OAuth"" का मतलब उन स्थितियों में है जिनमें आपका ऐप्लिकेशन असली उपयोगकर्ताओं की ओर से Google API को कॉल करता है और जिनमें कभी-कभी उपयोगकर्ता की सहमति ज़रूरी होती है.)
आम तौर पर, जब कोई ऐप्लिकेशन उपयोगकर्ता के डेटा के बजाय अपने डेटा के साथ Google API का इस्तेमाल करता है, तो उस ऐप्लिकेशन के लिए सेवा खाते का इस्तेमाल किया जाता है. उदाहरण के लिए, जो ऐप्लिकेशन डेटा को बनाए रखने के लिए Google Cloud Datastore का इस्तेमाल करता है उसे Google Cloud Datastore API पर कॉल की पुष्टि करने के लिए, सेवा खाते का इस्तेमाल करना होगा.
Google Workspace के डोमेन एडमिन, सेवा खातों के लिए पूरे डोमेन पर अनुमति देने की सुविधा भी दे सकते हैं. ऐसा करके, वे डोमेन के उपयोगकर्ताओं का डेटा ऐक्सेस कर सकते हैं.
इस दस्तावेज़ में बताया गया है कि कोई ऐप्लिकेशन, Google API क्लाइंट लाइब्रेरी (सुझाया गया) या एचटीटीपी का इस्तेमाल करके, सर्वर-टू-सर्वर 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 Workspace डोमेन के सभी उपयोगकर्ताओं के कैलेंडर में इवेंट जोड़ने के लिए, Google Calendar API का इस्तेमाल करता है, तो उपयोगकर्ताओं की ओर से Google Calendar API ऐक्सेस करने के लिए, वह सेवा खाते का इस्तेमाल करेगा. किसी डोमेन के उपयोगकर्ताओं की ओर से डेटा ऐक्सेस करने के लिए किसी सेवा खाते को अनुमति देना, कभी-कभी सेवा खाते को "पूरे डोमेन का अधिकार सौंपना" कहा जाता है.
पूरे डोमेन का अधिकार किसी सेवा खाते को देने के लिए, Google Workspace डोमेन के सुपर एडमिन को नीचे दिए गए चरण पूरे करने होंगे:
- अपने Google Workspace डोमेन के Admin console में, मुख्य मेन्यू > सुरक्षा > ऐक्सेस और डेटा कंट्रोल > एपीआई कंट्रोल पर जाएं.
- डोमेन वाइड डेलिगेशन पैनल में, डोमेन वाइड डेलिगेशन मैनेज करें चुनें.
- नया आइटम जोड़ें पर क्लिक करें.
- Client-ID फ़ील्ड में, सेवा खाते का Client-ID डालें. आपको 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से क्लाइंट ईमेल पता और निजी कुंजी मिलने के बाद,
Java के लिए Google API क्लाइंट लाइब्रेरी का इस्तेमाल करके, सेवा खाते के क्रेडेंशियल और
उन दायरों से GoogleCredential
ऑब्जेक्ट बनाएं जिनका ऐक्सेस आपके ऐप्लिकेशन को चाहिए. उदाहरण के लिए:
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");
ऊपर दिया गया कोड, GoogleCredential
ऑब्जेक्ट का इस्तेमाल अपने createDelegated()
तरीके को कॉल करने के लिए करता है. createDelegated()
तरीके का तर्क, आपके
Workspace खाते से जुड़ा उपयोगकर्ता होना चाहिए. अनुरोध करने पर, आपका कोड इस क्रेडेंशियल का इस्तेमाल करके, आपके सेवा खाते का इस्तेमाल करके Google
API को कॉल करेगा.
Python
API Consoleसे क्लाइंट ईमेल पता और निजी कुंजी पाने के बाद, Python के लिए Google API क्लाइंट लाइब्रेरी का इस्तेमाल करके, ये चरण पूरे करें:
- सेवा खाते के क्रेडेंशियल और उन स्कोप
की मदद से
Credentials
ऑब्जेक्ट बनाएं जिनका ऐक्सेस आपके ऐप्लिकेशन को चाहिए. उदाहरण के लिए:from google.oauth2 import service_account SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin'] SERVICE_ACCOUNT_FILE = '/path/to/service.json' credentials = service_account.Credentials.from_service_account_file( SERVICE_ACCOUNT_FILE, scopes=SCOPES)
अगर Google Cloud Platform पर कोई ऐप्लिकेशन डेवलप किया जा रहा है, तो आपके पास ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल करने का विकल्प है. इससे, यह प्रोसेस आसान हो सकती है.
- पूरे डोमेन के अधिकार सौंपना
अगर आपने सेवा खाते के लिए पूरे डोमेन का ऐक्सेस दिया है और आपको किसी उपयोगकर्ता खाते के नाम पर काम करना है, तो मौजूदा
ServiceAccountCredentials
ऑब्जेक्ट के लिएwith_subject
तरीके का इस्तेमाल करें. उदाहरण के लिए:delegated_credentials = credentials.with_subject('user@example.org')
अपने ऐप्लिकेशन में Google API को कॉल करने के लिए, क्रेडेंशियल ऑब्जेक्ट का इस्तेमाल करें.
एचटीटीपी/REST
API Consoleसे क्लाइंट आईडी और निजी कुंजी मिलने के बाद, आपके ऐप्लिकेशन को ये चरण पूरे करने होंगे:
- एक ऐसा JSON वेब टोकन (JWT, उच्चारण का चिह्न, "jot") बनाएं जिसमें हेडर, क्लेम सेट, और हस्ताक्षर शामिल हों.
- Google OAuth 2.0 ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन का अनुरोध करें.
- ऑथराइज़ेशन सर्वर से मिलने वाले 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 हेडर बनाना
हेडर में तीन फ़ील्ड होते हैं, जो हस्ताक्षर एल्गोरिदम, दावे के फ़ॉर्मैट, और [सेवा खाता कुंजी के कुंजी आईडी](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) के बारे में बताते हैं. इसका इस्तेमाल JWT पर हस्ताक्षर करने के लिए किया गया था. एल्गोरिदम और फ़ॉर्मैट ज़रूरी हैं. साथ ही, हर फ़ील्ड में सिर्फ़ एक वैल्यू होती है. जैसे-जैसे अतिरिक्त एल्गोरिदम और फ़ॉर्मैट जोड़े जाएंगे, यह हेडर उसके हिसाब से बदल जाएगा. कुंजी आईडी ज़रूरी नहीं है. अगर GCP पर किसी गलत कुंजी आईडी का इस्तेमाल किया जाता है, तो सेवा खाते से जुड़ी सभी कुंजियों की मदद से टोकन की पुष्टि की जाएगी. साथ ही, कोई मान्य कुंजी न मिलने पर टोकन को अस्वीकार कर दिया जाएगा. Google के पास यह अधिकार है कि वह आने वाले समय में, गलत कुंजी आईडी वाले टोकन को अस्वीकार कर सकता है.
सेवा खाते, आरएसए 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 |
दावे की समयसीमा खत्म होने का समय, जिसे 00:00:00 यूटीसी के बाद से सेकंड के तौर पर बताया गया है, 1 जनवरी, 1970 को. इस वैल्यू में, जारी किए गए समय के बाद ज़्यादा से ज़्यादा एक घंटे का समय होता है. |
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
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-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 Web Signature (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 हैश फ़ंक्शन के साथ आरएसएएसएसए-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 को कॉल करने के लिए, GoogleCredential
ऑब्जेक्ट का इस्तेमाल करें. इसके लिए,
यह तरीका अपनाएं:
- उस एपीआई के लिए सर्विस ऑब्जेक्ट बनाएं जिसे आपको
GoogleCredential
ऑब्जेक्ट का इस्तेमाल करके कॉल करना है. उदाहरण के लिए:SQLAdmin sqladmin = new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
- सर्विस ऑब्जेक्ट से मिले इंटरफ़ेस का इस्तेमाल करके,
एपीआई सेवा को अनुरोध करें.
उदाहरण के लिए, रोमांचक-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस सूची
बनाने के लिए:
SQLAdmin.Instances.List instances = sqladmin.instances().list("exciting-example-123").execute();
Python
Google API को कॉल करने के लिए, अनुमति वाले Credentials
ऑब्जेक्ट का इस्तेमाल
करने के लिए, यह तरीका अपनाएं:
- उस एपीआई के लिए सेवा ऑब्जेक्ट बनाएं जिसे आपको कॉल करना है. एपीआई के नाम और वर्शन के साथ-साथ अनुमति वाले
Credentials
ऑब्जेक्ट के साथbuild
फ़ंक्शन को कॉल करके, सर्विस ऑब्जेक्ट बनाया जाता है. उदाहरण के लिए, Cloud SQL एडमिन एपीआई के 1बीटा3 वर्शन को कॉल करने के लिए:import googleapiclient.discovery sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
- सर्विस ऑब्जेक्ट से मिले इंटरफ़ेस का इस्तेमाल करके,
एपीआई सेवा को अनुरोध करें.
उदाहरण के लिए, रोमांचक-example-123 प्रोजेक्ट में Cloud SQL डेटाबेस के इंस्टेंस सूची
बनाने के लिए:
response = sqladmin.instances().list(project='exciting-example-123').execute()
एचटीटीपी/REST
जब आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाता है, तब दिए गए सेवा खाते या उपयोगकर्ता खाते की ओर से Google API को कॉल करने के लिए, टोकन का इस्तेमाल किया जा सकता है. ऐसा तब किया जा सकता है, जब एपीआई के लिए ज़रूरी ऐक्सेस की अनुमति दी गई हो. ऐसा करने के लिए, एपीआई से किए जाने वाले अनुरोध में ऐक्सेस टोकन शामिल करें. इसके लिए, access_token
क्वेरी पैरामीटर या Authorization
एचटीटीपी हेडर Bearer
की वैल्यू शामिल करें. अगर हो सके, तो एचटीटीपी हेडर को प्राथमिकता दें, क्योंकि क्वेरी स्ट्रिंग आम तौर पर सर्वर लॉग में दिखती हैं. ज़्यादातर मामलों में, Google API पर कॉल सेट अप करने के लिए, क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Drive Files API को कॉल करते समय.
OAuth 2.0 Playground पर, सभी Google 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
ऐक्सेस टोकन की समयसीमा खत्म होने पर
Google OAuth 2.0 ऑथराइज़ेशन सर्वर से जारी किए गए ऐक्सेस टोकन की समयसीमा,
expires_in
वैल्यू से तय की गई अवधि के बाद खत्म हो जाती है. ऐक्सेस टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन को एक और JWT जनरेट करना चाहिए. साथ ही, उस पर हस्ताक्षर करके, दूसरे ऐक्सेस टोकन के लिए अनुरोध करना चाहिए.
JWT के गड़बड़ी कोड
error फ़ील्ड |
error_description फ़ील्ड |
मतलब | समस्या कैसे हल करें |
---|---|---|---|
unauthorized_client |
Unauthorized client or scope in request. |
अगर आपको पूरे डोमेन के लिए, किसी और को अपने ईमेल खाते का ऐक्सेस देना है, तो उपयोगकर्ता के डोमेन के 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 में अनुरोध किए गए एक या उससे ज़्यादा दायरे को अनुमति नहीं मिलती है. |
पक्का करें कि
आम तौर पर, इसमें कुछ मिनट लगते हैं. हालांकि, आपके 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 |
|
आम तौर पर, इसका मतलब होता है कि लोकल सिस्टम का समय सही नहीं है. ऐसा तब भी हो सकता है, जब
exp की वैल्यू, iat वैल्यू से आने वाले समय में 65 मिनट से ज़्यादा हो या
exp की वैल्यू, iat वैल्यू से कम हो. |
पक्का करें कि सिस्टम पर JWT जनरेट करने वाली घड़ी सही हो. अगर ज़रूरी हो, तो अपने समय को Google NTP के साथ सिंक करें. |
invalid_grant |
Invalid JWT Signature. |
JWT के दावे पर एक निजी पासकोड से हस्ताक्षर किया जाता है, जो क्लाइंट के ईमेल में बताए गए सेवा खाते से जुड़ी नहीं होती. इसके अलावा, यह भी हो सकता है कि इस्तेमाल की गई कुंजी को मिटा दिया गया हो, बंद कर दिया गया हो या उसकी समयसीमा खत्म हो चुकी हो. इसके अलावा, हो सकता है कि JWT के दावे को गलत तरीके से कोड में बदला गया हो - यह ज़रूरी है कि इसे Base64 कोड में बदला गया हो. साथ ही, इसमें नई लाइनों या पैडिंग (एक जैसे चिह्न) का इस्तेमाल न किया गया हो. |
JWT के दावे के सेट को डिकोड करें. इसके बाद, पुष्टि करें कि जिस कुंजी ने दावा किया है वह सेवा खाते से जुड़ी है. Google की दी गई OAuth लाइब्रेरी का इस्तेमाल करके देखें, ताकि यह पक्का किया जा सके कि JWT सही तरीके से जनरेट किया गया है. |
invalid_scope |
Invalid OAuth scope or ID token audience provided. |
किसी स्कोप का अनुरोध नहीं किया गया (दायरों की खाली सूची) या अनुरोध किया गया कोई एक दायरा मौजूद नहीं है (यानी अमान्य है). |
पक्का करें कि JWT के ध्यान दें कि |
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 के साथ, आपके पास OAuth 2.0 ऐक्सेस टोकन के बजाय, साइन किए गए JWT का सीधे तौर पर बियरर टोकन का इस्तेमाल करके, आधिकारिक एपीआई कॉल करने का विकल्प होता है. जब ऐसा मुमकिन हो, तब एपीआई कॉल करने से पहले, Google के ऑथराइज़ेशन सर्वर से नेटवर्क अनुरोध करने से बचा जा सकता है.
आपको जिस एपीआई को कॉल करना है उसकी सेवा की परिभाषा, अगर Google API GitHub रिपॉज़िटरी में पब्लिश की गई है, तो आपके पास ऐक्सेस टोकन के बजाय, JWT का इस्तेमाल करके अनुमति वाले एपीआई कॉल करने का विकल्प है. इसके लिए:
- ऊपर बताए गए तरीके से सेवा खाता बनाएं. पक्का करें कि खाता बनाते समय आपको मिली JSON फ़ाइल ही सेव हो.
- किसी भी स्टैंडर्ड 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
फ़ील्ड के लिए, मौजूदा यूनिक्स समय बताएं औरexp
फ़ील्ड के लिए, 3,600 सेकंड बाद की जेडब्लयूटी खत्म होने का समय डालें.
आपके सेवा खाते की JSON फ़ाइल में मौजूद निजी कुंजी का इस्तेमाल करके, जेडब्लयूटी को आरएसए-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')
- साइन किए गए JWT को बेयरर टोकन के तौर पर इस्तेमाल करके, एपीआई को कॉल करें:
GET /v1/projects/abc/databases/123/indexes HTTP/1.1 Authorization: Bearer SIGNED_JWT Host: firestore.googleapis.com