इस पेज का अनुवाद Cloud Translation API से किया गया है.

मोबाइल और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

और उदाहरण की पहचान इस खास जानकारी से, OAuth 2.0 फ़्लो के बारे में खास जानकारी मिलती है जिसका इस्तेमाल Google करता है. इससे आपको यह पक्का करने में मदद मिल सकती है कि आपने अपने ऐप्लिकेशन के लिए सही फ़्लो चुना है.

यह दस्तावेज़ बताता है कि फ़ोन, टैबलेट, और कंप्यूटर जैसे डिवाइसों पर इंस्टॉल किए गए ऐप्लिकेशन, Google API का ऐक्सेस देने के लिए, Google के #39; OAuth 2.0 एंडपॉइंट का इस्तेमाल कैसे करते हैं.

OAuth 2.0, उपयोगकर्ताओं को उनके उपयोगकर्ता नाम, पासवर्ड, और दूसरी जानकारी को निजी रखते हुए, ऐप्लिकेशन के साथ खास डेटा शेयर करने की सुविधा देता है. उदाहरण के लिए, कोई ऐप्लिकेशन OAuth 2.0 का इस्तेमाल करके उपयोगकर्ताओं से Google Drive में उनकी फ़ाइलें सेव करने की अनुमति ले सकता है.

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

यह अनुमति देने का तरीका, वेब सर्वर ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले फ़्लो जैसा ही है. मुख्य अंतर यह है कि इंस्टॉल किए गए ऐप्लिकेशन को, सिस्टम ब्राउज़र खोलना होगा और Google और #39; के ऑथराइज़ेशन सर्वर से मिले रिस्पॉन्स को मैनेज करने के लिए, एक लोकल रीडायरेक्ट यूआरआई देना होगा.

विकल्प

मोबाइल ऐप्लिकेशन के लिए, आप Android या iOS पर Google साइन इन की सुविधा इस्तेमाल कर सकते हैं. 'Google साइन-इन' की क्लाइंट लाइब्रेरी, पुष्टि करने और उपयोगकर्ता की अनुमति की प्रोसेस को हैंडल करती हैं. साथ ही, हो सकता है कि यहां बताए गए निचले लेवल के प्रोटोकॉल की तुलना में, इन्हें लागू करना ज़्यादा आसान हो.

ऐसे डिवाइसों पर चलने वाले ऐप्लिकेशन जो सिस्टम ब्राउज़र पर काम नहीं करते या जिनमें टीवी, गेम कंसोल, कैमरे या प्रिंटर जैसी सीमित इनपुट क्षमताएं हैं, उनके लिए, टीवी और एएमपी; डिवाइसों के लिए OAuth 2.0 या टीवी और सीमित इनपुट डिवाइसों पर साइन-इन की सुविधा देखें.

लाइब्रेरी और नमूने

हमारा सुझाव है कि आप इस लाइब्रेरी में बताए गए OAuth 2.0 फ़्लो को लागू करने में मदद करने के लिए, यहां दी गई लाइब्रेरी और सैंपल का इस्तेमाल करें:

Android के लिए AppAuth लाइब्रेरी
iOS के लिए AppAuth लाइब्रेरी
ऐप्लिकेशन के लिए OAuth: Windows के नमूने

ज़रूरी बातें

अपने प्रोजेक्ट के लिए API (एपीआई) चालू करें

Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को, API Consoleमें उन एपीआई को चालू करना होगा.

अपने प्रोजेक्ट के लिए एपीआई को चालू करने के लिए:

Open the API Library में Google API Console.
If prompted, select a project, or create a new one.
API Library सभी उपलब्ध एपीआई की सूची बनाता है. इन्हें प्रॉडक्ट परिवार और लोकप्रियता के हिसाब से ग्रुप किया जाता है. आप जिस एपीआई को चालू करना चाहते हैं वह अगर सूची में मौजूद नहीं है, तो खोज का इस्तेमाल करें.
वह एपीआई चुनें जिसे आप चालू करना चाहते हैं, फिर चालू करें बटन पर क्लिक करें.
If prompted, enable billing.
If prompted, read and accept the API's Terms of Service.

अनुमति वाले क्रेडेंशियल बनाना

Google API ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करने वाले किसी भी ऐप्लिकेशन के पास, Google और #39;s OAuth 2.0 सर्वर को ऐप्लिकेशन की पहचान करने वाले अनुमति क्रेडेंशियल होने चाहिए. नीचे दिए गए चरणों में बताया गया है कि अपने प्रोजेक्ट के लिए क्रेडेंशियल कैसे बनाए जा सकते हैं. इसके बाद, आपके ऐप्लिकेशन उन एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल का इस्तेमाल कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए चालू किया है.

