टीवी और सीमित-इनपुट डिवाइस अनुप्रयोगों के लिए OAuth 2.0

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

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

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

वैकल्पिक

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

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

आवश्यक शर्तें

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

Google API को कॉल करने वाले किसी भी एप्लिकेशन को API Consoleमें उन API को सक्षम करने की आवश्यकता होती है।

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

  1. Open the API Library Google API Consoleमें।
  2. If prompted, select a project, or create a new one.
  3. API Library उत्पाद परिवार और लोकप्रियता के आधार पर समूहीकृत सभी उपलब्ध API को सूचीबद्ध करता है। यदि आप जिस एपीआई को सक्षम करना चाहते हैं वह सूची में दिखाई नहीं दे रहा है, तो उसे खोजने के लिए खोज का उपयोग करें, या उस उत्पाद परिवार में सभी देखें पर क्लिक करें जिससे वह संबंधित है।
  4. उस API का चयन करें जिसे आप सक्षम करना चाहते हैं, फिर सक्षम करें बटन पर क्लिक करें।
  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 सर्वर पर एप्लिकेशन की पहचान करता हो। निम्नलिखित चरण बताते हैं कि अपने प्रोजेक्ट के लिए क्रेडेंशियल कैसे बनाएं। तब आपके एप्लिकेशन उन API तक पहुंचने के लिए क्रेडेंशियल्स का उपयोग कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए सक्षम किया है।

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

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

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

इससे पहले कि आप OAuth 2.0 प्राधिकरण को लागू करना शुरू करें, हम अनुशंसा करते हैं कि आप उन क्षेत्रों की पहचान करें जिन्हें एक्सेस करने के लिए आपके ऐप को अनुमति की आवश्यकता होगी।

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

OAuth 2.0 एक्सेस टोकन प्राप्त करना

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

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

नीचे दी गई छवि इस प्रक्रिया को दर्शाती है:

उपयोगकर्ता एक अलग डिवाइस पर लॉग इन करता है जिसमें एक ब्राउज़र होता है

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

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

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

मापदंडों
client_id आवश्यक

आपके आवेदन के लिए क्लाइंट आईडी। आप यह मान API ConsoleCredentials 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

चरण 2: प्राधिकरण सर्वर प्रतिक्रिया को संभालें

प्राधिकरण सर्वर निम्नलिखित प्रतिक्रियाओं में से एक लौटाएगा:

सफलता प्रतिक्रिया

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

गुण
device_code एक मान जिसे Google विशिष्ट रूप से उस डिवाइस की पहचान करने के लिए निर्दिष्ट करता है जो प्राधिकरण का अनुरोध करने वाला ऐप चलाता है। उपयोगकर्ता उस डिवाइस को किसी अन्य डिवाइस से अधिक इनपुट क्षमताओं के साथ अधिकृत करेगा। उदाहरण के लिए, कोई उपयोगकर्ता किसी टीवी पर चलने वाले ऐप को अधिकृत करने के लिए लैपटॉप या मोबाइल फोन का उपयोग कर सकता है। इस मामले में, device_code टीवी की पहचान करता है।

यह कोड ऐप को चलाने वाले डिवाइस को सुरक्षित रूप से यह निर्धारित करने देता है कि उपयोगकर्ता ने एक्सेस दी है या नहीं।

expires_in समय की अवधि, सेकंड में, कि device_code और user_code मान्य हैं। यदि, उस समय में, उपयोगकर्ता प्राधिकरण प्रवाह को पूरा नहीं करता है और आपका उपकरण उपयोगकर्ता के निर्णय के बारे में जानकारी प्राप्त करने के लिए भी मतदान नहीं करता है, तो आपको चरण 1 से इस प्रक्रिया को पुनरारंभ करने की आवश्यकता हो सकती है।
interval मतदान अनुरोधों के बीच आपके डिवाइस को प्रतीक्षा करने में लगने वाला समय, सेकंड में। उदाहरण के लिए, यदि मान 5 है, तो आपके उपकरण को हर पांच सेकंड में Google के प्राधिकरण सर्वर को एक मतदान अनुरोध भेजना चाहिए। अधिक विवरण के लिए चरण 3 देखें।
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"
}

उस स्थिति में, अनुरोधों की दर को कम करने के लिए बैकऑफ़ रणनीति का उपयोग करें।

चरण 3: उपयोगकर्ता कोड प्रदर्शित करें

उपयोगकर्ता को चरण 2 में प्राप्त verification_url और user_code प्रदर्शित करें। दोनों मानों में यूएस-ASCII वर्ण सेट से कोई भी प्रिंट करने योग्य वर्ण हो सकता है। आपके द्वारा उपयोगकर्ता को प्रदर्शित की जाने वाली सामग्री को उपयोगकर्ता को एक अलग डिवाइस पर verification_url पर नेविगेट करने और उपयोगकर्ता_कोड दर्ज करने का निर्देश देना user_code

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

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

चरण 4: Google के प्राधिकरण सर्वर को मतदान करें

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

अनुरोध करने वाले उपकरण को तब तक मतदान अनुरोध भेजना जारी रखना चाहिए जब तक कि उसे यह संकेत न मिले कि उपयोगकर्ता ने एक्सेस अनुरोध का जवाब दिया है या जब तक चरण 2 में प्राप्त device_code और user_code की समय सीमा समाप्त नहीं हो जाती है। चरण 2 में दिया गया interval अनुरोधों के बीच प्रतीक्षा करने के लिए सेकंड में समय की मात्रा निर्दिष्ट करता है।

मतदान के समापन बिंदु का URL https://oauth2.googleapis.com/token है। मतदान अनुरोध में निम्नलिखित पैरामीटर शामिल हैं:

मापदंडों
client_id आपके आवेदन के लिए क्लाइंट आईडी। आप यह मान API ConsoleCredentials pageमें पा सकते हैं।
client_secret प्रदान किए गए client_id के लिए क्लाइंट रहस्य। आप यह मान API ConsoleCredentials pageमें पा सकते हैं।
device_code device_code प्राधिकरण सर्वर द्वारा चरण 2 में लौटाया गया।
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" \
         /token

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

निम्न छवि उसी पृष्ठ को दिखाती है जो उपयोगकर्ता तब देखते हैं जब वे verification_url पर नेविगेट करते हैं जिसे आपने चरण 3 में प्रदर्शित किया था:

कोड दर्ज करके डिवाइस कनेक्ट करें

user_code दर्ज करने के बाद और, यदि पहले से लॉग-इन नहीं है, तो Google में लॉग इन करते हुए, उपयोगकर्ता को एक सहमति स्क्रीन दिखाई देती है, जैसा कि नीचे दिखाया गया है:

डिवाइस क्लाइंट के लिए उदाहरण सहमति स्क्रीन

चरण 6: मतदान अनुरोधों के जवाबों को संभालें

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 HTTP प्रतिक्रिया स्थिति कोड ( Forbidden ) होता है। प्रतिक्रिया में निम्न त्रुटि है:

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

अनुमति विचाराधीन

यदि उपयोगकर्ता ने अभी तक प्राधिकरण प्रवाह पूरा नहीं किया है, तो सर्वर एक 428 HTTP प्रतिक्रिया स्थिति कोड ( Precondition Required ) देता है। प्रतिक्रिया में निम्न त्रुटि है:

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

बहुत बार मतदान

यदि डिवाइस बहुत बार मतदान अनुरोध भेजता है, तो सर्वर 403 HTTP प्रतिक्रिया स्थिति कोड ( Forbidden ) देता है। प्रतिक्रिया में निम्न त्रुटि है:

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

अन्य त्रुटियां

यदि मतदान अनुरोध में कोई आवश्यक पैरामीटर नहीं है या गलत पैरामीटर मान है, तो प्राधिकरण सर्वर त्रुटियाँ भी लौटाता है। इन अनुरोधों में आमतौर पर 400 ( Bad Request ) या 401 ( Unauthorized ) HTTP प्रतिक्रिया स्थिति कोड होता है। उन त्रुटियों में शामिल हैं:

त्रुटि HTTP स्थिति कोड विवरण
invalid_client 401 OAuth क्लाइंट नहीं मिला। उदाहरण के लिए, यह त्रुटि तब होती है जब client_id पैरामीटर मान अमान्य है।
invalid_grant 400 code पैरामीटर मान अमान्य है।
unsupported_grant_type 400 grant_type पैरामीटर मान अमान्य है।

Google API को कॉल करना

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

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

HTTP उदाहरण प्राप्त करें

प्राधिकरण का उपयोग करके drive.files एंडपॉइंट (ड्राइव फाइल एपीआई) के लिए एक कॉल Authorization: Bearer एचटीटीपी हेडर निम्न जैसा दिख सकता है। ध्यान दें कि आपको अपना स्वयं का एक्सेस टोकन निर्दिष्ट करने की आवश्यकता है:

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 कमांड-लाइन एप्लिकेशन के साथ इन कमांड्स का परीक्षण कर सकते हैं। यहां एक उदाहरण दिया गया है जो HTTP शीर्षलेख विकल्प (पसंदीदा) का उपयोग करता है:

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 ) को एक HTTPS POST अनुरोध भेजता है जिसमें निम्नलिखित पैरामीटर शामिल हैं:

खेत
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"
}

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

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

कुछ मामलों में एक उपयोगकर्ता किसी एप्लिकेशन को दी गई पहुंच को रद्द करना चाह सकता है। एक उपयोगकर्ता खाता सेटिंग पर जाकर पहुंच को निरस्त कर सकता है। अधिक जानकारी के लिए अपने खाते के समर्थन दस्तावेज़ तक पहुंच वाले तृतीय-पक्ष साइटों और ऐप्स का साइट या ऐप एक्सेस निकालें अनुभाग देखें।

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

किसी टोकन को प्रोग्रामेटिक रूप से निरस्त करने के लिए, आपका आवेदन 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 एक त्रुटि कोड के साथ दिया जाता है।

अनुमत कार्यक्षेत्र

उपकरणों के लिए OAuth 2.0 प्रवाह केवल निम्नलिखित क्षेत्रों के लिए समर्थित है:

ओपनआईडी कनेक्ट , गूगल साइन-इन

  • email
  • openid
  • profile

ड्राइव एपीआई

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

यूट्यूब एपीआई

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