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

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

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

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

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

पुस्तकालय और नमूने

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

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

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

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

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

अपने प्रोजेक्ट के लिए API को सक्षम करने के लिए:

Open the API Library में Google API Console.
If prompted, select a project, or create a new one.
YouTube Analytics API और YouTube Reporting API को ढूंढने और चालू करने के लिए, लाइब्रेरी पेज का इस्तेमाल करें. YouTube Analytics का डेटा पाने वाले कई ऐप्लिकेशन, YouTube Data API के साथ भी इंटरफ़ेस करते हैं. उन अन्य एपीआई का पता लगाएं जिनका इस्तेमाल आपका ऐप्लिकेशन करेगा. साथ ही, उन्हें भी चालू करें.

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

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

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

iOS

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

UWP

Universal Windows Platform ऐप्लिकेशन टाइप चुनें.
OAuth क्लाइंट के लिए कोई नाम डालें. यह नाम आपके प्रोजेक्ट के Clients page पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
अपने ऐप्लिकेशन का 12 वर्णों वाला Microsoft Store आईडी डालें. यह वैल्यू, Microsoft Partner Center में ऐप्लिकेशन मैनेजमेंट सेक्शन के ऐप्लिकेशन की पहचान पेज पर देखी जा सकती है.
बनाएं पर क्लिक करें.

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

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

ms-app://YOUR_APP_PACKAGE_SID

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

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

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

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

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

YouTube Analytics API इन स्कोप का इस्तेमाल करता है:

दायरा	ब्यौरा
`https://www.googleapis.com/auth/youtube`	अपना YouTube खाता मैनेज करें
`https://www.googleapis.com/auth/youtube.readonly`	अपना YouTube खाता देखें
`https://www.googleapis.com/auth/youtubepartner`	YouTube पर अपनी परिसंपत्ति और संबंधित सामग्री देखें व प्रबंधित करें
`https://www.googleapis.com/auth/yt-analytics-monetary.readonly`	अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखना
`https://www.googleapis.com/auth/yt-analytics.readonly`	अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

YouTube Reporting API इन स्कोप का इस्तेमाल करता है:

Scope	Description
`https://www.googleapis.com/auth/yt-analytics-monetary.readonly`	View monetary and non-monetary YouTube Analytics reports for your YouTube content
`https://www.googleapis.com/auth/yt-analytics.readonly`	View YouTube Analytics reports for your YouTube content

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 सर्वर को अनुरोध भेजना

उपयोगकर्ता प्राधिकरण प्राप्त करने के लिए, https://accounts.google.com/o/oauth2/v2/auth पर Google के प्राधिकरण सर्वर पर एक अनुरोध भेजें. यह एंडपॉइंट, चालू सेशन की जानकारी ढूंढता है, उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. इस एंडपॉइंट को सिर्फ़ एसएसएल पर ऐक्सेस किया जा सकता है. साथ ही, यह एचटीटीपी (नॉन-एसएसएल) कनेक्शन को अस्वीकार करता है.

अनुमति देने वाला सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए क्वेरी स्ट्रिंग के इन पैरामीटर का इस्तेमाल करता है:

पैरामीटर

client_id

ज़रूरी है

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

redirect_uri

ज़रूरी है

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

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

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

redirect_uri की वैल्यू

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

com.example.app:redirect_uri_path

या

com.googleusercontent.apps.123:redirect_uri_path

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

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

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

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

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

response_type

ज़रूरी है

यह निर्धारित करता है कि Google OAuth 2.0 एंडपॉइंट एक प्राधिकरण कोड लौटाता है या नहीं.

स्थापित अनुप्रयोगों के लिए पैरामीटर मान को code पर सेट करें.

scope

ज़रूरी है

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

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

YouTube Analytics API निम्नलिखित स्कोप का उपयोग करता है:

दायरा	ब्यौरा
`https://www.googleapis.com/auth/youtube`	अपना YouTube खाता मैनेज करें
`https://www.googleapis.com/auth/youtube.readonly`	अपना YouTube खाता देखें
`https://www.googleapis.com/auth/youtubepartner`	YouTube पर अपनी परिसंपत्ति और संबंधित सामग्री देखें व प्रबंधित करें
`https://www.googleapis.com/auth/yt-analytics-monetary.readonly`	अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखना
`https://www.googleapis.com/auth/yt-analytics.readonly`	अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

YouTube रिपोर्टिंग API निम्नलिखित स्कोप का उपयोग करता है:

Scope	Description
`https://www.googleapis.com/auth/yt-analytics-monetary.readonly`	View monetary and non-monetary YouTube Analytics reports for your YouTube content
`https://www.googleapis.com/auth/yt-analytics.readonly`	View YouTube Analytics reports for your YouTube content

OAuth 2.0 API स्कोप दस्तावेज़ उन सभी स्कोपों की पूरी सूची प्रदान करता है जिनका उपयोग आप Google API तक पहुँचने के लिए कर सकते हैं.

code_challenge

सुझाया गया

