टीवी और सीमित इनपुट डिवाइस ऐप्लिकेशन के लिए OAuth 2.0

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

विकल्प

अगर Android, iOS, macOS, Linux या Windows जैसे प्लैटफ़ॉर्म के लिए ऐप्लिकेशन लिखा जा रहा है (इसमें Universal Windows Platform भी शामिल है). इसके पास ब्राउज़र और पूरे इनपुट का ऐक्सेस है के लिए, मोबाइल के लिए OAuth 2.0 फ़्लो का इस्तेमाल करें और डेस्कटॉप ऐप्लिकेशन हैं. (आपको इस फ़्लो का इस्तेमाल करना चाहिए, भले ही आपका ऐप्लिकेशन कोई कमांड-लाइन हो बिना ग्राफ़िकल इंटरफ़ेस वाला टूल उपलब्ध है.)

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

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

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

अगर कोई ऐप्लिकेशन Google API को कॉल करता है, तो उसे API Console.

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

1. Open the API Library Google API Console.
2. If prompted, select a project, or create a new one.
3. API Library में, प्रॉडक्ट के हिसाब से ग्रुप किए गए सभी उपलब्ध एपीआई की सूची दी गई है परिवार और लोकप्रियता. आपको जिस एपीआई को चालू करना है अगर वह सूची में नहीं दिख रहा है, तो खोजने के लिए खोज का इस्तेमाल करें इसे ढूंढें या इसके प्रॉडक्ट फ़ैमिली में सभी देखें पर क्लिक करें.
4. वह एपीआई चुनें जिसे आपको चालू करना है. इसके बाद, चालू करें बटन पर क्लिक करें.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

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

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

1. Go to the Credentials page.
2. क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी.
3. टीवी और सीमित इनपुट डिवाइस ऐप्लिकेशन टाइप चुनें.
4. अपने OAuth 2.0 क्लाइंट को कोई नाम दें और बनाएं पर क्लिक करें.

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

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

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

इंस्टॉल किए गए ऐप्लिकेशन या डिवाइसों के लिए, अनुमति वाले दायरे की सूची देखें.

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

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

1. आपका ऐप्लिकेशन, Google के ऑथराइज़ेशन सर्वर को अनुरोध भेजता है, जो स्कोप की पहचान करता है कि आपका ऐप्लिकेशन ऐक्सेस करने के लिए अनुमति का अनुरोध करेगा.
2. इसके बाद, सर्वर कई जानकारी के साथ जवाब देता है. इसका इस्तेमाल आगे के चरणों में किया जाता है, जैसे कि डिवाइस कोड और उपयोगकर्ता कोड.
3. आप ऐसी जानकारी दिखाते हैं जिसे उपयोगकर्ता, अनुमति देने के लिए किसी दूसरे डिवाइस पर डाल सकता है है.
4. आपका ऐप्लिकेशन, Google के ऑथराइज़ेशन सर्वर की पोलिंग शुरू करता है, ताकि यह पता लगाया जा सके कि उपयोगकर्ता ने आपके ऐप्लिकेशन को अनुमति दी है.
5. जब उपयोगकर्ता बेहतर इनपुट क्षमताओं वाले डिवाइस पर स्विच करता है, वेब ब्राउज़र लॉन्च करता है, तीसरे चरण में दिखाए गए यूआरएल पर जाता है और तीसरे चरण में दिखाया गया कोड डालता है. कॉन्टेंट बनाने उपयोगकर्ता आपके ऐप्लिकेशन को ऐक्सेस दे सकता है (या अस्वीकार कर सकता है).
6. पोलिंग के अनुरोध के अगले जवाब में, वे टोकन शामिल होते हैं जिन्हें अनुमति देने की आपके ऐप्लिकेशन को ज़रूरत होती है आपके अनुरोध को प्रोसेस करता है. (अगर उपयोगकर्ता ने आपके ऐप्लिकेशन को ऐक्सेस करने से मना कर दिया है, तो में टोकन शामिल नहीं हैं.)

नीचे दी गई इमेज में यह प्रोसेस दिखाई गई है:

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

पहला चरण: डिवाइस और उपयोगकर्ता कोड का अनुरोध करना

इस चरण में आपका डिवाइस, Google के ऑथराइज़ेशन सर्वर को इस नंबर पर एक एचटीटीपी पोस्ट अनुरोध भेजता है https://oauth2.googleapis.com/device/code, जिससे आपके ऐप्लिकेशन की पहचान की जाती है उपयोगकर्ता की ओर से आपके ऐप्लिकेशन को ऐक्सेस किए जाने वाले ऐक्सेस के दायरे भी शामिल होंगे. आपको यह यूआरएल यहां से फिर से हासिल करना चाहिए: डिस्कवरी दस्तावेज़: device_authorization_endpoint मेटाडेटा की वैल्यू. नीचे दिया गया एचटीटीपी अनुरोध शामिल करें पैरामीटर:

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

