इस दस्तावेज़ में बताया गया है कि फ़ोन, टैबलेट, और कंप्यूटर जैसे डिवाइसों पर इंस्टॉल किए गए ऐप्लिकेशन, YouTube Data API को ऐक्सेस करने की अनुमति देने के लिए, Google के OAuth 2.0 एंडपॉइंट का इस्तेमाल कैसे करते हैं.
OAuth 2.0 की मदद से, उपयोगकर्ता अपने उपयोगकर्ता नाम, पासवर्ड, और अन्य जानकारी को निजी रखते हुए, किसी ऐप्लिकेशन के साथ खास डेटा शेयर कर सकते हैं. उदाहरण के लिए, कोई ऐप्लिकेशन OAuth 2.0 का इस्तेमाल करके, उपयोगकर्ता के YouTube चैनल पर वीडियो अपलोड करने की अनुमति पा सकता है.
इंस्टॉल किए गए ऐप्लिकेशन, अलग-अलग डिवाइसों पर डिस्ट्रिब्यूट किए जाते हैं. साथ ही, यह माना जाता है कि ये ऐप्लिकेशन गोपनीय जानकारी को सुरक्षित नहीं रख सकते. उपयोगकर्ता के ऐप्लिकेशन पर मौजूद होने या ऐप्लिकेशन के बैकग्राउंड में चलने के दौरान, ये Google API ऐक्सेस कर सकते हैं.
अनुमति देने का यह तरीका, वेब सर्वर ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले तरीके से मिलता-जुलता है. मुख्य अंतर यह है कि इंस्टॉल किए गए ऐप्लिकेशन को सिस्टम ब्राउज़र खोलना होगा और Google के अनुमति देने वाले सर्वर से मिले रिस्पॉन्स को मैनेज करने के लिए, एक स्थानीय रीडायरेक्ट यूआरआई देना होगा.
विकल्प
मोबाइल ऐप्लिकेशन के लिए, Android या iOS के लिए, 'Google साइन इन' का इस्तेमाल किया जा सकता है. Google साइन-इन क्लाइंट लाइब्रेरी, पुष्टि करने और उपयोगकर्ता की अनुमति देने की प्रोसेस को मैनेज करती हैं. साथ ही, इन लाइब्रेरी को लागू करना, यहां बताए गए निचले लेवल के प्रोटोकॉल के मुकाबले आसान हो सकता है.
ऐसे डिवाइसों पर चलने वाले ऐप्लिकेशन के लिए जिन पर सिस्टम ब्राउज़र काम नहीं करता या जिनमें इनपुट की सुविधाएं सीमित होती हैं, जैसे कि टीवी, गेम कंसोल, कैमरे या प्रिंटर, टीवी और डिवाइसों के लिए OAuth 2.0 या टीवी और सीमित इनपुट वाले डिवाइसों पर साइन इन करना लेख पढ़ें.
लाइब्रेरी और सैंपल
हमारा सुझाव है कि इस दस्तावेज़ में बताए गए OAuth 2.0 फ़्लो को लागू करने के लिए, यहां दी गई लाइब्रेरी और सैंपल का इस्तेमाल करें:
- Android के लिए AppAuth लाइब्रेरी
- iOS के लिए AppAuth लाइब्रेरी
- ऐप्लिकेशन के लिए OAuth: Windows के लिए सैंपल
ज़रूरी शर्तें
अपने प्रोजेक्ट के लिए एपीआई चालू करना
Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को, उन एपीआई को में चालू करना होगा.
अपने प्रोजेक्ट के लिए एपीआई चालू करने के लिए:
- में .
- YouTube Data API ढूंढने और उसे चालू करने के लिए, लाइब्रेरी पेज का इस्तेमाल करें. ऐसे अन्य एपीआई ढूंढें जिनका इस्तेमाल आपका ऐप्लिकेशन करेगा और उन्हें भी चालू करें.
अनुमति देने वाले क्रेडेंशियल बनाना
Google के एपीआई को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करने वाले किसी भी ऐप्लिकेशन के पास, अनुमति देने वाले ऐसे क्रेडेंशियल होने चाहिए जिनसे Google के OAuth 2.0 सर्वर को ऐप्लिकेशन की पहचान की जा सके. यहां अपने प्रोजेक्ट के लिए क्रेडेंशियल बनाने का तरीका बताया गया है. इसके बाद, आपके ऐप्लिकेशन उन एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल का इस्तेमाल कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए चालू किया है.
- क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी पर क्लिक करें.
- यहां दिए गए सेक्शन में, क्लाइंट टाइप के बारे में बताया गया है. ये ऐसे क्लाइंट टाइप हैं जिनके साथ Google का अनुमति देने वाला सर्वर काम करता है. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें, अपने OAuth क्लाइंट को नाम दें, और फ़ॉर्म में अन्य फ़ील्ड को ज़रूरत के मुताबिक सेट करें.
Android
- Android ऐप्लिकेशन का टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के पर दिखाया जाता है.
- अपने Android ऐप्लिकेशन का पैकेज नाम डालें. यह वैल्यू, आपकी ऐप्लिकेशन मेनिफ़ेस्ट फ़ाइल में
<manifest>
एलिमेंट केpackage
एट्रिब्यूट में दी गई होती है. - ऐप्लिकेशन डिस्ट्रिब्यूशन के SHA-1 साइनिंग सर्टिफ़िकेट का फ़िंगरप्रिंट डालें.
- अगर आपका ऐप्लिकेशन, Google Play की ऐप्लिकेशन साइनिंग सेवा का इस्तेमाल करता है, तो Play Console के ऐप्लिकेशन साइनिंग पेज से SHA-1 फ़िंगरप्रिंट कॉपी करें.
- अगर आपने अपना कीस्टोर और हस्ताक्षर करने की कुंजियां मैनेज की हैं, तो सर्टिफ़िकेट की जानकारी को ऐसे फ़ॉर्मैट में प्रिंट करें जिसे कोई भी पढ़ सके. इसके लिए, Java के साथ शामिल keytool टूल का इस्तेमाल करें. keytool आउटपुट के
Certificate fingerprints
सेक्शन में मौजूदSHA1
वैल्यू को कॉपी करें. ज़्यादा जानकारी के लिए, Android के लिए Google API के दस्तावेज़ में, अपने क्लाइंट की पुष्टि करना देखें.
- (ज़रूरी नहीं) अपने Android ऐप्लिकेशन के मालिकाना हक की पुष्टि करें.
- बनाएं पर क्लिक करें.
iOS
- iOS ऐप्लिकेशन टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के पर दिखाया जाता है.
- अपने ऐप्लिकेशन का बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की जानकारी वाली प्रॉपर्टी की सूची वाली संसाधन फ़ाइल (info.plist) में मौजूद CFBundleIdentifier बटन की वैल्यू होती है. वैल्यू आम तौर पर, Xcode प्रोजेक्ट एडिटर के सामान्य पैनल या हस्ताक्षर और सुविधाओं के पैनल में दिखती है. बंडल आईडी, Apple की App Store Connect साइट पर, ऐप्लिकेशन के 'ऐप्लिकेशन की जानकारी' पेज के 'सामान्य जानकारी' सेक्शन में भी दिखता है.
पक्का करें कि आपने अपने ऐप्लिकेशन के लिए सही बंडल आईडी का इस्तेमाल किया हो. ऐसा इसलिए, क्योंकि ऐप्लिकेशन की जांच करने की सुविधा का इस्तेमाल करने पर, इसे बदला नहीं जा सकता.
- (ज़रूरी नहीं)
अगर आपका ऐप्लिकेशन Apple के App Store में पब्लिश किया गया है, तो अपने ऐप्लिकेशन का App Store आईडी डालें. स्टोर आईडी, संख्याओं वाली एक स्ट्रिंग होती है. यह हर Apple App Store यूआरएल में शामिल होती है.
- अपने iOS या iPadOS डिवाइस पर, Apple App Store ऐप्लिकेशन खोलें.
- अपना ऐप्लिकेशन खोजें.
- शेयर करें बटन (स्क्वेयर और अप ऐरो का निशान) चुनें.
- लिंक कॉपी करें को चुनें.
- लिंक को टेक्स्ट एडिटर में चिपकाएं. App Store आईडी, यूआरएल का आखिरी हिस्सा होता है.
उदाहरण:
https://apps.apple.com/app/google/id284815942
- (ज़रूरी नहीं)
अपना टीम आईडी डालें. ज़्यादा जानकारी के लिए, Apple Developer खाते के दस्तावेज़ में, अपना टीम आईडी ढूंढना लेख पढ़ें.
ध्यान दें: अगर आपको अपने क्लाइंट के लिए ऐप्लिकेशन की जांच की सुविधा चालू करनी है, तो टीम आईडी फ़ील्ड भरना ज़रूरी है. - (ज़रूरी नहीं)
अपने iOS ऐप्लिकेशन के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करें. ऐप्लिकेशन की जांच करने की सुविधा चालू करने पर, Apple की ऐप्लिकेशन की पुष्टि करने वाली सेवा का इस्तेमाल करके यह पुष्टि की जाती है कि आपके OAuth क्लाइंट से मिले OAuth 2.0 अनुरोध, सही और आपके ऐप्लिकेशन से मिले हैं. इससे, ऐप्लिकेशन के नाम पर धोखाधड़ी करने के जोखिम को कम करने में मदद मिलती है. अपने iOS ऐप्लिकेशन के लिए, ऐप्लिकेशन की जांच करने की सुविधा चालू करने के बारे में ज़्यादा जानें.
- बनाएं पर क्लिक करें.
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 एपीआई स्कोप दस्तावेज़ में, उन स्कोप की पूरी सूची होती है जिनका इस्तेमाल 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 (बिना पैडिंग के) में बदला गया है.
|
plain | कोड चैलेंज की वैल्यू, ऊपर जनरेट किए गए कोड की पुष्टि करने वाले कोड की वैल्यू से मेल खाती है.
|
दूसरा चरण: Google के OAuth 2.0 सर्वर को अनुरोध भेजना
उपयोगकर्ता की अनुमति पाने के लिए, https://accounts.google.com/o/oauth2/v2/auth
पर Google के ऑथराइज़ेशन सर्वर को अनुरोध भेजें. यह एंडपॉइंट, ऐक्टिव सेशन लुकअप को हैंडल करता है,
उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. एंडपॉइंट को सिर्फ़ एसएसएल के ज़रिए ऐक्सेस किया जा सकता है. साथ ही, यह एंडपॉइंट एचटीटीपी (गैर-एसएसएल) कनेक्शन को स्वीकार नहीं करता.
अनुमति देने वाला सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए इन क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:
पैरामीटर | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
ज़रूरी है
आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू आपको में दिखेगी. |
||||||||||||||||
redirect_uri |
ज़रूरी है
इससे यह तय होता है कि Google का अनुमति देने वाला सर्वर, आपके ऐप्लिकेशन को जवाब कैसे भेजता है. इंस्टॉल किए गए ऐप्लिकेशन के लिए, रीडायरेक्ट करने के कई विकल्प उपलब्ध होते हैं. साथ ही, आपने रीडायरेक्ट करने के किसी खास तरीके को ध्यान में रखकर, अपने अनुमति देने वाले क्रेडेंशियल सेट अप किए होंगे. यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. आपने अपने क्लाइंट के
में इसे कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले यूआरआई से मेल नहीं खाती है, तो आपको नीचे दी गई टेबल में, हर तरीके के लिए
|
||||||||||||||||
response_type |
ज़रूरी है
इससे यह पता चलता है कि Google OAuth 2.0 एंडपॉइंट, ऑथराइज़ेशन कोड दिखाता है या नहीं. इंस्टॉल किए गए ऐप्लिकेशन के लिए, पैरामीटर की वैल्यू को |
||||||||||||||||
scope |
ज़रूरी है
स्पेस से अलग किए गए स्कोप की सूची, जो उन संसाधनों की पहचान करती है जिन्हें आपका ऐप्लिकेशन उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. इन वैल्यू से, सहमति वाली उस स्क्रीन के बारे में पता चलता है जिसे Google, उपयोगकर्ता को दिखाता है. स्कोप की मदद से, आपका ऐप्लिकेशन सिर्फ़ उन संसाधनों का ऐक्सेस पाने का अनुरोध कर सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ताओं को यह कंट्रोल करने की सुविधा मिलती है कि वे आपके ऐप्लिकेशन को कितना ऐक्सेस दें. इसलिए, अनुरोध किए गए स्कोप की संख्या और उपयोगकर्ता की सहमति मिलने की संभावना के बीच उलटा संबंध होता है. YouTube Data API v3, इन स्कोप का इस्तेमाल करता है:
OAuth 2.0 API के स्कोप दस्तावेज़ में, उन स्कोप की पूरी सूची दी गई है जिनका इस्तेमाल करके Google API को ऐक्सेस किया जा सकता है. |
||||||||||||||||
code_challenge |
सुझाया गया
कोड में बदले गए |
||||||||||||||||
code_challenge_method |
सुझाया गया
इससे पता चलता है कि |
||||||||||||||||
state |
सुझाया गया
इस एट्रिब्यूट की वैल्यू, स्ट्रिंग होती है. आपका ऐप्लिकेशन, अनुमति के अनुरोध और अनुमति देने वाले सर्वर के जवाब के बीच स्थिति बनाए रखने के लिए, इस वैल्यू का इस्तेमाल करता है.
उपयोगकर्ता आपके ऐप्लिकेशन के ऐक्सेस अनुरोध को स्वीकार करने या अस्वीकार करने के बाद, सर्वर वही सटीक वैल्यू दिखाता है जिसे आपने इस पैरामीटर का इस्तेमाल कई कामों के लिए किया जा सकता है. जैसे, उपयोगकर्ता को अपने ऐप्लिकेशन में सही संसाधन पर ले जाना, नॉन्स भेजना, और किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध को कम करना. आपके |
||||||||||||||||
login_hint |
ज़रूरी नहीं
अगर आपके ऐप्लिकेशन को पता है कि कौनसा उपयोगकर्ता पुष्टि करने की कोशिश कर रहा है, तो वह Google Authentication Server को संकेत देने के लिए, इस पैरामीटर का इस्तेमाल कर सकता है. सर्वर, संकेत का इस्तेमाल करके साइन इन फ़ॉर्म में ईमेल फ़ील्ड को पहले से भरकर या एक से ज़्यादा लॉगिन सेशन में से सही सेशन चुनकर, लॉगिन फ़्लो को आसान बनाता है. पैरामीटर की वैल्यू को किसी ईमेल पते या |
अनुमति देने वाले यूआरएल के सैंपल
नीचे दिए गए टैब में, रीडायरेक्ट यूआरआई के अलग-अलग विकल्पों के लिए, अनुमति वाले यूआरएल के सैंपल दिखाए गए हैं.
हर यूआरएल, उस स्कोप का ऐक्सेस पाने का अनुरोध करता है जिससे उपयोगकर्ता के 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 खाता, अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे पा रहा है. ऐसा, 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 क्लाइंट आईडी के लिए अनुमति वाले
रीडायरेक्ट यूआरआई से मेल नहीं खाता. में जाकर, अनुमति वाले रीडायरेक्ट यूआरआई की समीक्षा करें.
क्लाइंट टाइप के लिए, पास किया गया 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 |
से मिला क्लाइंट आईडी. |
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 वेब टोकन (JWT) होती है. इसमें उपयोगकर्ता की पहचान की जानकारी होती है, जिस पर डिजिटल हस्ताक्षर किया गया हो. |
refresh_token |
ऐसा टोकन जिसका इस्तेमाल करके नया ऐक्सेस टोकन हासिल किया जा सकता है. रीफ़्रेश टोकन तब तक मान्य रहते हैं, जब तक उपयोगकर्ता ऐक्सेस रद्द नहीं कर देता. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के लिए, रीफ़्रेश टोकन हमेशा दिखाए जाते हैं. |
scope |
access_token से मिले ऐक्सेस के दायरे, स्पेस से अलग की गई, केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं. |
token_type |
दिखाया गया टोकन टाइप. फ़िलहाल, इस फ़ील्ड की वैल्यू हमेशा
Bearer पर सेट होती है. |
यहां दिया गया स्निपेट, जवाब का एक सैंपल दिखाता है:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
छठा चरण: देखें कि उपयोगकर्ताओं ने कौनसे स्कोप दिए हैं
एक साथ कई स्कोप का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए सभी स्कोप को अनुमति न दें. आपके ऐप्लिकेशन को हमेशा यह देखना चाहिए कि उपयोगकर्ता ने किन स्कोप को अनुमति दी है. साथ ही, ज़रूरी सुविधाओं को बंद करके, स्कोप के अस्वीकार होने की समस्या को मैनेज करना चाहिए. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी वाली अनुमतियों को मैनेज करने का तरीका लेख पढ़ें.
यह देखने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को किसी खास स्कोप का ऐक्सेस दिया है या नहीं,
ऐक्सेस टोकन के जवाब में scope
फ़ील्ड देखें. access_token से मिले ऐक्सेस के दायरे, स्पेस से अलग किए गए और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं.
उदाहरण के लिए, ऐक्सेस टोकन के जवाब का यह सैंपल दिखाता है कि उपयोगकर्ता ने आपके ऐप्लिकेशन को, अपने 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 |
से मिला क्लाइंट आईडी. |
client_secret |
से मिला क्लाइंट सीक्रेट.
(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 पर कस्टम यूआरआई स्कीम इस्तेमाल करने का विकल्प
Android के लिए Google Sign-In SDK टूल का इस्तेमाल करें. इससे, OAuth 2.0 का जवाब सीधे आपके ऐप्लिकेशन को मिलता है. साथ ही, रीडायरेक्ट यूआरआई की ज़रूरत भी नहीं पड़ती.
'Android के लिए Google साइन इन' SDK टूल पर माइग्रेट करने का तरीका
अगर Android पर OAuth इंटिग्रेशन के लिए कस्टम स्कीम का इस्तेमाल किया जाता है, तो आपको 'Android के लिए Google Sign-In' SDK टूल के सुझाए गए वर्शन का इस्तेमाल करने के लिए, ये कार्रवाइयां पूरी करनी होंगी:
- Google Sign-In SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
- Google API Console में, कस्टम स्कीम के लिए सहायता बंद करें.
Google Sign-In के Android SDK टूल पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
-
Google Sign-In Android SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें:
-
अपने कोड की जांच करके पता लगाएं कि आपने कहां 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
पैरामीटर की परिभाषा देखें. -
scope
औरclient_id
अनुरोध पैरामीटर को नोट करें. इनकी मदद से, आपको Google Sign-In SDK टूल को कॉन्फ़िगर करना होगा. -
SDK टूल सेट अप करने के लिए,
अपने Android ऐप्लिकेशन में Google Sign-In को इंटिग्रेट करना शुरू करें
निर्देशों का पालन करें. अपने बैकएंड सर्वर का OAuth 2.0 क्लाइंट आईडी पाएं चरण को छोड़ा जा सकता है. ऐसा इसलिए, क्योंकि पिछले चरण से मिले
client_id
का फिर से इस्तेमाल किया जाएगा. -
सर्वर साइड एपीआई ऐक्सेस को चालू करने के लिए दिए गए निर्देशों का पालन करें. इसमें ये चरण शामिल हैं:
-
जिन स्कोप के लिए अनुमति का अनुरोध किया जा रहा है उनके लिए ऑथराइज़ेशन कोड पाने के लिए,
getServerAuthCode
तरीके का इस्तेमाल करें. - ऑथराइज़ेशन कोड को ऐक्सेस और रीफ़्रेश टोकन के बदले पाने के लिए, अपने ऐप्लिकेशन के बैकएंड पर भेजें.
- उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस पाए गए ऐक्सेस टोकन का इस्तेमाल करें.
-
जिन स्कोप के लिए अनुमति का अनुरोध किया जा रहा है उनके लिए ऑथराइज़ेशन कोड पाने के लिए,
-
अपने कोड की जांच करके पता लगाएं कि आपने कहां Google के OAuth 2.0 सर्वर को अनुरोध भेजा है. अगर कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो आपका अनुरोध नीचे दिए गए तरीके से दिखेगा:
-
Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करना:
- अपनी OAuth 2.0 क्रेडेंशियल की सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं. इसके बाद, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स से सही का निशान हटाएं. साथ ही, कस्टम यूआरआई स्कीम की सुविधा बंद करने के लिए, सेव करें पर क्लिक करें.
कस्टम यूआरआई स्कीम चालू करना
अगर सुझाया गया विकल्प आपके लिए काम नहीं करता है, तो अपने Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू किए जा सकते हैं. इसके लिए, नीचे दिए गए निर्देशों का पालन करें:- अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं. इसके बाद, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स को चुनें और कस्टम यूआरआई स्कीम की सुविधा चालू करने के लिए, सेव करें पर क्लिक करें.
Chrome ऐप्लिकेशन पर कस्टम यूआरएल स्कीम इस्तेमाल करने का विकल्प
Chrome Identity API का इस्तेमाल करें. यह OAuth 2.0 का जवाब सीधे आपके ऐप्लिकेशन को भेजता है. इससे रीडायरेक्ट यूआरआई की ज़रूरत नहीं पड़ती.
लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)
इस यूआरएल का इस्तेमाल करके ऑथराइज़ेशन कोड पाने के लिए, आपका ऐप्लिकेशन स्थानीय वेब सर्वर पर सुन रहा होना चाहिए. ऐसा कई प्लैटफ़ॉर्म पर किया जा सकता है, लेकिन सभी पर नहीं. हालांकि, अगर आपके प्लैटफ़ॉर्म पर यह सुविधा काम करती है, तो ऑथराइज़ेशन कोड पाने के लिए, यह तरीका अपनाने का सुझाव दिया जाता है.
जब आपके ऐप्लिकेशन को अनुमति का जवाब मिलता है, तो बेहतर इस्तेमाल के लिए, उसे एचटीएमएल पेज दिखाकर जवाब देना चाहिए. इस पेज पर, उपयोगकर्ता को ब्राउज़र बंद करके आपके ऐप्लिकेशन पर वापस जाने का निर्देश दिया जाना चाहिए.
इस्तेमाल करने का सुझाव | macOS, Linux, और Windows डेस्कटॉप (यूनिवर्सल Windows Platform पर काम नहीं करने वाले) ऐप्लिकेशन |
फ़ॉर्म की वैल्यू | ऐप्लिकेशन टाइप को डेस्कटॉप ऐप्लिकेशन पर सेट करें. |
मैन्युअल तरीके से कॉपी/पेस्ट करना (अब काम नहीं करता)
अपने ऐप्लिकेशन को सुरक्षित रखना
ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (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 क्लाइंट के बदलाव वाले व्यू में, अपने क्लाइंट से मिले 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
सभी खातों की सुरक्षा की सुविधा को लागू करने के तरीके और उपलब्ध इवेंट की पूरी सूची के बारे में ज़्यादा जानने के लिए, सभी खातों की सुरक्षा की सुविधा की मदद से उपयोगकर्ता खातों को सुरक्षित रखें पेज पर जाएं .