इस दस्तावेज़ में बताया गया है कि फ़ोन, टैबलेट, और कंप्यूटर जैसे डिवाइस पर इंस्टॉल किए गए ऐप्लिकेशन, Google API का ऐक्सेस देने के लिए, Google के OAuth 2.0 एंडपॉइंट का इस्तेमाल कैसे करते हैं.
OAuth 2.0, उपयोगकर्ताओं को अपने उपयोगकर्ता नाम, पासवर्ड, और दूसरी जानकारी को निजी बनाए रखते हुए, किसी ऐप्लिकेशन के साथ चुनिंदा डेटा शेयर करने की सुविधा देता है. उदाहरण के लिए, कोई ऐप्लिकेशन, उपयोगकर्ताओं से Google Drive में फ़ाइलें सेव करने की अनुमति लेने के लिए, OAuth 2.0 का इस्तेमाल कर सकता है.
इंस्टॉल किए गए ऐप्लिकेशन, अलग-अलग डिवाइसों पर उपलब्ध कराए जाते हैं और यह माना जाता है कि ये ऐप्लिकेशन किसी भी डिवाइस को सीक्रेट नहीं रख सकते. वे Google API को तब ऐक्सेस कर सकते हैं, जब उपयोगकर्ता ऐप्लिकेशन में मौजूद हो या बैकग्राउंड में ऐप्लिकेशन चल रहा हो.
अनुमति देने का यह फ़्लो, वेब सर्वर ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले तरीके जैसा ही है. दोनों में मुख्य अंतर यह है कि इंस्टॉल किए गए ऐप्लिकेशन को सिस्टम ब्राउज़र खोलना होगा और Google के ऑथराइज़ेशन सर्वर से मिलने वाले रिस्पॉन्स को मैनेज करने के लिए, एक लोकल रीडायरेक्ट यूआरआई देना होगा.
विकल्प
मोबाइल ऐप्लिकेशन के लिए, Android या iOS के लिए 'Google साइन इन' का इस्तेमाल किया जा सकता है. 'Google साइन-इन' क्लाइंट लाइब्रेरी, पुष्टि करने और उपयोगकर्ता की अनुमति देने को मैनेज करती है. इन्हें लागू करना, यहां बताए गए निचले लेवल के प्रोटोकॉल की तुलना में ज़्यादा आसान हो सकता है.
ऐसे डिवाइस पर चल रहे ऐप्लिकेशन के लिए जिनमें सिस्टम ब्राउज़र काम नहीं करता या जिनमें सीमित इनपुट क्षमताएं होती हैं, जैसे कि टीवी, गेम कंसोल, कैमरा या प्रिंटर, टीवी और डिवाइस के लिए OAuth 2.0 या टीवी और सीमित इनपुट डिवाइसों पर साइन-इन देखें.
लाइब्रेरी और सैंपल
हम नीचे दी गई लाइब्रेरी और सैंपल का सुझाव देते हैं. इससे आपको इस दस्तावेज़ में बताए गए OAuth 2.0 फ़्लो को लागू करने में मदद मिलेगी:
- Android के लिए AppAuth लाइब्रेरी
- iOS के लिए AppAuth लाइब्रेरी
- ऐप्लिकेशन के लिए OAuth: Windows सैंपल
ज़रूरी शर्तें
अपने प्रोजेक्ट के लिए एपीआई चालू करें
Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को उन एपीआई को API Consoleमें चालू करना होगा.
अपने प्रोजेक्ट के लिए एपीआई चालू करने के लिए:
- Google API Consoleमें Open the API Library .
- If prompted, select a project, or create a new one.
- API Library में, प्रॉडक्ट फ़ैमिली और लोकप्रियता के हिसाब से, सभी उपलब्ध एपीआई की सूची होती है. आपको जिस एपीआई को चालू करना है, अगर वह सूची में नहीं दिख रहा है, तो उसे ढूंढने के लिए खोजें का इस्तेमाल करें. इसके अलावा, वह प्रॉडक्ट फ़ैमिली के सभी देखें पर क्लिक करें.
- वह एपीआई चुनें जिसे आपको चालू करना है, फिर चालू करें बटन पर क्लिक करें.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
अनुमति देने के लिए क्रेडेंशियल बनाएं
Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करने वाले किसी भी ऐप्लिकेशन में, अनुमति देने वाले क्रेडेंशियल होने चाहिए, जो Google के OAuth 2.0 सर्वर पर उस ऐप्लिकेशन की पहचान करते हों. अपने प्रोजेक्ट के लिए क्रेडेंशियल बनाने का तरीका नीचे बताया गया है. इसके बाद, आपके ऐप्लिकेशन उन एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल का इस्तेमाल कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए चालू किया है.
- Go to the Credentials page.
- क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी पर क्लिक करें.
- यहां दिए गए सेक्शन में ऐसे क्लाइंट टाइप और रीडायरेक्ट करने के तरीकों के बारे में बताया गया है जो Google के ऑथराइज़ेशन सर्वर पर काम करते हैं. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें और अपने OAuth क्लाइंट को नाम दें. साथ ही, फ़ॉर्म में दूसरे फ़ील्ड को सही तरीके से सेट करें.
Android
- Android ऐप्लिकेशन प्रकार चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पर दिखाया जाता है.
- अपने Android ऐप्लिकेशन के पैकेज का नाम डालें. यह मान आपकी ऐप्लिकेशन मेनिफ़ेस्ट फ़ाइल के
<manifest>
एलिमेंट कीpackage
एट्रिब्यूट में बताया गया है. - ऐप्लिकेशन डिस्ट्रिब्यूशन का SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट डालें.
- अगर आपके ऐप्लिकेशन में Google Play की ऐप्लिकेशन साइनिंग का इस्तेमाल किया जाता है, तो Play Console के ऐप्लिकेशन साइनिंग पेज से SHA-1 फ़िंगरप्रिंट कॉपी करें.
- अगर आपके पास अपना कीस्टोर और साइनिंग पासकोड खुद मैनेज करने का अधिकार है, तो सर्टिफ़िकेट की जानकारी को ऐसे फ़ॉर्मैट में प्रिंट करें जिसे लोग आसानी से पढ़ सकें. इसके लिए, Java के साथ मिलने वाली keytool सुविधा का इस्तेमाल करें. keytool आउटपुट
के
Certificate fingerprints
सेक्शन में,SHA1
की वैल्यू कॉपी करें. ज़्यादा जानकारी के लिए, Android के लिए Google API के दस्तावेज़ में अपने क्लाइंट की पुष्टि करना देखें.
- (ज़रूरी नहीं) अपने Android ऐप्लिकेशन के मालिकाना हक की पुष्टि करें.
- बनाएं पर क्लिक करें.
iOS
- iOS ऐप्लिकेशन का टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पर दिखाया जाता है.
- अपने ऐप्लिकेशन के लिए बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की जानकारी वाली प्रॉपर्टी की सूची की रिसॉर्स फ़ाइल (info.plist) में CFBundleIdentifier कुंजी की वैल्यू है. वैल्यू आम तौर पर, Xcode प्रोजेक्ट एडिटर के 'सामान्य' पैनल या 'हस्ताक्षर और क्षमताएं' पैनल में दिखाई जाती है. Apple की App Store Connect साइट पर मौजूद, ऐप्लिकेशन के लिए ऐप्लिकेशन की जानकारी वाले पेज पर मौजूद सामान्य जानकारी वाले सेक्शन में भी बंडल आईडी दिखाया जाता है.
- (ज़रूरी नहीं)
अगर ऐप्लिकेशन को Apple के App Store में पब्लिश किया गया है, तो अपने ऐप्लिकेशन का App Store आईडी डालें. स्टोर आईडी, अंकों वाली एक स्ट्रिंग होती है, जो Apple App Store के हर यूआरएल में शामिल होती है.
- अपने iOS या iPadOS डिवाइस पर Apple App Store ऐप्लिकेशन खोलें.
- अपना ऐप्लिकेशन खोजें.
- शेयर बटन (वर्ग और ऊपर तीर का निशान) चुनें.
- लिंक कॉपी करें चुनें.
- लिंक को टेक्स्ट एडिटर में चिपकाएं. App Store आईडी, यूआरएल का आखिरी हिस्सा होता है.
उदाहरण:
https://apps.apple.com/app/google/id284815942
- (ज़रूरी नहीं)
अपना टीम आईडी डालें. ज़्यादा जानकारी के लिए, Apple डेवलपर खाते के दस्तावेज़ में अपने टीम आईडी का पता लगाएं देखें.
- बनाएं पर क्लिक करें.
यूडब्ल्यूपी
- Universal Windows Platform ऐप्लिकेशन का टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पर दिखाया जाता है.
- अपने ऐप्लिकेशन का 12 वर्णों का Microsoft Store आईडी डालें. आपको यह वैल्यू Microsoft Partner Center में मिलेगी. इसके लिए, ऐप्लिकेशन मैनेजमेंट सेक्शन में, ऐप्लिकेशन आइडेंटिटी पेज पर जाएं.
- बनाएं पर क्लिक करें.
यूडब्ल्यूपी ऐप्लिकेशन के लिए, पसंद के मुताबिक यूआरआई स्कीम 39 वर्णों से ज़्यादा की नहीं हो सकती.
कस्टम यूआरआई स्कीम (Android, iOS, UWP)
कस्टम यूआरआई स्कीम डीपलिंक करने का एक तरीका है. इसमें आपके ऐप्लिकेशन को खोलने के लिए, पसंद के मुताबिक तय की गई स्कीम का इस्तेमाल किया जाता है.
Android पर कस्टम यूआरआई स्कीम का इस्तेमाल करने का विकल्पAndroid SDK के लिए 'Google साइन-इन' का इस्तेमाल करें. यह OAuth 2.0 रिस्पॉन्स, सीधे आपके ऐप्लिकेशन पर डिलीवर करता है. इससे, रीडायरेक्ट यूआरआई की ज़रूरत खत्म हो जाती है.
'Android SDK टूल के लिए 'Google साइन-इन' पर माइग्रेट करने का तरीका
अगर Android पर अपने OAuth इंटिग्रेशन के लिए कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो Android SDK के लिए सुझाए गए 'Google साइन-इन' के इस्तेमाल पर पूरी तरह से माइग्रेट करने के लिए, आपको नीचे दी गई कार्रवाइयां पूरी करनी होंगी:
- 'Google साइन-इन' SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
- Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करें.
'Google साइन-इन' Android SDK पर माइग्रेट करने के लिए, यहां दिया गया तरीका अपनाएं:
-
'Google साइन-इन' 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 साइन-इन' SDK टूल को कॉन्फ़िगर करने के लिए किन पैरामीटर की ज़रूरत होगी. -
SDK टूल सेट अप करने के लिए,
अपने Android ऐप्लिकेशन में 'Google साइन-इन' इंटिग्रेट करना शुरू करें
से जुड़े निर्देशों का पालन करें. आपके पास
बैकएंड सर्वर का OAuth 2.0 क्लाइंट आईडी पाएं चरण को छोड़ने का विकल्प होता है. यह चरण, पिछले चरण से मिले
client_id
को फिर से इस्तेमाल करने पर किया जाता है. -
सर्वर-साइड एपीआई का ऐक्सेस चालू करने
से जुड़े निर्देशों का पालन करें. इसमें यह तरीका भी शामिल है:
-
आपने जिन दायरों के लिए अनुमति का अनुरोध किया है उनके लिए, पुष्टि करने वाला कोड वापस पाने के लिए,
getServerAuthCode
तरीके का इस्तेमाल करें. - ऐप्लिकेशन के बैकएंड पर पुष्टि करने वाला कोड भेजें, ताकि उसके बदले ऐक्सेस और रीफ़्रेश टोकन मिल सके.
- उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस लाए गए ऐक्सेस टोकन का इस्तेमाल करें.
-
आपने जिन दायरों के लिए अनुमति का अनुरोध किया है उनके लिए, पुष्टि करने वाला कोड वापस पाने के लिए,
-
अपने कोड की जांच करके यह पता लगाएं कि
Google के OAuth 2.0 सर्वर को अनुरोध कहां भेजा जा रहा है. कस्टम स्कीम का इस्तेमाल करने पर, आपका अनुरोध नीचे कुछ ऐसा दिखेगा:
-
Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करें:
- अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं और कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स से सही का निशान हटाएं. इसके बाद, कस्टम यूआरआई स्कीम की सुविधा बंद करने के लिए, सेव करें पर क्लिक करें.
पसंद के मुताबिक यूआरआई स्कीम चालू करना
अगर सुझाया गया विकल्प आपके लिए काम नहीं करता है, तो नीचे दिए गए निर्देशों का पालन करके अपने Android क्लाइंट के लिए, पसंद के मुताबिक यूआरआई स्कीम चालू की जा सकती हैं:- अपने OAuth 2.0 क्रेडेंशियल की सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स चुनें. इसके बाद, कस्टम यूआरआई स्कीम सहायता को चालू करने के लिए, सेव करें पर क्लिक करें.
Chrome Identity API का इस्तेमाल करें, जो सीधे आपके ऐप्लिकेशन पर OAuth 2.0 रिस्पॉन्स भेजता है. इससे रीडायरेक्ट यूआरआई की ज़रूरत खत्म होती है.
ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (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 डेवलपर डैशबोर्ड में, रजिस्टर किया गया एक आइटम होना चाहिए. साथ ही, उस आईडी का आइटम आईडी होना चाहिए जिसकी पहचान Chrome एक्सटेंशन OAuth क्लाइंट के लिए की जा रही है.
- Chrome Web Store आइटम के लिए, आपको पब्लिशर होना ज़रूरी है. Chrome Web Store Developer Dashboard में, ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.
पुष्टि की प्रक्रिया पूरी करने के लिए, Chrome एक्सटेंशन क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, मालिकाना हक की पुष्टि करें बटन पर क्लिक करें.
ध्यान दें: अपने खाते का ऐक्सेस देने के बाद, कृपया पुष्टि की प्रक्रिया पूरी करने से पहले कुछ मिनट इंतज़ार करें.
अगर पुष्टि हो जाती है, तो आपको इसकी पुष्टि करने के लिए सूचना दिखेगी. ऐसा न करने पर, गड़बड़ी का मैसेज दिखेगा.
पुष्टि न हो पाने की समस्या को ठीक करने के लिए, कृपया नीचे दिए गए तरीके आज़माएं:
- पक्का करें कि 'Chrome वेब स्टोर डेवलपर डैशबोर्ड' में, रजिस्टर किया गया एक आइटम हो. साथ ही, उसका आइटम आईडी Chrome एक्सटेंशन OAuth क्लाइंट के तौर पर ही होना चाहिए, जिसके लिए पुष्टि की प्रक्रिया पूरी की जा रही है.
- पक्का करें कि आप ऐप्लिकेशन के पब्लिशर हैं. इसका मतलब है कि आप उस ऐप्लिकेशन के पब्लिशर या ग्रुप पब्लिशर हैं. 'Chrome वेब स्टोर डेवलपर डैशबोर्ड' में, ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.
- अगर आपने अभी-अभी अपने ग्रुप पब्लिशर की सूची अपडेट की है, तो पुष्टि करें कि 'Chrome वेब स्टोर' डेवलपर डैशबोर्ड में ग्रुप पब्लिशर की सदस्यता की सूची सिंक हो गई है. पब्लिशर की सदस्यता की सूची को सिंक करने के बारे में ज़्यादा जानें.
लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)
इस यूआरएल का इस्तेमाल करके ऑथराइज़ेशन कोड पाने के लिए, यह ज़रूरी है कि आपका ऐप्लिकेशन लोकल वेब सर्वर पर चल रहा हो. ऐसा कई प्लैटफ़ॉर्म पर मुमकिन है, लेकिन सभी प्लैटफ़ॉर्म पर नहीं. हालांकि, अगर आपका प्लैटफ़ॉर्म इस सुविधा के साथ काम करता है, तो हमारा सुझाव है कि आप ऑथराइज़ेशन कोड पाने का यह तरीका अपनाएं.
जब आपके ऐप्लिकेशन को अनुमति मिल जाती है, तो उसे अच्छी तरह से इस्तेमाल करने के लिए, एचटीएमएल पेज पर एक एचटीएमएल पेज दिखाना चाहिए. इस पेज पर, ब्राउज़र को बंद करके आपके ऐप्लिकेशन पर वापस जाने का निर्देश दिया जाता है.
इस्तेमाल करने के सुझाव | macOS, Linux, और Windows डेस्कटॉप (लेकिन Universal Windows Platform नहीं) ऐप्लिकेशन |
फ़ॉर्म वैल्यू | ऐप्लिकेशन टाइप को डेस्कटॉप ऐप्लिकेशन पर सेट करें. |
मैन्युअल तरीके से कॉपी करें/चिपकाएं
ऐक्सेस के दायरे की पहचान करें
दायरों की मदद से आपका ऐप्लिकेशन, सिर्फ़ उन संसाधनों के ऐक्सेस का अनुरोध कर सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ताओं को यह कंट्रोल करने की सुविधा भी मिलती है कि वे आपके ऐप्लिकेशन को कितने संसाधन दें. इसलिए, अनुरोध किए गए दायरों की संख्या और उपयोगकर्ता की सहमति लेने की संभावना के बीच अंतर हो सकता है.
हमारा सुझाव है कि OAuth 2.0 की अनुमति का इस्तेमाल शुरू करने से पहले, आप उन दायरों की पहचान कर लें जिन्हें ऐक्सेस करने के लिए आपके ऐप्लिकेशन को अनुमति की ज़रूरत होगी.
OAuth 2.0 एपीआई का दायरा दस्तावेज़ में, उन दायरों की पूरी सूची दी गई है जिनका इस्तेमाल, Google API को ऐक्सेस करने के लिए किया जा सकता है.
OAuth 2.0 ऐक्सेस टोकन पाना
नीचे दिए गए चरण दिखाते हैं कि आपका ऐप्लिकेशन, Google के OAuth 2.0 सर्वर के साथ कैसे इंटरैक्ट करता है, ताकि उपयोगकर्ता की ओर से एपीआई का अनुरोध करने के लिए, उपयोगकर्ता की सहमति ली जा सके. आपके ऐप्लिकेशन के पास वह सहमति होनी चाहिए, ताकि वह Google API अनुरोध पर काम शुरू कर सके जिसके लिए उपयोगकर्ता की अनुमति ज़रूरी है.
पहला चरण: कोड की पुष्टि करने वाला और चैलेंज जनरेट करना
Google, Code Exchange के लिए प्रूफ़ की (PKCE) प्रोटोकॉल के साथ काम करता है, ताकि इंस्टॉल किए गए ऐप्लिकेशन के फ़्लो को ज़्यादा सुरक्षित बनाया जा सके. अनुमति के हर अनुरोध के लिए, एक यूनीक कोड की पुष्टि करने वाला टूल बनाया जाता है. ऑथराइज़ेशन कोड पाने के लिए, इसकी बदली गई वैल्यू जिसे "code_Challenge" कहा जाता है, ऑथराइज़ेशन सर्वर को भेजा जाता है.
कोड की पुष्टि करने वाली सुविधा बनाना
code_verifier
एक हाई-एंट्रॉपी क्रिप्टोग्राफ़िक रैंडम स्ट्रिंग है, जिसमें रिज़र्व
नहीं किए गए वर्णों [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" का इस्तेमाल किया जाता है. इसमें
कम से कम 43 वर्ण और ज़्यादा से ज़्यादा 128 वर्ण होते हैं.
कोड की पुष्टि करने वाले में इतनी एंट्रॉपी होनी चाहिए कि वैल्यू का अनुमान लगाना संभव न हो.
कोड चैलेंज बनाना
कोड चैलेंज बनाने के दो तरीके काम करते हैं.
कोड चैलेंज जनरेट करने के तरीके | |
---|---|
S256 (सुझाया गया) | यह कोड चैलेंज, कोड की पुष्टि करने वाले के SHA256 हैश को Base64URL (बिना पैडिंग) के कोड में बदला गया है.
|
सादा | कोड चैलेंज की वैल्यू, ऊपर जनरेट किए गए कोड की पुष्टि करने वाली सुविधा से मेल खाती है.
|
दूसरा चरण: Google के OAuth 2.0 सर्वर को अनुरोध भेजना
उपयोगकर्ता की अनुमति पाने के लिए, https://accounts.google.com/o/oauth2/v2/auth
पर Google के ऑथराइज़ेशन सर्वर को अनुरोध भेजें. यह एंडपॉइंट, ऐक्टिव सेशन लुकअप को मैनेज करता है,
उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. एंडपॉइंट को सिर्फ़ एसएसएल पर ऐक्सेस किया जा सकता है और यह एचटीटीपी (नॉन-एसएसएल) कनेक्शन को अस्वीकार कर देता है.
अनुमति देने वाला सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए नीचे दिए गए क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:
पैरामीटर | |||||||
---|---|---|---|---|---|---|---|
client_id |
ज़रूरी
आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू API Console Credentials pageमें देखी जा सकती है. |
||||||
redirect_uri |
ज़रूरी
यह तय करता है कि Google का ऑथराइज़ेशन सर्वर आपके ऐप्लिकेशन को कैसे जवाब भेजता है. इंस्टॉल किए गए ऐप्लिकेशन के लिए रीडायरेक्ट करने के कई विकल्प उपलब्ध हैं. साथ ही, आपको रीडायरेक्ट करने के किसी खास तरीके को ध्यान में रखते हुए, अनुमति देने के क्रेडेंशियल सेट अप करने होंगे. वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले किसी ऐसे रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए जिसे आपने क्लाइंट के
API Console
Credentials pageमें कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले
यूआरआई से मेल नहीं खाती है, तो आपको यहां दी गई टेबल में, हर तरीके के लिए
|
||||||
response_type |
ज़रूरी
इससे यह तय होता है कि Google OAuth 2.0 एंडपॉइंट, ऑथराइज़ेशन कोड दिखाता है या नहीं. इंस्टॉल किए गए ऐप्लिकेशन के लिए, पैरामीटर वैल्यू को |
||||||
scope |
ज़रूरी
दायरों की स्पेस-डीलिमिटेड सूची, जिसमें उन संसाधनों की पहचान की जाती है जिन्हें आपका ऐप्लिकेशन, उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. ये वैल्यू, सहमति वाली उस स्क्रीन के बारे में बताती हैं जिसे Google, उपयोगकर्ता को दिखाता है. दायरों की मदद से आपका ऐप्लिकेशन, सिर्फ़ उन संसाधनों के ऐक्सेस का अनुरोध कर सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ताओं को यह कंट्रोल करने की सुविधा भी मिलती है कि वे आपके ऐप्लिकेशन को कितने ऐक्सेस दें. इसलिए, अनुरोध किए गए दायरों की संख्या और उपयोगकर्ता की सहमति लेने की संभावना के बीच फ़र्क़ होता है. |
||||||
code_challenge |
सुझाया गया
कोड में बदले गए |
||||||
code_challenge_method |
सुझाया गया
इससे पता चलता है कि |
||||||
state |
सुझाया गया
इस कॉलम से ऐसी स्ट्रिंग की जानकारी मिलती है जिसका इस्तेमाल आपका ऐप्लिकेशन, अनुमति देने के आपके अनुरोध और अनुमति देने वाले सर्वर के रिस्पॉन्स के बीच स्थिति बनाए रखने के लिए करता है.
सर्वर ठीक वही वैल्यू दिखाता है जिसे आप
इस पैरामीटर का इस्तेमाल कई कामों के लिए किया जा सकता है. जैसे, उपयोगकर्ता को
अपने ऐप्लिकेशन में सही रिसॉर्स पर ले जाना, नॉन्स भेजना, और क्रॉस-साइट से जुड़ी जालसाज़ी के अनुरोध को कम करना. आपके |
||||||
login_hint |
ज़रूरी नहीं
अगर आपके ऐप्लिकेशन को पता है कि कौनसा उपयोगकर्ता पुष्टि करने की कोशिश कर रहा है, तो वह इस पैरामीटर का इस्तेमाल करके, Google ऑथेंटिकेशन सर्वर को संकेत दे सकता है. सर्वर इस संकेत का इस्तेमाल करके, लॉगिन फ़्लो को आसान बनाता है. इसके लिए, साइन-इन फ़ॉर्म में ईमेल फ़ील्ड में पहले से जानकारी भरी जाती है या एक से ज़्यादा बार लॉगिन किए जाने वाले सही सेशन को चुना जाता है. पैरामीटर वैल्यू को किसी ईमेल पते या |
अनुमति देने वाले यूआरएल के सैंपल
नीचे दिए गए टैब अलग-अलग रीडायरेक्ट यूआरआई विकल्पों के लिए, अनुमति वाले यूआरएल के नमूने दिखाते हैं.
redirect_uri
पैरामीटर की वैल्यू के अलावा, सभी यूआरएल एक जैसे हैं. यूआरएल में
ज़रूरी response_type
और client_id
पैरामीटर के साथ-साथ
वैकल्पिक state
पैरामीटर भी शामिल होता है. हर यूआरएल में लाइन ब्रेक और स्पेस होते हैं, ताकि उन्हें आसानी से पढ़ा जा सके.
कस्टम यूआरआई स्कीम
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
लूपबैक आईपी पता
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
तीसरा चरण: Google, उपयोगकर्ता से सहमति के लिए अनुरोध करता है
इस चरण में, उपयोगकर्ता तय करता है कि आपके ऐप्लिकेशन को अनुरोध किया गया ऐक्सेस देना है या नहीं. इस चरण में, Google एक सहमति विंडो दिखाता है. इसमें आपके ऐप्लिकेशन का नाम और उन Google API सेवाओं का नाम दिखता है जिन्हें ऐक्सेस करने के लिए, वह उपयोगकर्ता के ऑथराइज़ेशन क्रेडेंशियल और दिए जाने वाले ऐक्सेस के दायरों की खास जानकारी देता है. इसके बाद उपयोगकर्ता, आपके ऐप्लिकेशन के अनुरोध किए गए एक या उससे ज़्यादा दायरों का ऐक्सेस देने की सहमति दे सकता है या अनुरोध को अस्वीकार कर सकता है.
इस चरण में आपके ऐप्लिकेशन को कुछ करने की ज़रूरत नहीं है, क्योंकि वह Google के OAuth 2.0 सर्वर से रिस्पॉन्स मिलने का इंतज़ार करता है, जिससे यह पता चलता है कि कोई ऐक्सेस दिया गया है या नहीं. इस जवाब के बारे में अगले चरण में बताया गया है.
गड़बड़ियां
Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट के अनुरोध पर, पुष्टि करने और ऑथराइज़ेशन फ़्लो की उम्मीद के बजाय, उपयोगकर्ता को मिलने वाले गड़बड़ी के मैसेज दिख सकते हैं. आम गड़बड़ी कोड और सुझाए गए समाधान नीचे दिए गए हैं.
admin_policy_enforced
Google खाते के Google Workspace एडमिन की नीतियों की वजह से, अनुरोध किए गए एक या उससे ज़्यादा दायरों को अनुमति नहीं दी जा सकती. Google Workspace एडमिन के लिए सहायता लेख पढ़ें यह कंट्रोल करें कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले कौनसे ऐप्लिकेशन, Google Workspace का डेटा ऐक्सेस करते हैं इस बारे में ज़्यादा जानकारी पाएं कि एडमिन, आपके OAuth क्लाइंट आईडी का ऐक्सेस साफ़ तौर पर मिलने तक, सभी स्कोप या संवेदनशील और पाबंदी वाले दायरों के ऐक्सेस पर पाबंदी कैसे लगा सकता है.
disallowed_useragent
ऑथराइज़ेशन एंडपॉइंट, एम्बेड किए गए ऐसे उपयोगकर्ता-एजेंट के अंदर दिखाया जाता है जिसे Google की OAuth 2.0 नीतियों के मुताबिक अनुमति नहीं है.
Android
android.webkit.WebView
में अनुमति के अनुरोध खोलते समय, Android डेवलपर को गड़बड़ी का यह मैसेज दिख सकता है.
इसके बजाय, डेवलपर को Android लाइब्रेरी का इस्तेमाल करना चाहिए. जैसे,
Android के लिए 'Google साइन-इन' या UPI फ़ाउंडेशन का
Android के लिए AppAuth.
जब कोई Android ऐप्लिकेशन, एम्बेड किए गए उपयोगकर्ता-एजेंट में कोई सामान्य वेब लिंक खोलता है और कोई उपयोगकर्ता आपकी साइट से Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर जाता है, तो वेब डेवलपर को यह गड़बड़ी दिख सकती है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में सामान्य लिंक खोलने की अनुमति देनी चाहिए. इनमें Android ऐप्लिकेशन के लिंक हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल हैं. Android की कस्टम टैब लाइब्रेरी का इस्तेमाल भी किया जा सकता है.
iOS
iOS और macOS डेवलपर को
WKWebView
में अनुमति के अनुरोध खोलते समय यह गड़बड़ी दिख सकती है.
इसके बजाय, डेवलपर को iOS लाइब्रेरी का इस्तेमाल करना चाहिए, जैसे कि
iOS के लिए 'Google साइन-इन' या UPI फ़ाउंडेशन के
iOS के लिए AppAuth.
जब कोई iOS या macOS ऐप्लिकेशन, एम्बेड किए गए किसी उपयोगकर्ता-एजेंट में कोई सामान्य वेब लिंक खोलता है और कोई उपयोगकर्ता आपकी साइट से, Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर
नेविगेट करता है, तो वेब डेवलपर को यह गड़बड़ी दिख सकती है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में सामान्य लिंक
खोलने की अनुमति देनी चाहिए. इसमें,
Universal लिंक
हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल हैं.
SFSafariViewController
लाइब्रेरी भी इस्तेमाल की जा सकती है.
org_internal
अनुरोध में मौजूद OAuth क्लाइंट आईडी, एक ऐसे प्रोजेक्ट का हिस्सा है जिससे किसी Google Cloud संगठन में मौजूद Google खातों का ऐक्सेस सीमित किया जाता है. इस कॉन्फ़िगरेशन के विकल्प के बारे में ज़्यादा जानकारी के लिए, OAuth के लिए सहमति देने वाली स्क्रीन को सेट अप करना सहायता लेख में, उपयोगकर्ता का टाइप सेक्शन देखें.
invalid_grant
अगर कोड की पुष्टि करने और चैलेंज का इस्तेमाल किया जा रहा है, तो code_callenge
पैरामीटर अमान्य है या मौजूद नहीं है. पक्का करें कि
code_challenge
पैरामीटर सही तरीके से सेट किया गया हो.
ऐक्सेस टोकन को रीफ़्रेश करते समय, हो सकता है कि टोकन की समयसीमा खत्म हो गई हो या अमान्य हो गया हो. उपयोगकर्ता की फिर से पुष्टि करें और नए टोकन पाने के लिए उपयोगकर्ता की सहमति मांगें. अगर आपको यह गड़बड़ी लगातार दिख रही है, तो पक्का करें कि आपका ऐप्लिकेशन सही तरीके से कॉन्फ़िगर किया गया हो. साथ ही, यह भी पक्का करें कि अनुरोध में सही टोकन और पैरामीटर का इस्तेमाल किया जा रहा हो. ऐसा न करने पर, हो सकता है कि उपयोगकर्ता खाता मिटा दिया गया हो या बंद कर दिया गया हो.
redirect_uri_mismatch
अनुमति देने के अनुरोध में पास किया गया redirect_uri
, OAuth क्लाइंट आईडी के आधिकारिक रीडायरेक्ट यूआरआई से मेल नहीं खाता. Google API Console Credentials pageमें अनुमति वाले रीडायरेक्ट यूआरआई की समीक्षा करें.
पास किया गया redirect_uri
, क्लाइंट टाइप के लिए अमान्य हो सकता है.
redirect_uri
पैरामीटर, OAuth आउट-ऑफ़-बैंड (OOB) फ़्लो के बारे में बता सकता है. यह फ़्लो अब काम नहीं करता. अपना इंटिग्रेशन अपडेट करने के लिए,
डेटा को दूसरी जगह भेजने से जुड़ी गाइड
देखें.
invalid_request
आपने जो अनुरोध किया था उसमें कोई गड़बड़ी है. ऐसा कई वजहों से हो सकता है:
- अनुरोध सही तरीके से फ़ॉर्मैट नहीं किया गया था
- अनुरोध में ज़रूरी पैरामीटर मौजूद नहीं हैं
- अनुरोध के लिए, अनुमति देने के किसी ऐसे तरीके का इस्तेमाल किया गया है जो Google पर काम नहीं करता. पुष्टि करें कि आपका OAuth इंटिग्रेशन, इंटिग्रेशन के लिए सुझाए गए तरीके का इस्तेमाल करता है
- रीडायरेक्ट यूआरआई के लिए कस्टम स्कीम का इस्तेमाल किया जाता है : अगर आपको गड़बड़ी का यह मैसेज दिखता है, Chrome ऐप्लिकेशन पर कस्टम यूआरआई स्कीम काम नहीं करती है या आपके Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू नहीं है, तो इसका मतलब है कि आप कस्टम यूआरआई स्कीम का इस्तेमाल कर रहे हैं जो Chrome ऐप्लिकेशन पर काम नहीं करती और डिफ़ॉल्ट रूप से Android पर बंद होती है. कस्टम यूआरआई स्कीम के विकल्पों के बारे में ज़्यादा जानें
चौथा चरण: OAuth 2.0 सर्वर से मिलने वाले रिस्पॉन्स को मैनेज करना
आपके ऐप्लिकेशन को अनुमति का रिस्पॉन्स मिलने का तरीका,
रीडायरेक्ट यूआरआई स्कीम पर निर्भर करता है. चाहे कोई भी स्कीम हो, रिस्पॉन्स में ऑथराइज़ेशन कोड (code
) या गड़बड़ी (error
) शामिल होगा. उदाहरण के लिए, error=access_denied
से पता चलता है कि उपयोगकर्ता ने
अनुरोध अस्वीकार कर दिया है.
अगर उपयोगकर्ता आपके ऐप्लिकेशन का ऐक्सेस देता है, तो आपके पास ऑथराइज़ेशन कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन देने की सुविधा होती है. इसकी जानकारी अगले चरण में दी गई है.
पांचवां चरण: रीफ़्रेश और ऐक्सेस टोकन के लिए एक्सचेंज ऑथराइज़ेशन कोड
किसी ऐक्सेस टोकन को ऑथराइज़ेशन कोड से बदलने के लिए, https://oauth2.googleapis.com/token
एंडपॉइंट पर कॉल करें और ये पैरामीटर सेट करें:
फ़ील्ड | |
---|---|
client_id |
API Console Credentials pageसे मिला क्लाइंट आईडी. |
client_secret |
API Console Credentials pageसे मिला क्लाइंट सीक्रेट. |
code |
शुरुआती अनुरोध करने पर, ऑथराइज़ेशन कोड मिला है. |
code_verifier |
पहले चरण में बनाया गया कोड की पुष्टि करने वाला टूल. |
grant_type |
जैसा कि OAuth 2.0 के स्पेसिफ़िकेशन में बताया गया है, इस फ़ील्ड की वैल्यू authorization_code पर सेट होनी चाहिए. |
redirect_uri |
दिए गए client_id के लिए,
API Console
Credentials page में आपके प्रोजेक्ट के लिए लिस्ट किए गए
रीडायरेक्ट यूआरआई में से एक. |
यह स्निपेट एक सैंपल अनुरोध दिखाता है:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& client_secret=your_client_secret& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
Google इस अनुरोध का जवाब देने के लिए, एक JSON ऑब्जेक्ट दिखाता है. इस ऑब्जेक्ट में, कम समय तक काम करने वाला ऐक्सेस टोकन और रीफ़्रेश टोकन होता है.
जवाब में ये फ़ील्ड शामिल होते हैं:
फ़ील्ड | |
---|---|
access_token |
वह टोकन जिसे आपका ऐप्लिकेशन, Google API अनुरोध की अनुमति देने के लिए भेजता है. |
expires_in |
ऐक्सेस टोकन की बची हुई अवधि (सेकंड में). |
id_token |
ध्यान दें: यह प्रॉपर्टी सिर्फ़ तब दिखेगी, जब आपके अनुरोध में openid , profile या email जैसा कोई आइडेंटिटी स्कोप शामिल हो. यह वैल्यू एक
JSON Web Token (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/drive.metadata.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Google API को कॉल करना
जब आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाता है, तब किसी उपयोगकर्ता खाते की ओर से Google API को कॉल करने के लिए टोकन का इस्तेमाल किया जा सकता है. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब एपीआई के लिए ज़रूरी ऐक्सेस के दायरे दिए गए हों. इसके लिए,
एपीआई के अनुरोध में ऐक्सेस टोकन शामिल करें. इसके लिए,
access_token
क्वेरी पैरामीटर या Authorization
एचटीटीपी हेडर Bearer
की वैल्यू शामिल करें. जब भी हो सके, एचटीटीपी हेडर को प्राथमिकता दी जाती है, क्योंकि क्वेरी स्ट्रिंग सर्वर लॉग में दिखती हैं. ज़्यादातर मामलों में,
Google API के लिए अपने कॉल सेट अप करने के लिए, क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. उदाहरण के लिए,
Drive Files API को कॉल करते समय.
OAuth 2.0 Playground पर, सभी Google API को आज़माया जा सकता है और उनके दायरे देखे जा सकते हैं.
एचटीटीपी जीईटी के उदाहरण
Authorization: Bearer
एचटीटीपी हेडर का इस्तेमाल करके
drive.files
एंडपॉइंट (Drive Files API) को किया जाने वाला कॉल कुछ ऐसा दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन खुद तय करना होगा:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
यहां access_token
क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, पुष्टि किए गए उपयोगकर्ता के लिए उसी एपीआई को कॉल किया गया है:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl
के उदाहरण
curl
कमांड लाइन ऐप्लिकेशन की मदद से, इन कमांड की जांच की जा सकती है. यहां एचटीटीपी हेडर विकल्प का इस्तेमाल करने वाला एक उदाहरण दिया गया है (प्राथमिकता दी जानी चाहिए):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर विकल्प का इस्तेमाल भी किया जा सकता है:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
ऐक्सेस टोकन को रीफ़्रेश करना
ऐक्सेस टोकन की समयसीमा खत्म हो जाती है. इस वजह से, ये किसी मिलते-जुलते एपीआई अनुरोध के लिए अमान्य क्रेडेंशियल बन जाते हैं. अगर आपने टोकन से जुड़े दायरों के ऑफ़लाइन ऐक्सेस का अनुरोध किया है, तो उपयोगकर्ता को अनुमति के लिए अनुरोध किए बिना, ऐक्सेस टोकन को रीफ़्रेश किया जा सकता है. ऐसा तब भी किया जा सकता है, जब उपयोगकर्ता मौजूद न हो.
ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन Google के ऑथराइज़ेशन सर्वर (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
, गड़बड़ी कोड के साथ
दिखाया जाता है.
इसके बारे में और पढ़ें
आईईटीएफ़ का सबसे सही तरीका नेटिव ऐप्लिकेशन के लिए OAuth 2.0 के बारे में, यहां बताए गए सबसे सही तरीके बताए गए हैं.