यह एक एन्कोडेड code_verifier निर्दिष्ट करता है जिसका उपयोग प्राधिकरण कोड विनिमय के दौरान सर्वर-साइड चुनौती के रूप में किया जाएगा. अधिक जानकारी के लिए क्रिएट कोड चैलेंज देखें.

code_challenge_method

सुझाया गया

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

state

सुझाया गया

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

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

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

login_hint

ज़रूरी नहीं

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

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

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

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

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

हर यूआरएल, ऐसे स्कोप के लिए ऐक्सेस का अनुरोध करता है जिससे उपयोगकर्ता की YouTube Analytics रिपोर्ट को ऐक्सेस किया जा सकता है.

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

कस्टम यूआरआई योजना

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

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

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

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

गड़बड़ियां

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

`admin_policy_enforced`

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

`disallowed_useragent`

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

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

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

`org_internal`

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

`deleted_client`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

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

`invalid_request`

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

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

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

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

यदि उपयोगकर्ता आपके एप्लिकेशन तक पहुंच प्रदान करता है, तो आप अगले चरण में वर्णित अनुसार प्राधिकरण कोड को एक्सेस टोकन और रिफ्रेश टोकन के लिए एक्सचेंज कर सकते हैं.

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

किसी प्राधिकरण कोड को एक्सेस टोकन में बदलने के लिए, https://oauth2.googleapis.com/token एंडपॉइंट को कॉल करें और निम्नलिखित पैरामीटर सेट करें:

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

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

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

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

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

जवाब में ये फ़ील्ड शामिल होते हैं:

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

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

यहाँ जवाब का एक सैंपल दिया गया है:

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

चरण 6: जांचें कि उपयोगकर्ताओं को किन-किन क्षेत्रों की अनुमति दी गई है.

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

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

अधिक विस्तृत जानकारी के लिए, ग्रैनुलर अनुमतियों को कैसे संभालें देखें.

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

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

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

Google API को कॉल करना

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

ध्यान दें कि YouTube Analytics API, सेवा खाते के फ़्लो के साथ काम नहीं करता. YouTube Reporting API, सिर्फ़ उन YouTube कॉन्टेंट के मालिकों के लिए सेवा खातों का इस्तेमाल करने की सुविधा देता है जिनके पास एक से ज़्यादा YouTube चैनलों का मालिकाना हक है और वे उन्हें मैनेज करते हैं. जैसे, रिकॉर्ड लेबल और फ़िल्म स्टूडियो.

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

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

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, reports.query एंडपॉइंट (YouTube Analytics API) को कॉल करने का तरीका यहां दिया गया है. ध्यान दें कि आपको अपना एक्सेस टोकन स्वयं निर्दिष्ट करना होगा:

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

`curl` के उदाहरण

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

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

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

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

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

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

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

निम्नलिखित उदाहरण एक नमूना अनुरोध दिखाता है:

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

जब तक उपयोगकर्ता ने एप्लिकेशन को दी गई पहुंच को रद्द नहीं किया है, तब तक टोकन सर्वर एक JSON ऑब्जेक्ट लौटाता है जिसमें एक नया एक्सेस टोकन होता है. यहाँ जवाब का एक सैंपल स्निपेट दिखाया गया है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly 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}

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

यदि निरस्तीकरण सफलतापूर्वक संसाधित हो जाता है, तो प्रतिक्रिया का HTTP स्टेटस कोड 200 होता है. त्रुटि की स्थिति में, एक HTTP स्टेटस कोड 400 के साथ एक त्रुटि कोड भी लौटाया जाता है.

ऐप रीडायरेक्ट विधियाँ

कस्टम यूआरआई योजना

कस्टम यूआरआई स्कीम्स डीपलिंकिंग का एक रूप है जो आपके ऐप को खोलने के लिए कस्टम-परिभाषित स्कीम का उपयोग करता है.

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

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

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

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

जब आपके ऐप को प्राधिकरण प्रतिक्रिया प्राप्त होती है, तो सर्वोत्तम उपयोगिता के लिए इसे एक एचटीएमएल पृष्ठ प्रदर्शित करके प्रतिक्रिया देनी चाहिए जो उपयोगकर्ता को ब्राउज़र बंद करने और आपके ऐप पर वापस लौटने का निर्देश देता है.

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

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

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

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

Chrome के लिए ऐप के स्वामित्व की पुष्टि करें

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

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

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

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

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

पुष्टि हो जाने पर, आपको एक सूचना दिखेगी. इससे पता चलेगा कि पुष्टि की प्रक्रिया पूरी हो गई है. अन्यथा, एक त्रुटि संदेश प्रदर्शित होगा.

सत्यापन में हुई विफलता को ठीक करने के लिए, निम्न प्रयास करें:

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

App Check (सिर्फ़ iOS)