Go to the Credentials page.
क्रेडेंशियल बनाएं &gt, OAuth क्लाइंट आईडी पर क्लिक करें.
नीचे दिए गए सेक्शन में बताया गया है कि क्लाइंट किस तरह के हैं. साथ ही, ये रीडायरेक्ट उन तरीकों के बारे में भी बताते हैं जो Google की अनुमति देने वाले सर्वर पर काम करते हैं. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें, अपना OAuth क्लाइंट नाम दें, और फ़ॉर्म में अन्य फ़ील्ड को सही तरीके से सेट करें.

कस्टम यूआरआई स्कीम (Android, iOS, UWP)

Android ऐप्लिकेशन, iOS ऐप्लिकेशन, और यूनिवर्सल Windows Platform (UWP) ऐप्लिकेशन के लिए, पसंद के मुताबिक यूआरआई स्कीम इस्तेमाल करने का सुझाव दिया जाता है.

Android

Android ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए एक नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट Credentials page पर दिखाया जाता है.
अपने Android ऐप्लिकेशन के पैकेज का नाम डालें. यह वैल्यू आपके ऐप्लिकेशन मेनिफ़ेस्ट की फ़ाइल में <manifest> एलिमेंट के package एट्रिब्यूट में दी गई है.
ऐप्लिकेशन डिस्ट्रिब्यूशन का SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट डालें.
- अगर आपके ऐप्लिकेशन में Google Play की ऐप्लिकेशन साइनिंग का इस्तेमाल होता है, तो Play Console के ऐप्लिकेशन साइनिंग पेज से SHA-1 फ़िंगरप्रिंट को कॉपी करें.
- अगर आप खुद का कीस्टोर और साइनिंग कुंजी मैनेज करते हैं, तो प्रमाणपत्र की जानकारी को ऐसे फ़ॉर्मैट में प्रिंट करने के लिए Java के साथ शामिल keytool यूटिलिटी का इस्तेमाल करें जिसे आसानी से पढ़ा जा सके. keytool आउटपुट के Certificate fingerprints सेक्शन में SHA1 वैल्यू को कॉपी करें. ज़्यादा जानकारी के लिए, 'Android के लिए Google API' दस्तावेज़ में, अपने क्लाइंट की पुष्टि करना लेख देखें.
बनाएं पर क्लिक करें.

iOS

iOS ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए एक नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट Credentials page पर दिखाया जाता है.
अपने ऐप्लिकेशन के लिए बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की #<FbundleIdentifier कुंजी की वैल्यू होती है. इस प्रॉपर्टी की सूची वाली संसाधन फ़ाइल (info.plist) होती है. आम तौर पर, वैल्यू को 'सामान्य' पैनल में दिखाया जाता है. इसके अलावा, इसे Xcode प्रोजेक्ट एडिटर के 'साइनिंग ऐंड एएमपी' बटन के साथ दिखाया जाता है. बंडल आईडी, Apple's App Store Connect साइट पर, ऐप्लिकेशन की जानकारी वाले पेज के सामान्य जानकारी वाले सेक्शन में भी दिखता है.
(ज़रूरी नहीं)
अगर ऐप्लिकेशन Apple 's App Store में प्रकाशित किया गया है, तो अपना ऐप्लिकेशन स्टोर आईडी डालें. स्टोर आईडी, अंकों के हिसाब से एक स्ट्रिंग होती है. यह हर Apple App Store यूआरएल में शामिल होती है.
1. अपने iOS या iPadOS पर, Apple App Store ऐप्लिकेशन खोलें.
2. अपना ऐप्लिकेशन खोजें.
3. शेयर करें बटन (स्क्वेयर और ऐरो अप सिंबल) चुनें.
4. लिंक कॉपी करें चुनें.
5. लिंक को टेक्स्ट एडिटर में चिपकाएं. App Store आईडी, यूआरएल का फ़ाइनल हिस्सा होता है.
  उदाहरण: https://apps.apple.com/app/google/id284815942
(ज़रूरी नहीं)
अपना टीम आईडी डालें. ज़्यादा जानकारी के लिए, Apple डेवलपर खाते के दस्तावेज़ में अपनी टीम का आईडी ढूंढें देखें.
बनाएं पर क्लिक करें.