उदाहरण

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

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

client_id=client_id&scope=email%20profile

इस उदाहरण में, एक जैसे अनुरोध भेजने के लिए curl कमांड दिखाया गया है:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

दूसरा चरण: ऑथराइज़ेशन सर्वर के रिस्पॉन्स को मैनेज करना

ऑथराइज़ेशन सर्वर, इनमें से कोई एक रिस्पॉन्स देगा:

सफलता का रिस्पॉन्स

अगर अनुरोध मान्य है, तो आपका जवाब एक JSON ऑब्जेक्ट होगा, जिसमें ये शामिल होंगे प्रॉपर्टी:

प्रॉपर्टी
device_code	वह वैल्यू जिसे Google खास तौर पर, अनुरोध करने वाले ऐप्लिकेशन को चलाने वाले डिवाइस की पहचान करने के लिए असाइन करता है अनुमति. उपयोगकर्ता उस डिवाइस को बेहतर सुविधा वाले किसी दूसरे डिवाइस से अनुमति देगा इनपुट क्षमता. उदाहरण के लिए, कोई उपयोगकर्ता किसी टीवी पर चल रहा ऐप्लिकेशन. इस मामले में, device_code, टीवी की पहचान करता है. इस कोड से, ऐप्लिकेशन को चलाने वाला डिवाइस सुरक्षित तरीके से यह तय करता है कि उपयोगकर्ता ने अनुमति दी है या नहीं या ऐक्सेस की अनुमति न मिले.
expires_in	device_code और सेकंड में वह समय अवधि user_code मान्य हैं. अगर उपयोगकर्ता उस समय, शर्तें पूरी नहीं करता है, प्राधिकरण फ़्लो और आपका डिवाइस, उपयोगकर्ता का फ़ैसला लेने के लिए, आपको पहले चरण से यह प्रोसेस फिर से शुरू करनी पड़ सकती है.
interval	पोलिंग अनुरोध के बीच में डिवाइस को लगने वाला वह समय (सेकंड में). इसके लिए उदाहरण के लिए, अगर वैल्यू 5 है, तो आपके डिवाइस को Google का ऑथराइज़ेशन सर्वर हर पांच सेकंड में सेव होता है. यहां जाएं: ज़्यादा जानकारी के लिए, तीसरा चरण देखें.
user_code	एक केस-सेंसिटिव वैल्यू, जो Google को उन स्कोप की पहचान करती है जिनके दायरे में ऐप्लिकेशन इसके ऐक्सेस का अनुरोध कर रहा है. आपका यूज़र इंटरफ़ेस, उपयोगकर्ता को यह वैल्यू डालने के लिए निर्देश देगा बेहतर इनपुट क्षमताओं के साथ अलग डिवाइस. इसके बाद Google, उपयोगकर्ताओं को आपके ऐप्लिकेशन का ऐक्सेस देने का अनुरोध करते समय, दायरों का सही सेट.
verification_url	ऐसा यूआरएल जिस पर जाने के लिए उपयोगकर्ता को किसी दूसरे डिवाइस पर नेविगेट करना होगा user_code और अपने ऐप्लिकेशन का ऐक्सेस दें या अस्वीकार करें. आपका यूज़र इंटरफ़ेस भी इस वैल्यू को दिखाएगा.

नीचे दिया गया स्निपेट एक सैंपल रिस्पॉन्स दिखाता है:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

कोटे से ज़्यादा अनुरोध किया गया

अगर डिवाइस कोड के अनुरोधों ने आपके क्लाइंट आईडी से जुड़े कोटा को पार कर लिया है, तो आपको आपको 403 कोड वाला रिस्पॉन्स मिलता है, जिसमें यह गड़बड़ी होती है:

{
  "error_code": "rate_limit_exceeded"
}

ऐसे मामले में, अनुरोधों की दर कम करने के लिए बैकऑफ़ रणनीति का इस्तेमाल करें.

तीसरा चरण: उपयोगकर्ता कोड दिखाना

दूसरे चरण में मिले verification_url और user_code को उपयोगकर्ता. दोनों वैल्यू में US-ASCII वर्ण सेट से कोई भी प्रिंट किया जा सकने वाला वर्ण हो सकता है. कॉन्टेंट जो उपयोगकर्ता को दिखाया जाता है उसमें उपयोगकर्ता को किसी दूसरे डिवाइस पर verification_url और user_code डालें.

नीचे दिए गए नियमों को ध्यान में रखते हुए अपना यूज़र इंटरफ़ेस (यूआई) डिज़ाइन करें:

• user_code
  • user_code को ऐसे फ़ील्ड में दिखाना ज़रूरी है जो 15 'W' को हैंडल कर सके साइज़ वर्ण दूसरे शब्दों में, अगर आप WWWWWWWWWWWWWWW कोड दिखा सकते हैं, तो सही ढंग से, आपका यूआई मान्य है, और हम आपको user_code आपके यूज़र इंटरफ़ेस (यूआई) में दिखता है.
  • user_code केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होता है और इसमें किसी भी तरह का बदलाव नहीं किया जाना चाहिए, जैसे जैसे कि केस बदलना या अन्य फ़ॉर्मैटिंग वर्ण शामिल करना.
• verification_url
  • जिस स्पेस में verification_url दिखाया जाता है वह इतनी चौड़ी होनी चाहिए कि 40 वर्ण लंबी URL स्ट्रिंग हैंडल करे.
  • आपको verification_url में किसी भी तरह का बदलाव नहीं करना चाहिए, लेकिन ऐसा करना ज़रूरी नहीं है डिसप्ले की स्कीम हटाएं. अगर आपको स्कीम को हटाना है, तो (उदाहरण के लिए, https://) की समीक्षा करने के लिए, पक्का करें कि आपका ऐप्लिकेशन इन्हें हैंडल कर सकता हो http और https, दोनों वैरिएंट.

चौथा चरण: पोल Google के ऑथराइज़ेशन सर्वर की मदद से पुष्टि करने की सुविधा

verification_url पर जाने के लिए, उपयोगकर्ता किसी अलग डिवाइस का इस्तेमाल करेगा और ऐक्सेस देने (या अस्वीकार) करने के बाद भी, अनुरोध करने वाले डिवाइस को तब अपने-आप सूचित नहीं किया जाता है, जब उपयोगकर्ता ऐक्सेस के अनुरोध का जवाब देता है. इस वजह से, अनुरोध करने वाले डिवाइस को Google के अनुमति देने वाले सर्वर का इस्तेमाल करता है, ताकि यह तय किया जा सके कि उपयोगकर्ता ने अनुरोध का जवाब कब दिया है.

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

पोल के एंडपॉइंट का यूआरएल https://oauth2.googleapis.com/token है. पोलिंग का अनुरोध इसमें ये पैरामीटर शामिल होते हैं:

पैरामीटर
client_id	आपके ऐप्लिकेशन का क्लाइंट आईडी. आपको यह वैल्यू यहां दिखेगी API Consoleअभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है Credentials page.
client_secret	दिए गए client_id के लिए क्लाइंट सीक्रेट. आपको यह वैल्यू यहां दिखेगी API Consoleअभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है Credentials page.
device_code	ऑथराइज़ेशन सर्वर से मिलने वाला device_code, दूसरा चरण.
grant_type	इस वैल्यू को urn:ietf:params:oauth:grant-type:device_code पर सेट करें.

उदाहरण

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

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

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

इस उदाहरण में, एक जैसे अनुरोध भेजने के लिए curl कमांड दिखाया गया है:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

पांचवां चरण: उपयोगकर्ता, ऐक्सेस के अनुरोध का जवाब देता है

नीचे दी गई इमेज में, वैसा ही पेज दिखाया गया है जैसा उपयोगकर्ताओं को तब दिखता है, जब वे verification_url, जिसे आपने तीसरे चरण में दिखाया है:

user_code डालने के बाद, अगर आपने पहले से लॉग इन नहीं किया है, तो Google में लॉग इन करें, जब उपयोगकर्ता को सहमति वाली स्क्रीन दिखती है, जैसा कि नीचे दिखाया गया है:

छठा चरण: पोलिंग के अनुरोधों के जवाब मैनेज करना

Google की अनुमति देने वाला सर्वर, पोल के हर अनुरोध का जवाब देने के लिए, इनमें से किसी एक शर्त को पूरा करता है जवाब:

ऐक्सेस दिया गया

अगर उपयोगकर्ता ने डिवाइस का ऐक्सेस दिया है (सहमति स्क्रीन पर Allow पर क्लिक करके), तो रिस्पॉन्स में ऐक्सेस टोकन और रीफ़्रेश टोकन शामिल होते हैं. टोकन आपके डिवाइस को ये काम करने में मदद करते हैं उपयोगकर्ता की ओर से Google API ऐक्सेस करें. (scope रिस्पॉन्स में जोड़ी गई प्रॉपर्टी से यह तय होता है कि डिवाइस ऐक्सेस कर सकता है.)

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

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

नीचे दिया गया स्निपेट एक सैंपल रिस्पॉन्स दिखाता है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

ऐक्सेस करने की मंज़ूरी नहीं मिली

अगर उपयोगकर्ता डिवाइस का ऐक्सेस नहीं देता है, तो सर्वर के रिस्पॉन्स में 403 एचटीटीपी रिस्पॉन्स स्टेटस कोड (Forbidden). इस जवाब में निम्न गड़बड़ी:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

अनुमति मिलना बाकी है

अगर उपयोगकर्ता ने अभी तक अनुमति देने वाला फ़्लो पूरा नहीं किया है, तो सर्वर 428 एचटीटीपी रिस्पॉन्स स्टेटस कोड (Precondition Required). जवाब में यह गड़बड़ी है:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

बहुत जल्दी-जल्दी पोल किया जा रहा है

अगर डिवाइस बार-बार पोलिंग के अनुरोध भेजता है, तो सर्वर एक 403 दिखाता है एचटीटीपी रिस्पॉन्स स्टेटस कोड (Forbidden). जवाब में ये चीज़ें शामिल होती हैं गड़बड़ी:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

दूसरी गड़बड़ियां

अगर पोलिंग अनुरोध में कोई जानकारी मौजूद नहीं है, तो ऑथराइज़ेशन सर्वर गड़बड़ी भी दिखाता है पैरामीटर है या उसका पैरामीटर मान गलत है. इन अनुरोधों में आम तौर पर 400 होती है (Bad Request) या 401 (Unauthorized) एचटीटीपी रिस्पॉन्स की स्थिति कोड. इनमें ये गड़बड़ियां शामिल हैं:

गड़बड़ी	एचटीटीपी स्टेटस कोड	ब्यौरा
admin_policy_enforced	400	Google खाता, अनुरोध किए गए एक या उससे ज़्यादा दायरों को अनुमति नहीं दे सकता है, क्योंकि की नीतियों का पालन करना होगा. Google Workspace एडमिन सहायता केंद्र देखें लेख यह कंट्रोल करना कि किस तीसरे पक्ष और इंटरनल ऐप्लिकेशन, Google Workspace का डेटा ऐक्सेस करते हैं. इससे हमें यह जानने में मदद मिलेगी कि जब तक आपके OAuth को साफ़ तौर पर ऐक्सेस नहीं दिया जाता, तब तक एडमिन दायरों के ऐक्सेस पर पाबंदी लगा सकता है Client-ID.
invalid_client	401	OAuth क्लाइंट नहीं मिला. उदाहरण के लिए, यह गड़बड़ी तब होती है, जब client_id पैरामीटर की वैल्यू अमान्य है. OAuth क्लाइंट का टाइप गलत है. पक्का करें कि ऐप्लिकेशन का टाइप क्लाइंट आईडी के लिए, टीवी और सीमित इनपुट डिवाइस पर सेट है.
invalid_grant	400	code पैरामीटर की वैल्यू अमान्य है, पहले ही दावा किया जा चुका है या नहीं किया जा सकता पार्स किया गया.
unsupported_grant_type	400	grant_type पैरामीटर की वैल्यू अमान्य है.
org_internal	403	अनुरोध में दिया गया OAuth क्लाइंट आईडी, एक ऐसे प्रोजेक्ट का हिस्सा है जो Google खातों का ऐक्सेस सीमित करता है किसी खास समय में Google Cloud का संगठन. पुष्टि करें उपयोगकर्ता टाइप कॉन्फ़िगरेशन पर निर्भर करता है.

Calling Google API

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

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

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

एक कॉल drive.files Authorization: Bearer एचटीटीपी का इस्तेमाल करके एंडपॉइंट (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

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

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

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

फ़ील्ड
client_id	API Consoleसे मिला क्लाइंट आईडी.
client_secret	API Consoleसे मिला क्लाइंट सीक्रेट.
grant_type	जैसे तय की गई OAuth 2.0 का स्पेसिफ़िकेशन, इस फ़ील्ड का मान refresh_token पर सेट होना चाहिए.
refresh_token	ऑथराइज़ेशन कोड के एक्सचेंज से मिला रीफ़्रेश टोकन.

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

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

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

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

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

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

टोकन निरस्त करना

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

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

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

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

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

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

अनुमति वाले दायरे

डिवाइसों के लिए, OAuth 2.0 फ़्लो सिर्फ़ इन दायरों के लिए काम करता है:

OpenID Connect, Google साइन इन

• email
• openid
• profile

Drive API

• https://www.googleapis.com/auth/drive.appdata
• https://www.googleapis.com/auth/drive.file

YouTube API

• https://www.googleapis.com/auth/youtube
• https://www.googleapis.com/auth/youtube.readonly

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

अपने उपयोगकर्ताओं की सुरक्षा के लिए, Google Ads खातों में 'क्रॉस-खाता' लागू की जा रही है 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

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