ऐप चेक सुविधा आपके iOS अनुप्रयोगों को Apple की ऐप अटेस्ट सेवा का उपयोग करके अनधिकृत उपयोग से सुरक्षित रखने में मदद करती है ताकि यह सत्यापित किया जा सके कि Google OAuth 2.0 एंडपॉइंट्स पर किए गए अनुरोध आपके प्रामाणिक अनुप्रयोगों से उत्पन्न होते हैं. इससे ऐप के जरिए पहचान चुराने का खतरा कम होता है.

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

आपके iOS क्लाइंट के लिए ऐप चेक को सफलतापूर्वक सक्षम करने के लिए निम्नलिखित आवश्यकताओं को पूरा किया जाना चाहिए:

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

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

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

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

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

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

अपने iOS क्लाइंट के लिए ऐप चेक लागू करें

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

पुष्टि किए गए अनुरोधों की संख्या - ऐसे अनुरोध जिनमें मान्य App Check टोकन मौजूद है. App Check लागू करने की सुविधा चालू करने के बाद, सिर्फ़ इस कैटगरी के अनुरोध पूरे किए जाएंगे.
अपुष्ट अनुरोधों की संख्या: संभवतः पुराने क्लाइंट अनुरोध - अनुरोधों में ऐप चेक टोकन नहीं है; ये अनुरोध आपके ऐप के पुराने संस्करण से हो सकते हैं जिसमें ऐप चेक कार्यान्वयन शामिल नहीं है.
अपुष्ट अनुरोधों की संख्या: अज्ञात स्रोत अनुरोध - अनुरोध जिनमें ऐप चेक टोकन नहीं है और ऐसा नहीं लगता कि वे आपके ऐप से आ रहे हैं.
पुष्टि नहीं किए गए अनुरोधों की संख्या: अमान्य अनुरोध - ऐसे अनुरोध जिनमें App Check का अमान्य टोकन शामिल है. ये अनुरोध, ऐसे क्लाइंट से आ सकते हैं जो आपके ऐप्लिकेशन के नाम पर धोखाधड़ी करने की कोशिश कर रहा है या ये अनुरोध, एमुलेट किए गए एनवायरमेंट से आ सकते हैं.

इन मेट्रिक को देखकर जानें कि App Check लागू करने से, आपके उपयोगकर्ताओं पर क्या असर पड़ेगा.

App Check लागू करने के लिए, ENFORCE बटन पर क्लिक करें और अपने चुने गए विकल्प की पुष्टि करें. नीति उल्लंघन ठीक करने के लिए कार्रवाई लागू होने के बाद, आपके क्लाइंट के ऐसे सभी अनुरोध अस्वीकार कर दिए जाएंगे जिनकी पुष्टि नहीं हुई है.

ध्यान दें: नीति लागू करने की सुविधा चालू करने के बाद, बदलावों को लागू होने में 15 मिनट तक लग सकते हैं.

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

अपने ऐप्लिकेशन के लिए App Check को लागू न करने पर, लागू करना बंद हो जाएगा. साथ ही, इससे आपके क्लाइंट से Google OAuth 2.0 एंडपॉइंट को किए गए सभी अनुरोधों को अनुमति मिल जाएगी. इनमें बिना पुष्टि किए गए अनुरोध भी शामिल हैं.

अपने iOS क्लाइंट के लिए, App Check को लागू न करने के लिए, iOS क्लाइंट के बदलाव करने वाले व्यू पर जाएं. इसके बाद, लागू न करें बटन पर क्लिक करें और अपने विकल्प की पुष्टि करें.

ध्यान दें: App Check को लागू न करने के बाद, बदलावों को लागू होने में 15 मिनट तक लग सकते हैं.

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

अपने ऐप्लिकेशन के लिए App Check की सुविधा बंद करने पर, App Check की निगरानी और लागू करने की सुविधा बंद हो जाएगी. इसके बजाय, App Check को लागू न करें, ताकि अपने क्लाइंट के लिए मेट्रिक को मॉनिटर करना जारी रखा जा सके.

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

ध्यान दें: App Check की सुविधा बंद करने के बाद, बदलावों को लागू होने में 15 मिनट लग सकते हैं.

समय के हिसाब से ऐक्सेस

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

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

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

IETF के सबसे सही तरीके OAuth 2.0 for Native Apps में, यहां बताए गए कई सबसे सही तरीके शामिल हैं.

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

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

Google की Cross-Account Protection Service, आपके ऐप्लिकेशन को इस तरह के इवेंट भेजती है:

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

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

पुस्तकालय और नमूने

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

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

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

iOS

UWP

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

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

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

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

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

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

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

कस्टम यूआरआई योजना

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

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

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

चरण 6: जांचें कि उपयोगकर्ताओं को किन-किन क्षेत्रों की अनुमति दी गई है.

Google API को कॉल करना

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

curl के उदाहरण

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

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

ऐप रीडायरेक्ट विधियाँ

कस्टम यूआरआई योजना

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

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

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

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

Chrome के लिए ऐप के स्वामित्व की पुष्टि करें

App Check (सिर्फ़ iOS)

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

अपने iOS क्लाइंट के लिए ऐप चेक लागू करें

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

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

समय के हिसाब से ऐक्सेस

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

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण