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

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

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

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

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

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

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

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

ऐसे डिवाइसों पर चलने वाले ऐप्लिकेशन के लिए जो सिस्टम ब्राउज़र के साथ काम नहीं करते या जिनमें सीमित इनपुट क्षमताएं होती हैं, जैसे कि टीवी, गेम कंसोल, कैमरे या प्रिंटर, टीवी और डिवाइसों के लिए 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 Clients page.
क्लाइंट खाता बनाएं पर क्लिक करें.
यहां दिए गए सेक्शन में, क्लाइंट के उन टाइप के बारे में बताया गया है जिनके साथ Google का अनुमति सर्वर काम करता है. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें. इसके बाद, अपने OAuth क्लाइंट का नाम डालें और फ़ॉर्म में दिए गए अन्य फ़ील्ड को ज़रूरत के मुताबिक सेट करें.

iOS

iOS ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए कोई नाम डालें. यह नाम आपके प्रोजेक्ट के Clients page पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
अपने ऐप्लिकेशन के लिए बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की सूचना प्रॉपर्टी लिस्ट रिसॉर्स फ़ाइल (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 क्लाइंट के लिए कोई नाम डालें. यह नाम आपके प्रोजेक्ट के Clients page पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
अपने ऐप्लिकेशन का 12 वर्णों वाला Microsoft Store आईडी डालें. यह वैल्यू, Microsoft Partner Center में ऐप्लिकेशन मैनेजमेंट सेक्शन के ऐप्लिकेशन की पहचान पेज पर देखी जा सकती है.
बनाएं पर क्लिक करें.

UWP ऐप्लिकेशन के लिए, रीडायरेक्ट यूआरआई आपके ऐप्लिकेशन के यूनीक पैकेज सिक्योरिटी आइडेंटिफ़ायर (एसआईडी) का इस्तेमाल करके बनाया जाता है. आपको अपने ऐप्लिकेशन का Package SID, Visual Studio प्रोजेक्ट में मौजूद Package.appxmanifest फ़ाइल में मिल सकता है.

Google Cloud Console में क्लाइंट आईडी बनाते समय, आपको रीडायरेक्ट यूआरआई को इस फ़ॉर्मैट में डालना होगा. इसके लिए, आपको अपने पैकेज के एसआईडी की छोटी वैल्यू का इस्तेमाल करना होगा:

ms-app://YOUR_APP_PACKAGE_SID

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

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

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

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

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

ज़रूरी है

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

redirect_uri

ज़रूरी है

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

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

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

redirect_uri की वैल्यू

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

com.example.app:redirect_uri_path

या

com.googleusercontent.apps.123:redirect_uri_path

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

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

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

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

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

response_type

ज़रूरी है

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

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

scope

ज़रूरी है

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

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 चैनल की निजी जानकारी देखें

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 क्लाइंट को सीएसआरएफ़ को रोकना होगा. इसके बारे में 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 नीतियों के तहत अनुमति नहीं है.

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 क्लाइंट आईडी के लिए अनुमति वाले रीडायरेक्ट यूआरआई से मेल नहीं खाता. Google Cloud Console Clients pageमें जाकर, अनुमति वाले रीडायरेक्ट यूआरआई देखें.

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

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

`invalid_request`

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

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

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

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

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

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

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

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

यहां अनुरोध का एक सैंपल दिया गया है:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://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 भी दिखाया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

Chrome के लिए ऐप्लिकेशन के मालिकाना हक की पुष्टि करना

ऐप्लिकेशन के मालिकाना हक की पुष्टि करके, ऐप्लिकेशन के गलत इस्तेमाल के जोखिम को कम किया जा सकता है.

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

आपके पास 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 सुविधा, आपके iOS ऐप्लिकेशन को बिना अनुमति के इस्तेमाल से सुरक्षित रखने में मदद करती है. इसके लिए, Apple की App Attest service का इस्तेमाल किया जाता है. इससे यह पुष्टि की जाती है कि 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 ऐप्लिकेशन के लिए ऐप्लिकेशन की जांच करने की सुविधा चालू करते समय, आपको इस सुविधा से जुड़ी गड़बड़ियां दिख सकती हैं. इन गड़बड़ियों को ठीक करने के लिए, यह तरीका आज़माएं:

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

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

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

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

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

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

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

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

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

iOS

UWP

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

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

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

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

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

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

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

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

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

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

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

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

Google API को कॉल करना

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

curl के उदाहरण

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

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

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

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

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

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

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

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

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` के उदाहरण