हम Data API को अपडेट कर रहे हैं, ताकि यह Shorts पर मिले व्यू की गिनती करने के तरीके से मेल खा सके. ज़्यादा जानें

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

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

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

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

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

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

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

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

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

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

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

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

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

Open the API Library में Google API Console.
If prompted, select a project, or create a new one.
YouTube Data API ढूंढने और उसे चालू करने के लिए, लाइब्रेरी पेज का इस्तेमाल करें. अपने ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले अन्य एपीआई ढूंढें और उन्हें भी चालू करें.

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

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

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

Android

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

iOS

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

UWP

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

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

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

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

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

YouTube Data API v3, इन स्कोप का इस्तेमाल करता है:

दायरा	ब्यौरा
`https://www.googleapis.com/auth/youtube`	अपना YouTube खाता मैनेज करें
`https://www.googleapis.com/auth/youtube.channel-memberships.creator`	अपने चैनल के मौजूदा सक्रिय सदस्यों की सूची और उनका मौजूदा लेवल देखें. यह भी देखें कि वे चैनल के सदस्य कब बने
`https://www.googleapis.com/auth/youtube.force-ssl`	अपने YouTube वीडियो की रेटिंग, टिप्पणियां और कैप्शन देखें, उनमें बदलाव करें और उन्हें हमेशा के लिए मिटाएं
`https://www.googleapis.com/auth/youtube.readonly`	अपना YouTube खाता देखें
`https://www.googleapis.com/auth/youtube.upload`	अपने YouTube वीडियो मैनेज करें
`https://www.googleapis.com/auth/youtubepartner`	YouTube पर अपनी परिसंपत्ति और संबंधित सामग्री देखें व प्रबंधित करें
`https://www.googleapis.com/auth/youtubepartner-channel-audit`	किसी YouTube भागीदार की ऑडिट प्रक्रिया के दौरान उससे प्रासंगिक अपने YouTube चैनल की निजी जानकारी देखें

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

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

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

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

पहला चरण: कोड वेरिफ़ायर और चैलेंज जनरेट करना

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

कोड वेरिफ़ायर बनाना

