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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iOS

iOS ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए कोई नाम डालें. यह नाम आपके प्रोजेक्ट के क्लाइंट पेज पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
अपने ऐप्लिकेशन के लिए बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की जानकारी वाली प्रॉपर्टी लिस्ट रिसॉर्स फ़ाइल (info.plist) में मौजूद CFBundleIdentifier कुंजी की वैल्यू होती है. यह वैल्यू, आम तौर पर Xcode प्रोजेक्ट एडिटर के जनरल पैनल या साइनिंग और कैपेबिलिटी पैनल में दिखती है. बंडल आईडी, Apple के App Store Connect की साइट पर ऐप्लिकेशन के लिए, ऐप्लिकेशन की जानकारी वाले पेज के सामान्य जानकारी सेक्शन में भी दिखता है.
पुष्टि करें कि आपके ऐप्लिकेशन के लिए सही बंडल आईडी का इस्तेमाल किया जा रहा है. ऐसा इसलिए, क्योंकि App Check सुविधा का इस्तेमाल करने पर, बंडल आईडी को बदला नहीं जा सकेगा.
(ज़रूरी नहीं)
अगर ऐप्लिकेशन को Apple के App Store में पब्लिश किया गया है, तो अपने ऐप्लिकेशन का App Store आईडी डालें. स्टोर आईडी, एक न्यूमेरिक स्ट्रिंग होती है. यह Apple ऐप स्टोर के हर यूआरएल में शामिल होती है.
1. अपने iOS या iPadOS डिवाइस पर, Apple App Store ऐप्लिकेशन खोलें.
2. अपना ऐप्लिकेशन खोजें.
3. 'शेयर करें' बटन (स्क्वेयर और ऊपर की ओर ऐरो वाला सिंबल) को चुनें.
4. लिंक कॉपी करें को चुनें.
5. लिंक को किसी टेक्स्ट एडिटर में चिपकाएं. App Store आईडी, यूआरएल का आखिरी हिस्सा होता है.
  उदाहरण: https://apps.apple.com/app/google/id284815942
(ज़रूरी नहीं)
अपनी टीम का आईडी डालें. ज़्यादा जानकारी के लिए, Apple डेवलपर खाते के दस्तावेज़ में अपना टीम आईडी ढूंढें देखें.
ध्यान दें: अगर आपको अपने क्लाइंट के लिए App Check की सुविधा चालू करनी है, तो टीम आईडी फ़ील्ड भरना ज़रूरी है.
(ज़रूरी नहीं)
अपने iOS ऐप्लिकेशन के लिए App Check की सुविधा चालू करें. App Check की सुविधा चालू करने पर, Apple की App Attest सेवा का इस्तेमाल करके यह पुष्टि की जाती है कि आपके OAuth क्लाइंट से मिले OAuth 2.0 अनुरोध असली हैं और आपके ऐप्लिकेशन से मिले हैं. इससे ऐप्लिकेशन के नाम पर धोखाधड़ी होने का जोखिम कम हो जाता है. अपने iOS ऐप्लिकेशन के लिए, App Check की सुविधा चालू करने के बारे में ज़्यादा जानें.
बनाएं पर क्लिक करें.

डेस्कटॉप

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

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

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

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 Workspace एडमिन की नीतियों की वजह से, Google खाते से अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दी जा सकती. 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_callenge पैरामीटर अमान्य है या मौजूद नहीं है. पक्का करें कि code_challenge पैरामीटर सही तरीके से सेट किया गया हो.

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

`redirect_uri_mismatch`

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

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

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

`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 का इस्तेमाल करके, डीपीओपी प्रूफ़ कैसे बनाया जाता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आईईटीएफ़ के सबसे सही मौजूदा तरीके 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

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

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

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

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

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

iOS

डेस्कटॉप

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

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 के लिए ऐप्लिकेशन के मालिकाना हक की पुष्टि करना

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