यूडब्ल्यूपी

यूनिवर्सल Windows Platform ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए एक नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट Credentials page पर दिखाया जाता है.
अपने ऐप्लिकेशन का #19 वर्णों वाला Microsoft Store आईडी डालें. ऐप्लिकेशन वैल्यू के सेक्शन में मौजूद, ऐप्लिकेशन की पहचान वाले पेज पर जाकर, Microsoft Partner Center में यह वैल्यू देखी जा सकती है.
बनाएं पर क्लिक करें.

UWP ऐप्लिकेशन के लिए, कस्टम यूआरआई स्कीम 39 वर्णों से ज़्यादा की नहीं हो सकती.

लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)

इस यूआरएल का इस्तेमाल करके ऑथराइज़ेशन कोड पाने के लिए, आपका ऐप्लिकेशन स्थानीय वेब सर्वर पर सुनना चाहिए. ऐसा सभी प्लैटफ़ॉर्म पर हो सकता है, लेकिन सभी प्लैटफ़ॉर्म पर नहीं. हालांकि, अगर आपका प्लैटफ़ॉर्म काम करता है, तो आपको ऑथराइज़ेशन कोड पाने का सुझाव दिया जाता है.

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

इस्तेमाल करने के बारे में सुझाव	macOS, Linux, और Windows डेस्कटॉप (लेकिन यूनिवर्सल Windows प्लैटफ़ॉर्म नहीं) ऐप्लिकेशन
फ़ॉर्म वैल्यू	ऐप्लिकेशन टाइप को डेस्कटॉप ऐप्लिकेशन पर सेट करें.

ध्यान दें: लूपबैक आईपी पते के बारे में ज़्यादा जानने के लिए, redirect_uri पैरामीटर की परिभाषा देखें. लूपबैक आईपी की जगह localhost का इस्तेमाल भी किया जा सकता है. हालांकि, इस कॉन्फ़िगरेशन की वजह से क्लाइंट फ़ायरवॉल में समस्याएं आ सकती हैं. फ़ायरवॉल के ज़रिए, ज़्यादातर मामलों में कम्यूनिकेशन का काम किया जा सकता है.

मैन्युअल कॉपी/पेस्ट

ऐक्सेस के दायरे की पहचान करना

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

हमारा सुझाव है कि OAuth 2.0 को लागू करने से पहले, उन दायरों की पहचान कर लें जिन्हें ऐक्सेस करने के लिए आपके ऐप्लिकेशन को अनुमति की ज़रूरत होगी.

OAuth 2.0 एपीआई के दायरे वाले दस्तावेज़ में, उन दायरों की पूरी सूची मौजूद है जिनका इस्तेमाल करके, आप Google API ऐक्सेस कर सकते हैं.

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

OAuth 2.0 ऐक्सेस टोकन पाना

नीचे दिया गया तरीका बताता है कि आपका ऐप्लिकेशन उपयोगकर्ता और #39; की ओर से एपीआई अनुरोध करने के लिए, Google और #39; OAuth 2.0 सर्वर के साथ कैसे इंटरैक्ट करता है. Google एपीआई अनुरोध को लागू करने से पहले, आपके ऐप्लिकेशन को वह सहमति लेनी होगी जिसमें उपयोगकर्ता की अनुमति ज़रूरी है.

पहला चरण: कोड की पुष्टि करने वाला प्रोग्राम और चुनौती जनरेट करना

Google, इंस्टॉल किए गए ऐप्लिकेशन फ़्लो को ज़्यादा सुरक्षित बनाने के लिए, कोड एक्सचेंज (PKCE) प्रोटोकॉल के साथ काम करता है. हर ऑथराइज़ेशन अनुरोध के लिए एक खास कोड की पुष्टि करने वाला प्रोग्राम बनाया जाता है और ऑथराइज़ेशन कोड पाने के लिए इसके बदले गए मान को &quat;code_Challenge&quat; कहा जाता है.

कोड सत्यापनकर्ता बनाएं

code_verifier, बिना किसी शुल्क के क्रिप्टोग्राफ़िक स्ट्रिंग होती है, जिसमें रिज़र्वेशन नहीं किए गए वर्ण (A-Z] / [a-z] / [0-9] / &कोटेशन;-&&कोटेशन; / &कोट्स;

कोड की पुष्टि करने वाले प्रोग्राम में इतनी वैल्यू होनी चाहिए कि उसका अनुमान लगाने में मुश्किल हो.