code_verifier एक हाई-एंट्रॉपी क्रिप्टोग्राफ़िक रैंडम स्ट्रिंग है. इसमें आरक्षित नहीं किए गए वर्ण [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" का इस्तेमाल किया जाता है. इसकी लंबाई कम से कम 43 वर्ण और ज़्यादा से ज़्यादा 128 वर्ण होती है.

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

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

कोड चैलेंज बनाने के दो तरीके इस्तेमाल किए जा सकते हैं.

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

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

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

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

पैरामीटर

client_id

ज़रूरी है

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

redirect_uri

ज़रूरी है

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

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

YouTube Data API v3, इन स्कोप का इस्तेमाल करता है:

दायरा	ब्यौरा
`https://www.googleapis.com/auth/youtube`	अपना YouTube खाता मैनेज करें
`https://www.googleapis.com/auth/youtube.channel-memberships.creator`	अपने चैनल के मौजूदा सक्रिय सदस्यों की सूची और उनका मौजूदा लेवल देखें. यह भी देखें कि वे चैनल के सदस्य कब बने
`https://www.googleapis.com/auth/youtube.force-ssl`	अपने YouTube वीडियो की रेटिंग, टिप्पणियां और कैप्शन देखें, उनमें बदलाव करें और उन्हें हमेशा के लिए मिटाएं
`https://www.googleapis.com/auth/youtube.readonly`	अपना YouTube खाता देखें
`https://www.googleapis.com/auth/youtube.upload`	अपने YouTube वीडियो मैनेज करें
`https://www.googleapis.com/auth/youtubepartner`	YouTube पर अपनी परिसंपत्ति और संबंधित सामग्री देखें व प्रबंधित करें
`https://www.googleapis.com/auth/youtubepartner-channel-audit`	किसी YouTube भागीदार की ऑडिट प्रक्रिया के दौरान उससे प्रासंगिक अपने YouTube चैनल की निजी जानकारी देखें

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

code_challenge

सुझाया गया

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

code_challenge_method

सुझाया गया

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

state

सुझाया गया

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

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

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

login_hint

ज़रूरी नहीं

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

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

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

अनुमति देने वाले यूआरएल के उदाहरण

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

हर यूआरएल, ऐसे स्कोप का ऐक्सेस मांगता है जिससे उपयोगकर्ता के YouTube खाते को देखा जा सकता है.

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

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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 Workspace एडमिन की नीतियों की वजह से, Google खाता अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे सकता. Google Workspace एडमिन के लिए सहायता लेख यह कंट्रोल करना कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले किन ऐप्लिकेशन की मदद से Google Workspace के डेटा को ऐक्सेस किया जा सकता है पढ़ें. इसमें इस बारे में ज़्यादा जानकारी दी गई है कि एडमिन, सभी स्कोप या संवेदनशील और पाबंदी वाले स्कोप के ऐक्सेस को तब तक सीमित कैसे कर सकता है, जब तक आपके OAuth क्लाइंट आईडी को साफ़ तौर पर ऐक्सेस करने की अनुमति नहीं मिल जाती.

`disallowed_useragent`

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

Android

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

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

iOS

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

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

`org_internal`

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

`deleted_client`

अनुरोध करने के लिए इस्तेमाल किए जा रहे OAuth क्लाइंट को मिटा दिया गया है. क्लाइंट को मैन्युअल तरीके से मिटाया जा सकता है. इसके अलावा, इस्तेमाल नहीं किए जा रहे क्लाइंट के मामले में, क्लाइंट अपने-आप मिट जाते हैं. मिटाए गए क्लाइंट को मिटाने के 30 दिनों के अंदर वापस लाया जा सकता है. ज़्यादा जानें .

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

redirect_uri पैरामीटर, OAuth के आउट-ऑफ़-बैंड (OOB) फ़्लो को रेफ़र कर सकता है. यह फ़्लो अब काम नहीं करता. अपने इंटिग्रेशन को अपडेट करने के लिए, माइग्रेशन गाइड देखें.

`invalid_request`

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

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

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

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

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

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

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

फ़ील्ड
`client_id`	यह क्लाइंट आईडी, से मिला है.
`client_secret`	क्लाइंट सीक्रेट, से मिला है.
`code`	यह शुरुआती अनुरोध से मिला ऑथराइज़ेशन कोड है.
`code_verifier`	पहले चरण में बनाया गया कोड वेरिफ़ायर.
`grant_type`	OAuth 2.0 की खास बातों में बताए गए तरीके के मुताबिक, इस फ़ील्ड की वैल्यू `authorization_code` पर सेट होनी चाहिए.
`redirect_uri`	आपके प्रोजेक्ट के लिए, में दिए गए रीडायरेक्ट यूआरआई में से कोई एक , दिए गए `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://127.0.0.1:9004&
grant_type=authorization_code

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

जवाब में ये फ़ील्ड शामिल होते हैं:

फ़ील्ड
`access_token`	यह टोकन, आपका ऐप्लिकेशन Google API के अनुरोध को अनुमति देने के लिए भेजता है.
`expires_in`	ऐक्सेस टोकन की बची हुई लाइफ़टाइम, सेकंड में.
`id_token`	ध्यान दें: यह प्रॉपर्टी सिर्फ़ तब दिखाई जाती है, जब आपके अनुरोध में पहचान का स्कोप शामिल हो. जैसे, `openid`, `profile` या `email`. इसकी वैल्यू, JSON Web Token (JWT) होती है. इसमें उपयोगकर्ता की पहचान की जानकारी होती है, जिस पर डिजिटल हस्ताक्षर किया गया होता है.
`refresh_token`	यह एक ऐसा टोकन होता है जिसका इस्तेमाल करके, नया ऐक्सेस टोकन पाया जा सकता है. रीफ़्रेश टोकन तब तक मान्य होते हैं, जब तक उपयोगकर्ता ऐक्सेस रद्द नहीं कर देता या रीफ़्रेश टोकन की समयसीमा खत्म नहीं हो जाती. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के लिए, रीफ़्रेश टोकन हमेशा दिखाए जाते हैं.
`refresh_token_expires_in`	रीफ़्रेश टोकन की बची हुई लाइफ़टाइम, सेकंड में. यह वैल्यू सिर्फ़ तब सेट होती है, जब उपयोगकर्ता समयसीमा के हिसाब से ऐक्सेस देता है.
`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/youtube.force-ssl",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

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

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

ज़्यादा जानकारी के लिए, अनुमति देने के अलग-अलग विकल्पों को मैनेज करने का तरीका लेख पढ़ें.

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

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

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

Google API को कॉल करना

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

ध्यान दें कि YouTube Data API, सेवा खातों का इस्तेमाल सिर्फ़ उन YouTube कॉन्टेंट के मालिकों के लिए करता है जिनके पास एक से ज़्यादा YouTube चैनल हैं और वे उन्हें मैनेज करते हैं. जैसे, रिकॉर्ड लेबल और फ़िल्म स्टूडियो.

OAuth 2.0 Playground पर जाकर, Google के सभी एपीआई आज़माए जा सकते हैं. साथ ही, उनके स्कोप देखे जा सकते हैं.

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

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, youtube.channels एंडपॉइंट (YouTube Data API) को किया गया कॉल इस तरह दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन डालना होगा:

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

यहां पुष्टि किए गए उपयोगकर्ता के लिए, access_token क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, उसी एपीआई को कॉल किया गया है:

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

`curl` के उदाहरण

curl कमांड-लाइन ऐप्लिकेशन की मदद से, इन कमांड की जांच की जा सकती है. यहां एचटीटीपी हेडर विकल्प (पसंदीदा) का इस्तेमाल करने वाला एक उदाहरण दिया गया है:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर का विकल्प भी इस्तेमाल किया जा सकता है:

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

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

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

ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन 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",
  "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 पर कस्टम यूआरआई स्कीम इस्तेमाल करने का विकल्प

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

Google Identity Services Android Library पर माइग्रेट करने का तरीका

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

Google Identity Services Android Library का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
Google Cloud Console में, कस्टम स्कीम के लिए सहायता बंद करें.

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

Google Identity Services Android Library पर माइग्रेट करने का तरीका यहां बताया गया है:

Google Identity Services Android Library का इस्तेमाल करने के लिए, अपने कोड को अपडेट करें:
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. एसडीके टूल सेट अप करने के लिए, Google उपयोगकर्ता के डेटा का ऐक्सेस देने की अनुमति दें निर्देशों का पालन करें. Google Cloud Console प्रोजेक्ट सेट अप करें चरण को छोड़ा जा सकता है, क्योंकि आपको पिछले चरण से मिला client_id फिर से इस्तेमाल करना होगा.
4. उपयोगकर्ता की कार्रवाइयों के लिए ज़रूरी अनुमतियों का अनुरोध करें निर्देशों का पालन करें. इसमें ये चरण शामिल हैं:
  1. उपयोगकर्ता से अनुमतियों का अनुरोध करें.
  2. getServerAuthCode तरीके का इस्तेमाल करके, उन स्कोप के लिए पुष्टि करने वाला कोड पाएं जिनके लिए अनुमति का अनुरोध किया जा रहा है.
  3. अपने ऐप्लिकेशन के बैकएंड को ऑथराइज़ेशन कोड भेजें, ताकि उसे ऐक्सेस और रीफ़्रेश टोकन के बदले में बदला जा सके.
  4. उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस पाए गए ऐक्सेस टोकन का इस्तेमाल करें.
  ध्यान दें: अगर आपके ऐप्लिकेशन को सिर्फ़ पुष्टि करने के स्कोप की ज़रूरत है, तो सुझाई गई Credential Manager Library का इस्तेमाल करने के लिए, इन निर्देशों का पालन करें.
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 डेस्कटॉप (लेकिन Universal 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 Web Store Developer Dashboard में रजिस्टर किया गया कोई आइटम होना चाहिए. साथ ही, उसका आईडी वही होना चाहिए जो उस Chrome एक्सटेंशन OAuth क्लाइंट का है जिसकी पुष्टि की जा रही है.
आपके पास Chrome Web Store आइटम के लिए पब्लिशर खाता होना चाहिए. Chrome Web Store के डेवलपर डैशबोर्ड में, ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.

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

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

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

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

App Check (सिर्फ़ iOS के लिए)

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

अपने iOS क्लाइंट के लिए App Check चालू करना

अपने iOS क्लाइंट के लिए App Check को चालू करने के लिए, यहां दी गई ज़रूरी शर्तें पूरी करनी होंगी:

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

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

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

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

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

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

अपने iOS क्लाइंट के लिए App Check लागू करना

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

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

इन मेट्रिक को देखें और जानें कि App Check लागू करने से, आपके उपयोगकर्ताओं पर क्या असर पड़ेगा.

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

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

अपने iOS क्लाइंट के लिए, App Check को लागू न करना

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

अपने iOS क्लाइंट के लिए, App Check को लागू न करने के लिए, iOS क्लाइंट के बदलाव करने वाले व्यू पर जाएं. इसके बाद, लागू न करें बटन पर क्लिक करें और अपने विकल्प की पुष्टि करें.

ध्यान दें: App Check को लागू न करने के बाद, बदलावों को लागू होने में 15 मिनट तक लग सकते हैं.

अपने iOS क्लाइंट के लिए App Check की सुविधा बंद करना

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

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

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

समय के हिसाब से ऐक्सेस

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

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

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

IETF के सबसे सही तरीके OAuth 2.0 for Native Apps में, यहां बताए गए कई सबसे सही तरीके शामिल हैं.

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

अपने उपयोगकर्ताओं के खातों को सुरक्षित रखने के लिए, आपको एक और कदम उठाना चाहिए. इसके लिए, Google की Cross-Account Protection Service का इस्तेमाल करके, Cross-Account Protection लागू करें. इस सेवा की मदद से, सुरक्षा से जुड़ी घटनाओं की सूचनाएं पाने के लिए सदस्यता ली जा सकती है. इससे आपके ऐप्लिकेशन को, उपयोगकर्ता के खाते में हुए बड़े बदलावों के बारे में जानकारी मिलती है. इसके बाद, इस जानकारी का इस्तेमाल करके कार्रवाई की जा सकती है. यह इस बात पर निर्भर करता है कि आपको इवेंट का जवाब कैसे देना है.

Google की Cross-Account Protection Service, आपके ऐप्लिकेशन को इस तरह के इवेंट भेजती है:

https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
https://schemas.openid.net/secevent/risc/event-type/account-disabled

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

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

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

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

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

Android

iOS

UWP

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

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

पहला चरण: कोड वेरिफ़ायर और चैलेंज जनरेट करना

कोड वेरिफ़ायर बनाना

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

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

अनुमति देने वाले यूआरएल के उदाहरण

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

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

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

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

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

Google API को कॉल करना

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

curl के उदाहरण

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

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

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

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

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

Google Identity Services Android Library पर माइग्रेट करने का तरीका

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

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

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

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

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

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

Android

Chrome

App Check (सिर्फ़ iOS के लिए)

अपने iOS क्लाइंट के लिए App Check चालू करना

अपने iOS क्लाइंट के लिए App Check लागू करना

अपने iOS क्लाइंट के लिए, App Check को लागू न करना

अपने iOS क्लाइंट के लिए App Check की सुविधा बंद करना

समय के हिसाब से ऐक्सेस

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

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण