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

डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

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

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

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

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

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

डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0 लागू करते समय, हमारा सुझाव है कि आप अपनी प्रोग्रामिंग भाषा (जैसे, Python, Java, Node.js, Go, .NET) के लिए, Google API क्लाइंट लाइब्रेरी का इस्तेमाल करें. क्लाइंट लाइब्रेरी, उपयोगकर्ता की अनुमति और टोकन मैनेजमेंट को हैंडल करती हैं. इससे, सीधे तौर पर लोअर-लेवल एचटीटीपी/आरईएसटी एंडपॉइंट का इस्तेमाल करने के मुकाबले, लागू करना आसान हो जाता है और गड़बड़ी होने की संभावना कम हो जाती है.

मोबाइल ऐप्लिकेशन के लिए, Android और iOS की अनुमति से जुड़ी गाइड देखें.

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

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

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

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

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

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

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

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

क्लाइंट पेज पर जाएं.
क्लाइंट बनाएं पर क्लिक करें.
ऐप्लिकेशन टाइप के तौर पर, डेस्कटॉप ऐप्लिकेशन चुनें.
Name फ़ील्ड में, OAuth क्लाइंट का नाम डालें. यह नाम आपके प्रोजेक्ट के क्लाइंट पेज पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
बनाएं पर क्लिक करें.

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

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

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

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

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 के क्लाइंट पेज पर देखी जा सकती है.

redirect_uri

ज़रूरी है

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

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

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

code_challenge

सुझाया गया

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

code_challenge_method

सुझाया गया

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

state

सुझाया गया

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

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

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

login_hint

ज़रूरी नहीं

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

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

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

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

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

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

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

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

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

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

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

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

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

गड़बड़ियां

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

`admin_policy_enforced`

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

`disallowed_useragent`

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

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

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

`org_internal`

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

`deleted_client`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

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

हेडर	ज़रूरी है	ब्यौरा
`DPoP`	वैकल्पिक	डीपीओपी प्रूफ़ एक जेडब्ल्यूटी है, जिससे निजी पासकोड के मालिकाना हक की पुष्टि होती है. यह एक हेडर है, न कि पैरामीटर. अगर टोकन दिए जाते हैं, तो वे इस कुंजी से जुड़े होते हैं. हर अनुरोध के लिए एक नया और यूनीक सबूत जनरेट किया जाना चाहिए. साथ ही, इसमें `htm` (एचटीटीपी तरीका) और `htu` (एचटीटीपी यूआरआई) दावे शामिल होने चाहिए, जो अनुरोध से मेल खाते हों.

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

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

DPoP प्रूफ़ बनाना

यहां दिए गए तरीके से, कमांड लाइन से OpenSSL का इस्तेमाल करके, डीपीओपी प्रूफ़ बनाने का तरीका बताया गया है:

ईसी पी-256 कुंजी का जोड़ा जनरेट करना:

openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

डीपीओपी हेडर बनाएं:
हेडर में typ, alg, और jwk (सार्वजनिक पासकोड) के दावे शामिल होने चाहिए. x और y वैल्यू, आपके ईसी सार्वजनिक पासकोड के Base64Url-कोड में बदले गए निर्देशांक हैं. इस JSON को Base64Url में कोड में बदलें:
```
{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"YOUR_PUBLIC_KEY_X",
    "y":"YOUR_PUBLIC_KEY_Y",
    "crv":"P-256"
  }
}
```
डीपीओपी पेलोड बनाएं:
पेलोड में jti (अनुरोध के लिए यूनीक आइडेंटिफ़ायर), htm (एचटीटीपी मेथड, जैसे कि POST), htu (एचटीटीपी यूआरआई, जैसे कि https://oauth2.googleapis.com/token), और iat (जारी करने का समय) शामिल होना चाहिए. अगर आपको पिछले अनुरोध के जवाब में DPoP-Nonce हेडर में सर्वर से कोई नॉन्स मिला है, तो आपको उस नॉन्स वैल्यू को nonce दावे में शामिल करना होगा. ऑथराइज़ेशन कोड एक्सचेंज के लिए, नॉन्स क्लेम करना ज़रूरी नहीं है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब DPoP-Nonce हेडर पहले मिल चुका हो. इस JSON को Base64Url में कोड में बदलें:
```
{
  "jti":"JTI_VALUE",
  "htm":"POST",
  "htu":"https://oauth2.googleapis.com/token",
  "iat":YOUR_JWT_ISSUED_TIME,
  "nonce":"SERVER_PROVIDED_NONCE"
}
```
jti की वैल्यू, एक्सचेंज के टाइप पर निर्भर करती है:
- ऑथराइज़ेशन कोड एक्सचेंज के लिए, jti, ऑथराइज़ेशन कोड का Base64Url-कोड में बदला गया SHA256 हैश होना चाहिए: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
- रिफ़्रेश टोकन एक्सचेंज के लिए, jti हर अनुरोध के लिए एक यूनीक आइडेंटिफ़ायर होना चाहिए: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
सबूत पर हस्ताक्षर करना:
एन्कोड किए गए हेडर और पेलोड को पीरियड (.) के साथ जोड़ें. इसके बाद, ES256 का इस्तेमाल करके, अपने निजी पासकोड से नतीजे पर हस्ताक्षर करें. ध्यान दें कि JWS के लिए, हस्ताक्षर को रॉ R | S कॉनकैटेनेटेड फ़ॉर्मैट (P-256 के लिए 64 बाइट) में होना चाहिए. अगर OpenSSL का सीधे तौर पर इस्तेमाल किया जा रहा है, तो आपको डिफ़ॉल्ट ASN.1 DER-एन्कोड किए गए सिग्नेचर को इस रॉ फ़ॉर्मैट में बदलना होगा.

सफल एक्सचेंज की जानकारी, टोकन वाले 200 OK रिस्पॉन्स से मिलती है. अगर एक्सचेंज के दौरान मान्य डीपीओपी प्रूफ़ का इस्तेमाल किया जाता है, तो Google जो रीफ़्रेश टोकन दिखाएगा वह आपकी कुंजी से डीपीओपी-बाउंड होगा. हालांकि, ऐक्सेस टोकन डीपीओपी बाउंड नहीं होंगे. ऐक्सेस टोकन में DPoP के बजाय Bearer का token_type बना रहेगा. इसके अलावा, Google जवाब में DPoP-Nonce एचटीटीपी हेडर दिखाता है. आपके क्लाइंट को इस नॉन्स को कैश मेमोरी में सेव करना होगा. साथ ही, इसे बाद के अनुरोधों में DPoP प्रूफ़ के nonce दावे में शामिल करना होगा. जैसे, नए ऐक्सेस टोकन के लिए रीफ़्रेश टोकन को एक्सचेंज करते समय या DPoP से सुरक्षित एपीआई को कॉल करते समय. पहले से जारी किए गए इस नॉन्स का इस्तेमाल करके, अपने अगले अनुरोध पर दोतरफ़ा यात्रा की गड़बड़ी (use_dpop_nonce) से बचा जा सकता है.

DPoP से बाउंड किए गए रीफ़्रेश टोकन के साथ किए गए टोकन एक्सचेंज के अनुरोधों के लिए, DPoP के सबूत शामिल किए जाने चाहिए.

एक्सचेंज पूरा न होने की गड़बड़ी तब होती है, जब DPoP हेडर मौजूद न हो, अमान्य हो या सबूत के तौर पर इस्तेमाल की गई कुंजी, टोकन से जुड़ी कुंजी से अलग हो. इन मामलों में, सर्वर 400 Bad Request गड़बड़ी दिखाता है. अगर डीपीओपी प्रूफ़ में htm या htu के दावे मेल नहीं खाते हैं, iat की समयसीमा खत्म हो गई है, jti का फिर से इस्तेमाल किया गया है या हस्ताक्षर अमान्य है, तो Google invalid_dpop_proof गड़बड़ी का कोड दिखाता है. अगर डीपीओपी नॉन्स की ज़रूरत है, जैसे कि रीफ़्रेश टोकन एक्सचेंज के दौरान, और डीपीओपी प्रूफ़ में nonce दावा मौजूद नहीं है या नॉन्स की वैल्यू सर्वर के लिए स्वीकार नहीं की जा सकती (उदाहरण के लिए, इसकी समयसीमा खत्म हो गई है, पहले ही इस्तेमाल की जा चुकी है या गलत है), तो Google use_dpop_nonce गड़बड़ी कोड के साथ-साथ DPoP-Nonce एचटीटीपी हेडर दिखाता है. इसमें एक नया नॉन्स होता है, जिसका इस्तेमाल बाद के अनुरोध में किया जा सकता है. अन्य गड़बड़ियों के लिए, invalid_grant दिख सकता है.

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

रिस्पॉन्स में ये फ़ील्ड शामिल होते हैं:

फ़ील्ड
`access_token`	वह टोकन जिसे आपका ऐप्लिकेशन, Google API के अनुरोध को अनुमति देने के लिए भेजता है.
`expires_in`	ऐक्सेस टोकन की समयसीमा खत्म होने में बचे सेकंड.
`id_token`	ध्यान दें: यह प्रॉपर्टी सिर्फ़ तब दिखती है, जब आपके अनुरोध में पहचान का दायरा शामिल हो. जैसे, `openid`, `profile` या `email`. यह वैल्यू, JSON वेब टोकन (JWT) होती है. इसमें उपयोगकर्ता की पहचान की जानकारी होती है, जिस पर डिजिटल हस्ताक्षर किया गया होता है.
`refresh_token`	यह एक ऐसा टोकन है जिसका इस्तेमाल करके, नया ऐक्सेस टोकन हासिल किया जा सकता है. रीफ़्रेश टोकन तब तक मान्य रहते हैं, जब तक उपयोगकर्ता ऐक्सेस वापस नहीं ले लेता या रीफ़्रेश टोकन की समयसीमा खत्म नहीं हो जाती. अगर डीपीओपी का इस्तेमाल किया गया था, तो रीफ़्रेश टोकन उस निजी पासकोड से जुड़ा होता है जिसका इस्तेमाल डीपीओपी के सबूत पर हस्ताक्षर करने के लिए किया गया था. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के लिए, रीफ़्रेश टोकन हमेशा दिखाए जाते हैं.
`refresh_token_expires_in`	रीफ़्रेश टोकन की समयसीमा खत्म होने में बचे सेकंड. यह वैल्यू सिर्फ़ तब सेट होती है, जब उपयोगकर्ता समय के हिसाब से ऐक्सेस देता है.
`scope`	`access_token` से मिले ऐक्सेस के स्कोप. इन्हें स्पेस-डिलिमिटेड और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाया जाता है.
`token_type`	लौटाए गए टोकन का टाइप. यह वैल्यू हमेशा `Bearer` होती है, भले ही डीपीओपी का इस्तेमाल किया गया हो.

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

यहां दिए गए स्निपेट में, डीपीओपी का इस्तेमाल करने पर मिलने वाले रिस्पॉन्स हेडर और मुख्य हिस्से का सैंपल दिखाया गया है:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

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

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

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

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

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

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

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

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

Google API को कॉल करना

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

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

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

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, drive.files एंडपॉइंट (Drive Files API) को किया गया कॉल कुछ ऐसा दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन डालना होगा:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

`curl` के उदाहरण

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

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

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

ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन Google के ऑथराइज़ेशन सर्वर (https://oauth2.googleapis.com/token) को एचटीटीपीएस POST अनुरोध भेजता है. इस अनुरोध के मुख्य हिस्से में ये पैरामीटर शामिल होते हैं:

नाम	वैल्यू
`client_id`	API Console से मिला क्लाइंट आईडी.
`client_secret`	ज़रूरी नहीं API Console से मिला क्लाइंट सीक्रेट. (`client_secret`, Android, iOS या Chrome ऐप्लिकेशन के तौर पर रजिस्टर किए गए क्लाइंट के अनुरोधों पर लागू नहीं होता.)
`grant_type`	OAuth 2.0 की खास जानकारी में बताए गए तरीके के मुताबिक, इस फ़ील्ड की वैल्यू `refresh_token` पर सेट होनी चाहिए.
`refresh_token`	ऑथराइज़ेशन कोड एक्सचेंज से मिला रीफ़्रेश टोकन.

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

हेडर	ज़रूरी है	ब्यौरा
`DPoP`	वैकल्पिक	डीपीओपी प्रूफ़ एक जेडब्ल्यूटी है, जिससे निजी पासकोड के मालिकाना हक की पुष्टि होती है. यह एक हेडर है, न कि पैरामीटर. अगर टोकन दिए जाते हैं, तो वे इस कुंजी से जुड़े होते हैं. हर अनुरोध के लिए एक नया और यूनीक सबूत जनरेट किया जाना चाहिए. साथ ही, इसमें `htm` (एचटीटीपी तरीका) और `htu` (एचटीटीपी यूआरआई) दावे शामिल होने चाहिए, जो अनुरोध से मेल खाते हों.

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

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

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

सफल एक्सचेंज की जानकारी, 200 OK रिस्पॉन्स से मिलती है. इसमें एक नया ऐक्सेस टोकन शामिल होता है. डीपीओपी का इस्तेमाल करने पर, token_type को Bearer पर सेट किया जाता है. सफल रिस्पॉन्स से पुष्टि होती है कि रीफ़्रेश टोकन के लिए, डीपीओपी के सबूत को स्वीकार कर लिया गया है. Google, जवाब में एक नया DPoP-Nonce एचटीटीपी हेडर भी दिखा सकता है. अगर ऐसा होता है, तो आपके क्लाइंट को इस नॉन्स को कैश मेमोरी में सेव करना होगा. साथ ही, बाद के अनुरोधों में, इसे डीपीओपी के सबूत के nonce दावे में शामिल करना होगा.

अगर DPoP हेडर मौजूद नहीं है, अमान्य है या गलत कुंजी का इस्तेमाल किया गया है, तो एक्सचेंज नहीं हो पाता. डीपीओपी से जुड़ी गड़बड़ी के खास कोड और नॉन्स को मैनेज करने के बारे में जानकारी पाने के लिए, एक्सचेंज नहीं हो सका लेख पढ़ें.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

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

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

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

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

प्रोग्राम के हिसाब से टोकन को रद्द करने के लिए, आपका ऐप्लिकेशन https://oauth2.googleapis.com/revoke को अनुरोध भेजता है और टोकन को पैरामीटर के तौर पर शामिल करता है:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

टोकन, ऐक्सेस टोकन या रीफ़्रेश टोकन हो सकता है. अगर टोकन एक ऐक्सेस टोकन है और उसका कोई रीफ़्रेश टोकन है, तो रीफ़्रेश टोकन को भी रद्द कर दिया जाएगा.

अगर टोकन रद्द करने की प्रोसेस पूरी हो जाती है, तो जवाब का एचटीटीपी स्टेटस कोड 200 होता है. गड़बड़ी की स्थितियों के लिए, गड़बड़ी के कोड के साथ एचटीटीपी स्टेटस कोड 400 दिखाया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समय के आधार पर ऐक्सेस

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

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

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

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

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

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

Google की सभी खातों की सुरक्षा सेवा, आपके ऐप्लिकेशन को कुछ इवेंट भेजती है. यहां उनके कुछ उदाहरण दिए गए हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

DPoP प्रूफ़ बनाना

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

Google API को कॉल करना

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

curl के उदाहरण

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

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

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

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

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

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

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

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

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

समय के आधार पर ऐक्सेस

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

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण