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

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

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

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

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

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

विकल्प

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

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

लाइब्रेरी और सैंपल

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

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

ज़रूरी शर्तें

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

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

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

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 के दस्तावेज़ में, अपने क्लाइंट की पुष्टि करना देखें.
(ज़रूरी नहीं) अपने Android ऐप्लिकेशन के मालिकाना हक की पुष्टि करें.
बनाएं पर क्लिक करें.

iOS

iOS ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पर दिखाया जाता है.
अपने ऐप्लिकेशन का बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की जानकारी वाली प्रॉपर्टी की सूची वाली संसाधन फ़ाइल (info.plist) में मौजूद CFBundleIdentifier बटन की वैल्यू होती है. वैल्यू आम तौर पर, Xcode प्रोजेक्ट एडिटर के सामान्य पैनल या हस्ताक्षर और सुविधाओं के पैनल में दिखती है. बंडल आईडी, Apple की App Store Connect साइट पर, ऐप्लिकेशन के 'ऐप्लिकेशन की जानकारी' पेज के 'सामान्य जानकारी' सेक्शन में भी दिखता है.
पक्का करें कि आपने अपने ऐप्लिकेशन के लिए सही बंडल आईडी का इस्तेमाल किया हो. ऐसा इसलिए, क्योंकि ऐप्लिकेशन की जांच करने की सुविधा का इस्तेमाल करने पर, इसे बदला नहीं जा सकता.
(ज़रूरी नहीं)
अगर आपका ऐप्लिकेशन Apple के App Store में पब्लिश किया गया है, तो अपने ऐप्लिकेशन का 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 Developer खाते के दस्तावेज़ में, अपना टीम आईडी ढूंढना लेख पढ़ें.
ध्यान दें: अगर आपको अपने क्लाइंट के लिए ऐप्लिकेशन की जांच की सुविधा चालू करनी है, तो टीम आईडी फ़ील्ड भरना ज़रूरी है.
(ज़रूरी नहीं)
अपने iOS ऐप्लिकेशन के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करें. ऐप्लिकेशन की जांच करने की सुविधा चालू करने पर, Apple की ऐप्लिकेशन की पुष्टि करने वाली सेवा का इस्तेमाल करके यह पुष्टि की जाती है कि आपके OAuth क्लाइंट से मिले OAuth 2.0 अनुरोध, सही और आपके ऐप्लिकेशन से मिले हैं. इससे, ऐप्लिकेशन के नाम पर धोखाधड़ी करने के जोखिम को कम करने में मदद मिलती है. अपने iOS ऐप्लिकेशन के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करने के बारे में ज़्यादा जानें.
बनाएं पर क्लिक करें.

UWP

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

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

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

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

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

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

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

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

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

पहला चरण: कोड की पुष्टि करने वाला कोड और चैलेंज जनरेट करना

Google, कोड एक्सचेंज के लिए पुष्टि करने वाली कुंजी (PKCE) प्रोटोकॉल के साथ काम करता है, ताकि इंस्टॉल किए गए ऐप्लिकेशन फ़्लो को ज़्यादा सुरक्षित बनाया जा सके. अनुमति के हर अनुरोध के लिए, एक यूनीक कोड पुष्टि करने वाला टूल बनाया जाता है. साथ ही, "code_challenge" नाम की बदली गई वैल्यू को अनुमति देने वाले सर्वर पर भेजा जाता है, ताकि अनुमति का कोड मिल सके.

कोड की पुष्टि करने वाला टूल बनाना