कोड कैप्चा बनाएं

कोड चैलेंज बनाने के दो तरीके काम करते हैं.

कोड चैलेंज जनरेट करने के तरीके
S256 (सुझाया गया)	कोड की पुष्टि करने वाला कोड, कोड की पुष्टि करने वाले प्रोग्राम का SHA256 हैश कोड में बदला गया Base64URL (बिना पैडिंग वाला) है. `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
सादा	कोड की पुष्टि वही वैल्यू है जो ऊपर जनरेट किए गए कोड की पुष्टि करने वाले प्रोग्राम ने की है. `code_challenge` = `code_verifier`

दूसरा चरण: Google's OAuth 2.0 के सर्वर को अनुरोध भेजना

उपयोगकर्ता की अनुमति पाने के लिए, Google को पुष्टि करने वाला सर्वर https://accounts.google.com/o/oauth2/v2/auth पर अनुरोध भेजें. यह एंडपॉइंट, सेशन के चालू लुकअप को मैनेज करता है, उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. एंडपॉइंट को सिर्फ़ एसएसएल से ऐक्सेस किया जा सकता है और यह एचटीटीपी (बिना एसएसएल) वाले कनेक्शन अस्वीकार कर देता है.

अनुमति देने वाला सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए इन क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:

पैरामीटर

client_id

ज़रूरी

आपके ऐप्लिकेशन के लिए क्लाइंट आईडी. आपको यह वैल्यू API Console Credentials pageमें दिखेगी.

redirect_uri

ज़रूरी

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

यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले किसी एक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए जिसे आपने अपने क्लाइंट के API ConsoleCredentials pageमें कॉन्फ़िगर किया था. अगर यह मान आधिकारिक यूआरआई से मेल नहीं खाता है, तो आपको redirect_uri_mismatch गड़बड़ी मिलेगी.

नीचे दी गई टेबल में, हर तरीके के लिए सही redirect_uri पैरामीटर वैल्यू दी गई है:

redirect_uri की वैल्यू

कस्टम यूआरआई स्कीम

com.example.app:redirect_uri_path

या

com.googleusercontent.apps.123:redirect_uri_path

com.example.app, आपके कंट्रोल में आने वाले डोमेन का रिवर्स डीएनएस नोटेशन है. कस्टम स्कीम में मान्य होने के लिए एक पीरियड होना ज़रूरी है.
com.googleusercontent.apps.123, क्लाइंट आईडी का रिवर्स डीएनएस नोटेशन है.
redirect_uri_path पाथ का एक वैकल्पिक कॉम्पोनेंट है, जैसे कि /oauth2redirect. ध्यान दें कि पाथ को एक स्लैश के साथ शुरू किया जाना चाहिए, जो सामान्य एचटीटीपी यूआरएल से अलग है.

लूपबैक आईपी पता

http://127.0.0.1:port या http://[::1]:port

अपने प्लैटफ़ॉर्म से जुड़े लूपबैक आईपी पते के लिए, अपने प्लैटफ़ॉर्म के बारे में क्वेरी करें. साथ ही, किसी भी क्रम में उपलब्ध पोर्ट पर एचटीटीपी लिसनर शुरू करें. port को उस पोर्ट नंबर से बदलें जिसे आपका ऐप्लिकेशन सुनता है.

response_type

ज़रूरी

यह तय करता है कि Google OAuth 2.0 एंडपॉइंट, ऑथराइज़ेशन कोड दिखाता है या नहीं.

इंस्टॉल किए गए ऐप्लिकेशन के लिए पैरामीटर वैल्यू code पर सेट करें.

scope

ज़रूरी

स्पेस की दायरे वाली सूची, जिसमें ऐसे संसाधन शामिल हैं जिन्हें आपका ऐप्लिकेशन, उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. ये मान Google को उस सहमति स्क्रीन के बारे में बताते हैं जिसे Google दिखाता है.

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

code_challenge

सुझाया गया

यह कोड में बदला गया code_verifier तय करता है. इसका इस्तेमाल, ऑथराइज़ेशन कोड एक्सचेंज के दौरान सर्वर-साइड चैलेंज के तौर पर किया जाएगा. ज़्यादा जानकारी के लिए, ऊपर दिए गए कोड चैलेंज बनाएं सेक्शन को देखें.

code_challenge_method

सुझाया गया

इस नीति से पता चलता है कि ऑथराइज़ेशन कोड एक्सचेंज के दौरान, code_verifier को कोड करने के लिए किस तरीके का इस्तेमाल किया जाएगा. इस पैरामीटर का इस्तेमाल ऊपर बताए गए code_challenge पैरामीटर के साथ किया जाना चाहिए. अगर code_challenge में शामिल नहीं है, तो code_challenge_method की वैल्यू डिफ़ॉल्ट रूप से plain पर सेट होती है. इस पैरामीटर के लिए सिर्फ़ S256 या plain इस्तेमाल किए जा सकते हैं.

state

सुझाया गया

ऐसे किसी भी स्ट्रिंग मान के बारे में बताता है जिसका इस्तेमाल आपका ऐप्लिकेशन, आपके अनुमति देने के अनुरोध और अनुमति देने वाले सर्वर के रिस्पॉन्स के बीच स्थिति बनाए रखने के लिए करता है. जब उपयोगकर्ता आपके ऐप्लिकेशन की पुष्टि के लिए अनुरोध करता है या उसे अस्वीकार करता है, तब सर्वर redirect_uri के name=value फ़्रैगमेंट आइडेंटिफ़ायर (#) में, name=value की जोड़ी गई वैल्यू के बराबर वैल्यू दिखाता है.

इस पैरामीटर का इस्तेमाल कई कामों के लिए किया जा सकता है. जैसे, उपयोगकर्ता को आपके ऐप्लिकेशन में सही संसाधन पर ले जाना, गैर-लाभकारी संस्था को भेजना, और क्रॉस-साइट अनुरोध से जुड़ी धोखाधड़ी को कम करना. state का इस्तेमाल करके, redirect_uri का अनुमान लगाया जा सकता है. इससे, इस बात का भरोसा बढ़ सकता है कि आने वाला कनेक्शन, पुष्टि करने के अनुरोध की वजह से हुआ है. अगर आप कोई रैंडम स्ट्रिंग जनरेट करते हैं या किसी कुकी या हैश की कुंजी को किसी ऐसे दूसरे कोड के कोड में बदलते हैं जो क्लाइंट की स्थिति बताता है, तो आप इस बात की पुष्टि कर सकते हैं कि अनुरोध और रिस्पॉन्स, एक ही ब्राउज़र में जनरेट किए गए हैं या नहीं. साथ ही, क्रॉस-साइट से जुड़े जालसाज़ी जैसे हमलों से बचाव भी किया जा सकता है. state टोकन बनाने और उसकी पुष्टि करने के उदाहरण के लिए, OpenID Connect दस्तावेज़ देखें.

login_hint

ज़रूरी नहीं

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

पैरामीटर वैल्यू को ईमेल पते या sub के आइडेंटिफ़ायर पर सेट करें. यह उपयोगकर्ता और #39; के Google आईडी के बराबर होता है.

ध्यान दें: क्लाइंट ने client_secret को गोपनीय नहीं रखा हो सकता. इसलिए, इंस्टॉल किए गए ऐप्लिकेशन के साथ अनुमति के अनुरोध में बढ़ोतरी नहीं की जा सकती.

विज्ञापन दिखाने की अनुमति देने वाले यूआरएल

नीचे दिए गए टैब, अलग-अलग रीडायरेक्ट यूआरआई विकल्पों के लिए, अनुमति देने वाले यूआरएल के नमूने दिखाते हैं.

redirect_uri पैरामीटर की वैल्यू के अलावा, यूआरएल एक जैसे होते हैं. यूआरएल में ज़रूरी response_type और client_id पैरामीटर के साथ-साथ वैकल्पिक state पैरामीटर भी शामिल होते हैं. हर यूआरएल में लाइन ब्रेक और पढ़ने के लिए खाली जगह होती है.

तीसरा चरण: Google को, सहमति देने के लिए उपयोगकर्ता से अनुरोध करना

इस चरण में, उपयोगकर्ता यह तय करता है कि आपके ऐप्लिकेशन को अनुरोध किया गया ऐक्सेस देना है या नहीं. इस स्टेज पर, Google एक सहमति विंडो दिखाता है जिसमें आपके ऐप्लिकेशन का नाम और Google API की सेवाएं शामिल होती हैं. इनकी मदद से, उपयोगकर्ता और #39; के अनुमति क्रेडेंशियल के साथ ऐक्सेस की अनुमति का अनुरोध किया जाता है. साथ ही, दिए जाने वाले ऐक्सेस के दायरे की खास जानकारी भी दिखाई जाती है. इसके बाद, उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए एक या एक से ज़्यादा दायरों का ऐक्सेस देने के लिए सहमत हो सकता है या अनुरोध को अस्वीकार कर सकता है.

आपके ऐप्लिकेशन को इस स्टेज पर कुछ भी करने की ज़रूरत नहीं है. यह Google # OAuth 2.0 के सर्वर के जवाब का इंतज़ार करता है, जो यह बताता है कि कोई ऐक्सेस दिया गया है या नहीं. इस रिस्पॉन्स को अगले चरण में बताया गया है.

गड़बड़ियां

Google सामान्य गड़बड़ी कोड और सुझाए गए रिज़ॉल्यूशन नीचे दिए गए हैं.

`admin_policy_enforced`

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

`disallowed_useragent`

ऑथराइज़ेशन एंडपॉइंट को एम्बेड किए गए उपयोगकर्ता-एजेंट में दिखाया जाता है, जिसे Google की OAuth 2.0 नीतियों ने अनुमति नहीं दी है.

Android

android.webkit.WebView में अनुमति के अनुरोध खोलने पर, Android डेवलपर को यह गड़बड़ी का मैसेज मिल सकता है. इसके बजाय, डेवलपर को Android लाइब्रेरी का इस्तेमाल करना चाहिए, जैसे कि Android के लिए Google साइन इन या OpenGL फ़ाउंडेशन का #39; Android के लिए AppAuth.

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

iOS

WKWebView में अनुमति देने का अनुरोध खोलने पर iOS और macOS डेवलपर इस गड़बड़ी का सामना कर सकते हैं. इसके बजाय, डेवलपर को iOS लाइब्रेरी का इस्तेमाल करना चाहिए, जैसे कि iOS के लिए Google साइन इन या OpenGL Foundation's iOS के लिए AppAuth.

वेब डेवलपर को यह गड़बड़ी तब मिल सकती है, जब iOS या macOS ऐप्लिकेशन एम्बेड किए गए उपयोगकर्ता एजेंट में सामान्य वेब लिंक खोलता हो. साथ ही, जब उपयोगकर्ता आपकी साइट पर जाकर, Google's OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर जाता है, तो यह गड़बड़ी आ सकती है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में सामान्य लिंक खोलने की अनुमति देनी चाहिए. इसमें यूनिवर्सल लिंक हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल होते हैं. SFSafariViewController लाइब्रेरी भी एक विकल्प है.

`org_internal`

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

`redirect_uri_mismatch`

अनुमति के अनुरोध में पास किया गया redirect_uri, OAuth क्लाइंट आईडी के लिए आधिकारिक रीडायरेक्ट यूआरआई से मेल नहीं खाता. Google API Console Credentials page में आधिकारिक रीडायरेक्ट यूआरआई की समीक्षा करें.

पास किया गया redirect_uri, क्लाइंट टाइप के लिए अमान्य हो सकता है.

चौथा चरण: OAuth 2.0 सर्वर का रिस्पॉन्स मैनेज करना

आपके ऐप्लिकेशन को अनुमति देने का जवाब जिस तरह से मिलता है, वह उस रीडायरेक्ट यूआरआई स्कीम पर निर्भर करता है जिसका इस्तेमाल वह करता है. स्कीम पर ध्यान दिए बिना, रिस्पॉन्स में या तो एक ऑथराइज़ेशन कोड (code) या एक गड़बड़ी (error) होगी. उदाहरण के लिए, error=access_denied से पता चलता है कि उपयोगकर्ता ने अनुरोध को अस्वीकार कर दिया है.

अगर उपयोगकर्ता आपके ऐप्लिकेशन को ऐक्सेस देता है, तो आप ऐक्सेस टोकन और रीफ़्रेश टोकन के लिए ऑथराइज़ेशन कोड को एक्सचेंज कर सकते हैं. इसका तरीका आगे बताया गया है.

पांचवां चरण: रीफ़्रेश करने और टोकन ऐक्सेस करने के लिए, ऑथराइज़ेशन कोड को एक्सचेंज करना

ऐक्सेस टोकन के लिए ऑथराइज़ेशन कोड को बदलने के लिए, https://oauth2.googleapis.com/token एंडपॉइंट को कॉल करें और ये पैरामीटर सेट करें:

फ़ील्ड
`client_id`	API Console Credentials pageसे मिला क्लाइंट आईडी.
`client_secret`	API Console Credentials pageसे मिला क्लाइंट सीक्रेट.
`code`	शुरुआती अनुरोध से मिला ऑथराइज़ेशन कोड.
`code_verifier`	कोड की पुष्टि करने वाला प्रोग्राम, जिसे आपने चरण 1 में बनाया था.
`grant_type`	जैसा कि OAuth 2.0 में बताया गया है, इस फ़ील्ड का मान `authorization_code` पर सेट होना चाहिए.
`redirect_uri`	दिए गए API Console Credentials page दिए गए `client_id` के लिए, आपके प्रोजेक्ट के लिए लिस्ट किए गए रीडायरेक्ट यूआरआई में से एक.

नीचे दिया गया स्निपेट एक नमूना अनुरोध दिखाता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http%3A//127.0.0.1%3A9004&
grant_type=authorization_code

Google, इस अनुरोध का जवाब ऐसे JSON ऑब्जेक्ट के साथ देता है जिसमें कम समय के लिए ऐक्सेस टोकन और रीफ़्रेश टोकन होता है.

रिस्पॉन्स में ये फ़ील्ड शामिल होते हैं:

फ़ील्ड
`access_token`	वह टोकन जो आपका ऐप्लिकेशन, Google API के अनुरोध की अनुमति देने के लिए भेजता है.
`expires_in`	ऐक्सेस टोकन की बची हुई अवधि सेकंड में.
`id_token`	ध्यान दें: यह प्रॉपर्टी सिर्फ़ तब ही दिखाई जाती है, जब आपके अनुरोध में पहचान का दायरा शामिल होता है, जैसे कि `openid`, `profile` या `email`. यह मान JSON वेब टोकन (JWT) होता है, जिसमें उपयोगकर्ता के बारे में डिजिटल तौर पर हस्ताक्षर की गई पहचान की जानकारी होती है.
`refresh_token`	नया टोकन पाने के लिए, इस टोकन का इस्तेमाल किया जा सकता है. रीफ़्रेश टोकन तब तक मान्य रहते हैं, जब तक उपयोगकर्ता ऐक्सेस को निरस्त नहीं कर देता. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के लिए, हमेशा रीफ़्रेश टोकन दिए जाते हैं.
`scope`	`access_token` के दिए हुए ऐक्सेस के दायरे में, स्पेस को अलग-अलग करने वाले केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाया गया है.
`token_type`	लौटाया गया टोकन किस तरह का है. इस समय, इस फ़ील्ड की वैल्यू हमेशा `Bearer` पर सेट रहती है.

अहम जानकारी: आपके ऐप्लिकेशन में दोनों टोकन स्टोर किए जाने चाहिए. साथ ही, इन्हें लंबे समय तक इस्तेमाल के लिए रखा जाना चाहिए. यह आपके ऐप्लिकेशन के अलग-अलग इंवोकेशन के बीच ऐक्सेस किया जा सकता है. रीफ़्रेश टोकन की मदद से, आपका ऐप्लिकेशन नया ऐक्सेस टोकन पा सकता है. ऐसा तब किया जाता है, जब आपके टोकन की समयसीमा खत्म हो गई हो. उदाहरण के लिए, अगर आपका ऐप्लिकेशन रीफ़्रेश टोकन खो देता है, तो उपयोगकर्ता को OAuth 2.0 सहमति फ़्लो को दोहराना होगा, ताकि आपके ऐप्लिकेशन को नया रीफ़्रेश टोकन मिल सके.

नीचे दिया गया स्निपेट एक सैंपल जवाब दिखाता है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Google API कॉलिंग

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

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

एचटीटीपी 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

ऐक्सेस टोकन को रीफ़्रेश करना

ऐक्सेस टोकन समय-समय पर खत्म हो जाते हैं और किसी मिलते-जुलते एपीआई अनुरोध के लिए अमान्य क्रेडेंशियल बन जाते हैं. अगर आपने टोकन से जुड़े दायरों के लिए ऑफ़लाइन ऐक्सेस का अनुरोध किया है, तो उपयोगकर्ता की अनुमति के बिना भी ऐक्सेस टोकन को रीफ़्रेश किया जा सकता है. ऐसा तब भी हो सकता है, जब उपयोगकर्ता मौजूद न हो.

ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन एचटीटीपीएसPOST को Google' के ऑथराइज़ेशन सर्वर (https://oauth2.googleapis.com/token) को अनुरोध भेजता है. इस अनुरोध में, ये पैरामीटर शामिल होते हैं:

फ़ील्ड
`client_id`	API Consoleसे मिला क्लाइंट आईडी.
`client_secret`	API Consoleसे लिया गया क्लाइंट सीक्रेट. `client_secret`, Android, iOS या Chrome ऐप्लिकेशन के तौर पर रजिस्टर किए गए क्लाइंट के अनुरोधों पर लागू नहीं होता.
`grant_type`	जैसा कि OAuth 2.0 में तय किया गया है, इस फ़ील्ड का मान `refresh_token` पर सेट होना चाहिए.
`refresh_token`	ऑथराइज़ेशन कोड एक्सचेंज से मिला रीफ़्रेश टोकन.

नीचे दिया गया स्निपेट एक नमूना अनुरोध दिखाता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

जब तक उपयोगकर्ता, ऐप्लिकेशन को दिए गए ऐक्सेस को निरस्त नहीं करता, तब तक टोकन सर्वर एक JSON ऑब्जेक्ट दिखाता है जिसमें नया ऐक्सेस टोकन शामिल होता है. नीचे दिया गया स्निपेट एक सैंपल जवाब दिखाता है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

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

टोकन निरस्त करना

कुछ मामलों में, हो सकता है कि उपयोगकर्ता किसी ऐप्लिकेशन को दिया गया ऐक्सेस निरस्त करना चाहे. उपयोगकर्ता खाता सेटिंग पर जाकर ऐक्सेस को निरस्त कर सकता है. ज़्यादा जानकारी के लिए, तीसरे पक्ष की साइटों और ऐप्लिकेशन के ऐक्सेस वाले सेक्शन या ऐप्लिकेशन को हटाने का सेक्शन और सहायता दस्तावेज़ देखें.

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

टोकन को प्रोग्रामैटिक तौर पर निरस्त करने के लिए, आपका ऐप्लिकेशन https://oauth2.googleapis.com/revoke से अनुरोध करता है और टोकन को पैरामीटर के तौर पर शामिल करता है:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

टोकन, ऐक्सेस टोकन या रीफ़्रेश टोकन हो सकता है. अगर टोकन किसी ऐक्सेस टोकन के तौर पर है और उसके हिसाब से कोई रीफ़्रेश टोकन मौजूद है, तो रीफ़्रेश टोकन भी निरस्त कर दिया जाएगा.

अगर रद्द करने की प्रोसेस पूरी हो गई है, तो रिस्पॉन्स का एचटीटीपी स्टेटस कोड 200 है. गड़बड़ी की स्थितियों के लिए, एचटीटीपी स्टेटस कोड 400 को गड़बड़ी कोड के साथ दिखाया जाता है.

इसके बारे में और पढ़ें

आईईटीएफ़ के सबसे सही मौजूदा तरीकों नेटिव ऐप्लिकेशन के लिए OAuth 2.0 यहां बताए गए कई सबसे सही तरीके तय करता है.

मोबाइल और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

लाइब्रेरी और नमूने

ज़रूरी बातें

अपने प्रोजेक्ट के लिए API (एपीआई) चालू करें

अनुमति वाले क्रेडेंशियल बनाना

कस्टम यूआरआई स्कीम (Android, iOS, UWP)

Android

iOS

यूडब्ल्यूपी

लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)

मैन्युअल कॉपी/पेस्ट

ऐक्सेस के दायरे की पहचान करना

OAuth 2.0 ऐक्सेस टोकन पाना

पहला चरण: कोड की पुष्टि करने वाला प्रोग्राम और चुनौती जनरेट करना

कोड सत्यापनकर्ता बनाएं

कोड कैप्चा बनाएं

दूसरा चरण: Google's OAuth 2.0 के सर्वर को अनुरोध भेजना

विज्ञापन दिखाने की अनुमति देने वाले यूआरएल

कस्टम यूआरआई स्कीम

लूपबैक आईपी पता

तीसरा चरण: Google को, सहमति देने के लिए उपयोगकर्ता से अनुरोध करना

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

redirect_uri_mismatch

चौथा चरण: OAuth 2.0 सर्वर का रिस्पॉन्स मैनेज करना

पांचवां चरण: रीफ़्रेश करने और टोकन ऐक्सेस करने के लिए, ऑथराइज़ेशन कोड को एक्सचेंज करना

Google API कॉलिंग

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

curl के उदाहरण

ऐक्सेस टोकन को रीफ़्रेश करना

टोकन निरस्त करना

इसके बारे में और पढ़ें

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`redirect_uri_mismatch`

`curl` के उदाहरण