code_verifier, एन्क्रिप्शन के लिए इस्तेमाल होने वाली एक स्ट्रिंग है. इसमें, [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" जैसे वर्ण इस्तेमाल किए जाते हैं. इसकी लंबाई 43 से 128 वर्णों के बीच हो सकती है.

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

कोड चैलेंज बनाना

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

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

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

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

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

पैरामीटर

client_id

ज़रूरी है

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

redirect_uri

ज़रूरी है

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

यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. आपने अपने क्लाइंट के API Console Credentials 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

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

ध्यान दें कि मोबाइल ऐप्लिकेशन पर, लूपबैक आईपी पते के रीडायरेक्ट विकल्प के लिए, इस्तेमाल करना बंद कर दिया गया है.

response_type

ज़रूरी है

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

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

scope

ज़रूरी है

स्पेस से अलग किए गए स्कोप की सूची, जो उन संसाधनों की पहचान करती है जिन्हें आपका ऐप्लिकेशन उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. इन वैल्यू से, सहमति वाली उस स्क्रीन के बारे में पता चलता है जिसे 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 पेयर के तौर पर भेजा था.

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

अहम जानकारी: OAuth क्लाइंट को सीएसआरएफ़ से बचाना चाहिए, जैसा कि OAuth2 स्पेसिफ़िकेशन में बताया गया है. ऐसा करने का एक तरीका यह है कि आप state पैरामीटर का इस्तेमाल करके, ऑथराइज़ेशन के अनुरोध और ऑथराइज़ेशन सर्वर के जवाब के बीच की स्थिति बनाए रखें.

login_hint

ज़रूरी नहीं

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

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

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

अनुमति देने वाले यूआरएल के सैंपल

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

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

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

तीसरा चरण: Google, उपयोगकर्ता से सहमति मांगता है

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

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

गड़बड़ियां

Google के OAuth 2.0 अनुमति एंडपॉइंट के अनुरोधों से, पुष्टि करने और अनुमति देने के अनुमानित फ़्लो के बजाय, उपयोगकर्ता को गड़बड़ी के मैसेज दिख सकते हैं. गड़बड़ी के सामान्य कोड और सुझाए गए समाधान यहां दिए गए हैं.

`admin_policy_enforced`

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

`disallowed_useragent`

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

Android

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

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

iOS

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

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

`org_internal`

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

`invalid_grant`

अगर कोड की पुष्टि करने वाले टूल और चैलेंज का इस्तेमाल किया जा रहा है, तो code_callenge पैरामीटर अमान्य है या मौजूद नहीं है. पक्का करें कि code_challenge पैरामीटर सही तरीके से सेट किया गया हो.

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

`redirect_uri_mismatch`

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

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

redirect_uri पैरामीटर, OAuth के ऐसे फ़्लो का रेफ़रंस दे सकता है जो अब काम नहीं करता. अपने इंटिग्रेशन को अपडेट करने के लिए, माइग्रेशन गाइड देखें.

`invalid_request`

आपके अनुरोध में कोई गड़बड़ी थी. ऐसा कई वजहों से हो सकता है:

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

चौथा चरण: 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`	पहले चरण में बनाया गया कोड पुष्टि करने वाला कोड.
`grant_type`	OAuth 2.0 के स्पेसिफ़िकेशन में बताए गए मुताबिक, इस फ़ील्ड की वैल्यू `authorization_code` पर सेट होनी चाहिए.
`redirect_uri`	दिए गए `client_id` के लिए, API Console Credentials page में आपके प्रोजेक्ट के लिए सूची में शामिल रीडायरेक्ट यूआरआई में से एक.

यहां दिया गया स्निपेट, अनुरोध का सैंपल दिखाता है:

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://127.0.0.1:9004&
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 https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

छठा चरण: देखें कि उपयोगकर्ताओं ने कौनसे स्कोप दिए हैं

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

यह देखने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को किसी खास स्कोप का ऐक्सेस दिया है या नहीं, ऐक्सेस टोकन के जवाब में scope फ़ील्ड देखें. access_token से मिले ऐक्सेस के दायरे, स्पेस से अलग किए गए और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं.

उदाहरण के लिए, ऐक्सेस टोकन के जवाब के इस सैंपल से पता चलता है कि उपयोगकर्ता ने आपके ऐप्लिकेशन को, Drive में सिर्फ़ पढ़ने की अनुमति वाली गतिविधि और Calendar इवेंट की अनुमतियों का ऐक्सेस दिया है:

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

Google API को कॉल करना

जब आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाता है, तो किसी उपयोगकर्ता खाते की ओर से 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 के ऑथराइज़ेशन सर्वर (https://oauth2.googleapis.com/token) को एचटीटीपीएस POST अनुरोध भेजता है. इस अनुरोध में ये पैरामीटर शामिल होते हैं:

फ़ील्ड
`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 https://www.googleapis.com/auth/calendar.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 दिखाया जाता है.

ऐप्लिकेशन को रीडायरेक्ट करने के तरीके

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

कस्टम यूआरआई स्कीम, डीपलिंकिंग का एक फ़ॉर्मैट है. यह आपके ऐप्लिकेशन को खोलने के लिए, कस्टम तौर पर तय की गई स्कीम का इस्तेमाल करता है.

Android पर कस्टम यूआरआई स्कीम इस्तेमाल करने का विकल्प

Android के लिए Google Sign-In SDK टूल का इस्तेमाल करें. इससे, OAuth 2.0 का जवाब सीधे आपके ऐप्लिकेशन को मिलता है. साथ ही, रीडायरेक्ट यूआरआई की ज़रूरत भी नहीं पड़ती.

अगर Android पर OAuth इंटिग्रेशन के लिए कस्टम स्कीम का इस्तेमाल किया जाता है, तो आपको 'Android के लिए Google Sign-In' SDK टूल के सुझाए गए वर्शन का इस्तेमाल करने के लिए, ये कार्रवाइयां पूरी करनी होंगी:

Google Sign-In SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
Google API Console में, कस्टम स्कीम के लिए सहायता बंद करें.

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

Google Sign-In के Android SDK टूल पर माइग्रेट करने के लिए, यह तरीका अपनाएं:

Google Sign-In Android SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें:
1. अपने कोड की जांच करके पता लगाएं कि Google के OAuth 2.0 सर्वर को अनुरोध कहां भेजा जा रहा है. कस्टम स्कीम का इस्तेमाल करने पर, आपका अनुरोध नीचे दिए गए उदाहरण की तरह दिखेगा:
```
  https://accounts.google.com/o/oauth2/v2/auth?
  scope=<SCOPES>&
  response_type=code&
  &state=<STATE>&
  redirect_uri=com.example.app:/oauth2redirect&
  client_id=<CLIENT_ID>
  
```
  com.example.app:/oauth2redirect, ऊपर दिए गए उदाहरण में कस्टम स्कीम का रीडायरेक्ट यूआरआई है. कस्टम यूआरआई स्कीम वैल्यू के फ़ॉर्मैट के बारे में ज़्यादा जानने के लिए, redirect_uri पैरामीटर की परिभाषा देखें.
2. scope और client_id अनुरोध पैरामीटर को नोट करें. इनकी मदद से, आपको Google Sign-In SDK टूल को कॉन्फ़िगर करना होगा.
  ध्यान दें: अगर किसी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल किया जा रहा है, तो यह जानकारी पाने के लिए लाइब्रेरी की कॉन्फ़िगरेशन फ़ाइल देखें.
3. SDK टूल सेट अप करने के लिए, अपने Android ऐप्लिकेशन में Google Sign-In को इंटिग्रेट करना शुरू करें निर्देशों का पालन करें. अपने बैकएंड सर्वर का OAuth 2.0 क्लाइंट आईडी पाएं चरण को छोड़ा जा सकता है. ऐसा इसलिए, क्योंकि पिछले चरण से मिले client_id का फिर से इस्तेमाल किया जाएगा.
4. सर्वर साइड एपीआई ऐक्सेस को चालू करने के लिए दिए गए निर्देशों का पालन करें. इसमें ये चरण शामिल हैं:
  1. जिन स्कोप के लिए अनुमति का अनुरोध किया जा रहा है उनके लिए ऑथराइज़ेशन कोड पाने के लिए, getServerAuthCode तरीके का इस्तेमाल करें.
  2. ऑथराइज़ेशन कोड को ऐक्सेस और रीफ़्रेश टोकन के बदले पाने के लिए, अपने ऐप्लिकेशन के बैकएंड पर भेजें.
  3. उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस पाए गए ऐक्सेस टोकन का इस्तेमाल करें.
  ध्यान दें: अगर आपके ऐप्लिकेशन को ऑफ़लाइन ऐक्सेस की ज़रूरत नहीं है, तो क्लाइंट-साइड एपीआई ऐक्सेस का अनुरोध करने के बजाय, इन निर्देशों का पालन करें.
Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करना:
1. अपनी OAuth 2.0 क्रेडेंशियल की सूची पर जाएं और अपना Android क्लाइंट चुनें.
2. बेहतर सेटिंग सेक्शन पर जाएं. इसके बाद, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स से सही का निशान हटाएं. साथ ही, कस्टम यूआरआई स्कीम की सुविधा बंद करने के लिए, सेव करें पर क्लिक करें.

कस्टम यूआरआई स्कीम चालू करना

अगर सुझाया गया विकल्प आपके लिए काम नहीं करता है, तो अपने Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू किए जा सकते हैं. इसके लिए, नीचे दिए गए निर्देशों का पालन करें:

अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
बेहतर सेटिंग सेक्शन पर जाएं. इसके बाद, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स को चुनें और कस्टम यूआरआई स्कीम की सुविधा चालू करने के लिए, सेव करें पर क्लिक करें.

Chrome ऐप्लिकेशन पर कस्टम यूआरएल स्कीम इस्तेमाल करने का विकल्प

Chrome Identity API का इस्तेमाल करें. यह OAuth 2.0 का जवाब सीधे आपके ऐप्लिकेशन को भेजता है. इससे रीडायरेक्ट यूआरआई की ज़रूरत नहीं पड़ती.

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

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

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

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

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

मैन्युअल तरीके से कॉपी/पेस्ट करना (अब काम नहीं करता)

अपने ऐप्लिकेशन को सुरक्षित रखना

ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (Android, Chrome)

ऐप्लिकेशन के नाम पर धोखाधड़ी करने के जोखिम को कम करने के लिए, अपने ऐप्लिकेशन के मालिकाना हक की पुष्टि की जा सकती है.

Android

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

आपके पास Google Play Console में रजिस्टर किया गया ऐसा ऐप्लिकेशन होना चाहिए जिसका पैकेज का नाम और SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट, उस Android OAuth क्लाइंट से मेल खाता हो जिसकी पुष्टि की जा रही है.
आपके पास Google Play Console में, ऐप्लिकेशन के लिए एडमिन की अनुमति होनी चाहिए. Google Play Console में ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.

पुष्टि की प्रक्रिया पूरी करने के लिए, Android क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, मालिकाना हक की पुष्टि करें बटन पर क्लिक करें.

पुष्टि हो जाने पर, आपको एक सूचना दिखेगी. ऐसा न करने पर, आपको गड़बड़ी का मैसेज दिखेगा.

पुष्टि न होने की समस्या को ठीक करने के लिए, यह तरीका आज़माएं:

पक्का करें कि जिस ऐप्लिकेशन की पुष्टि की जा रही है वह Google Play Console में रजिस्टर किया गया ऐप्लिकेशन हो.
पक्का करें कि आपके पास Google Play Console में, ऐप्लिकेशन के लिए एडमिन की अनुमति हो.

Chrome

पुष्टि की प्रक्रिया पूरी करने के लिए, आपको अपने Chrome Web Store डेवलपर खाते का इस्तेमाल करना होगा. पुष्टि की प्रक्रिया पूरी करने के लिए, यहां बताई गई ज़रूरी शर्तें पूरी करनी होंगी:

आपके पास Chrome वेब स्टोर के डेवलपर डैशबोर्ड में, रजिस्टर किया गया कोई आइटम होना चाहिए. साथ ही, उस आइटम का आईडी, Chrome एक्सटेंशन के उस OAuth क्लाइंट के आईडी से मेल खाना चाहिए जिसकी पुष्टि की जा रही है.
आपके पास Chrome Web Store आइटम के लिए पब्लिशर की भूमिका होनी चाहिए. Chrome Web Store के डेवलपर डैशबोर्ड में, ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.

Chrome एक्सटेंशन क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, पुष्टि की प्रोसेस पूरी करने के लिए मालिकाना हक की पुष्टि करें बटन पर क्लिक करें.

ध्यान दें: अपने खाते का ऐक्सेस देने के बाद, पुष्टि की प्रोसेस पूरी करने से पहले कुछ मिनट इंतज़ार करें.

पुष्टि न होने की समस्या को ठीक करने के लिए, यह तरीका आज़माएं:

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

ऐप्लिकेशन की जांच करना (सिर्फ़ iOS के लिए)

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

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करना

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच की सुविधा चालू करने के लिए, आपको यहां दी गई ज़रूरी शर्तें पूरी करनी होंगी:

आपको अपने iOS क्लाइंट के लिए टीम आईडी देना होगा.
आपको अपने बंडल आईडी में वाइल्डकार्ड का इस्तेमाल नहीं करना चाहिए, क्योंकि यह एक से ज़्यादा ऐप्लिकेशन को रिज़ॉल्व कर सकता है. इसका मतलब है कि बंडल आईडी में तारे का निशान (*) नहीं होना चाहिए.

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

App Check की सुविधा चालू करने के लिए, अपने iOS क्लाइंट के बदलाव वाले व्यू में, Firebase App Check की मदद से अपने OAuth क्लाइंट को गलत इस्तेमाल से बचाएं टॉगल बटन को चालू करें.

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

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

पुष्टि करें कि आपने जो बंडल आईडी और टीम आईडी डाला है वह मान्य है.
पुष्टि करें कि बंडल आईडी के लिए वाइल्डकार्ड का इस्तेमाल न किया जा रहा हो.

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा को लागू करना

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

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

इन मेट्रिक की समीक्षा करके जानें कि ऐप्लिकेशन की जांच की सुविधा लागू करने से, आपके उपयोगकर्ताओं पर क्या असर पड़ेगा.

ऐप्लिकेशन की जांच करने की सुविधा लागू करने के लिए, ENFORCE बटन पर क्लिक करें और अपनी पसंद की पुष्टि करें. नीति उल्लंघन ठीक करने की प्रोसेस चालू होने के बाद, आपके क्लाइंट के ऐसे सभी अनुरोध अस्वीकार कर दिए जाएंगे जिनकी पुष्टि नहीं हुई है.

ध्यान दें: नीति उल्लंघन ठीक करने की सुविधा चालू करने के बाद, बदलाव लागू होने में 15 मिनट लग सकते हैं.

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच की सुविधा बंद करना

अपने ऐप्लिकेशन के लिए ऐप्लिकेशन की जांच की ज़रूरी शर्तें हटाने पर, शर्तों को लागू करने की प्रोसेस रुक जाएगी. साथ ही, आपके क्लाइंट से Google OAuth 2.0 एंडपॉइंट पर किए जाने वाले सभी अनुरोधों को अनुमति मिल जाएगी. इनमें ऐसे अनुरोध भी शामिल हैं जिनकी पुष्टि नहीं की गई है.

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच की सुविधा को लागू होने से रोकने के लिए, iOS क्लाइंट के 'बदलाव करें' व्यू पर जाएं और लागू न करें बटन पर क्लिक करें. इसके बाद, अपनी पसंद की पुष्टि करें.

ध्यान दें: ऐप्लिकेशन की जांच की ज़रूरी शर्त हटाने के बाद, बदलावों को लागू होने में 15 मिनट तक लग सकते हैं.

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा बंद करना

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

अपने iOS क्लाइंट के लिए, App Check की सुविधा बंद करने के लिए, iOS क्लाइंट के 'बदलाव करें' व्यू पर जाएं और Firebase App Check की मदद से, अपने OAuth क्लाइंट को गलत इस्तेमाल से बचाएं टॉगल बटन को बंद करें.

ध्यान दें: ऐप्लिकेशन की जांच की सुविधा बंद करने के बाद, बदलावों को लागू होने में 15 मिनट तक लग सकते हैं.

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

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

'सभी खातों की सुरक्षा' सुविधा लागू करना

अपने उपयोगकर्ताओं के खातों को सुरक्षित रखने के लिए, आपको एक और कदम उठाना चाहिए. इसके लिए, 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

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

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

लाइब्रेरी और सैंपल

ज़रूरी शर्तें

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

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

Android

iOS

UWP

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

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

पहला चरण: कोड की पुष्टि करने वाला कोड और चैलेंज जनरेट करना

कोड की पुष्टि करने वाला टूल बनाना

कोड चैलेंज बनाना

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

अनुमति देने वाले यूआरएल के सैंपल

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

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

तीसरा चरण: Google, उपयोगकर्ता से सहमति मांगता है

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_grant

redirect_uri_mismatch

invalid_request

चौथा चरण: OAuth 2.0 सर्वर के जवाब को मैनेज करना

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

छठा चरण: देखें कि उपयोगकर्ताओं ने कौनसे स्कोप दिए हैं

Google API को कॉल करना

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

curl के उदाहरण

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

टोकन रद्द करना

ऐप्लिकेशन को रीडायरेक्ट करने के तरीके

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

Android पर कस्टम यूआरआई स्कीम इस्तेमाल करने का विकल्प

'Android के लिए Google साइन इन' SDK टूल पर माइग्रेट करने का तरीका

कस्टम यूआरआई स्कीम चालू करना

Chrome ऐप्लिकेशन पर कस्टम यूआरएल स्कीम इस्तेमाल करने का विकल्प

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

मैन्युअल तरीके से कॉपी/पेस्ट करना (अब काम नहीं करता)

अपने ऐप्लिकेशन को सुरक्षित रखना

ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (Android, Chrome)

Android

Chrome

ऐप्लिकेशन की जांच करना (सिर्फ़ iOS के लिए)

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करना

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा को लागू करना

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच की सुविधा बंद करना

अपने iOS क्लाइंट के लिए, ऐप्लिकेशन की जांच करने की सुविधा बंद करना

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

'सभी खातों की सुरक्षा' सुविधा लागू करना

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण