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

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

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

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

वैकल्पिक

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

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

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

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

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

  1. Google API Console में Open the API Library
  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. उपयोगकर्ता रिच इनपुट क्षमताओं वाले डिवाइस पर स्विच करता है, एक वेब ब्राउज़र लॉन्च करता है, चरण 3 में प्रदर्शित URL पर नेविगेट करता है और एक कोड दर्ज करता है जो चरण 3 में भी प्रदर्शित होता है। उपयोगकर्ता आपके आवेदन तक पहुंच (या इनकार) कर सकता है।
  6. आपके मतदान अनुरोध की अगली प्रतिक्रिया में उपयोगकर्ता की ओर से अनुरोधों को अधिकृत करने के लिए आपके ऐप के टोकन की आवश्यकता है। (यदि उपयोगकर्ता ने आपके एप्लिकेशन तक पहुंच से इनकार कर दिया, तो प्रतिक्रिया में टोकन नहीं हैं।)

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

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

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

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

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

मापदंडों
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

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

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

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

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

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

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

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

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

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

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

चरण 4: पोल Google का प्राधिकरण सर्वर

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

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

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

मापदंडों
client_id आपके आवेदन के लिए क्लाइंट आईडी। आप इस मान को API Console Credentials page में पा सकते हैं।
client_secret क्लाइंट प्रदान किए गए client_id लिए गुप्त है। आप इस मान को API Console Credentials page में पा सकते हैं।
device_code device_code प्राधिकरण सर्वर द्वारा चरण 2 में वापस आ गया।
grant_type इस मान को urn:ietf:params:oauth:grant-type:device_code

उदाहरण

निम्नलिखित स्निपेट एक नमूना अनुरोध दिखाता है:

0a77c00

यह उदाहरण समान अनुरोध भेजने के लिए 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: उपयोगकर्ता अनुरोध का उपयोग करने के लिए प्रतिक्रिया करता है

निम्न छवि एक पृष्ठ दिखाती है, जो उपयोगकर्ताओं द्वारा चरण 3 में दिखाए गए verification_url url पर जाने पर उपयोगकर्ता देखते हैं।

एक कोड दर्ज करके एक उपकरण कनेक्ट करें

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

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

चरण 6: मतदान अनुरोधों की प्रतिक्रियाएं संभालें

Google का प्राधिकरण सर्वर प्रत्येक मतदान अनुरोध का जवाब निम्नलिखित में से किसी एक प्रतिक्रिया के साथ देता है:

प्रवेश करने की अनुमति है

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

इस स्थिति में, API प्रतिक्रिया में निम्नलिखित फ़ील्ड शामिल हैं:

खेत
access_token Google API अनुरोध को अधिकृत करने के लिए आपके द्वारा भेजा गया टोकन।
expires_in सेकंड में एक्सेस टोकन का शेष जीवनकाल।
refresh_token एक टोकन जिसे आप एक नया एक्सेस टोकन प्राप्त करने के लिए उपयोग कर सकते हैं। ताज़ा टोकन तब तक मान्य हैं जब तक उपयोगकर्ता पहुँच को रद्द नहीं करता। ध्यान दें कि ताज़ा टोकन हमेशा उपकरणों के लिए लौटाए जाते हैं।
scope access_token द्वारा दी गई पहुंच के 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"
}
है

एक्सेस टोकन का जीवनकाल सीमित होता है। यदि आपके एप्लिकेशन को लंबे समय तक API तक पहुंचने की आवश्यकता है, तो यह नए एक्सेस टोकन प्राप्त करने के लिए रिफ्रेश टोकन का उपयोग कर सकता है। यदि आपके एप्लिकेशन को इस प्रकार की पहुंच की आवश्यकता है, तो इसे बाद में उपयोग के लिए ताज़ा टोकन स्टोर करना चाहिए।

पहुंच अस्वीकृत

यदि उपयोगकर्ता डिवाइस तक पहुंच देने से इनकार करता है, तो सर्वर प्रतिक्रिया में 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 के लिए अपनी कॉल सेट करने के लिए क्लाइंट लाइब्रेरी का उपयोग कर सकते हैं (उदाहरण के लिए, ड्राइव फाइल एपीआई को कॉल करते समय)।

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

HTTP GET के उदाहरण हैं

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

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

यहाँ access_token क्वेरी स्ट्रिंग पैरामीटर का उपयोग करके प्रमाणित उपयोगकर्ता के लिए उसी API के लिए एक कॉल है:

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

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

0a195cbb0

एक पहुंच टोकन को ताज़ा करना

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

एक्सेस टोकन को रीफ्रेश करने के लिए, आपका एप्लिकेशन 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"
}

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

टोकन जारी करना

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

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

प्रोग्राम को टोकन को रद्द करने के लिए, आपका आवेदन 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 प्रवाह केवल निम्न स्कोप के लिए समर्थित है:

OpenID कनेक्ट , Google साइन-इन

  • email
  • openid
  • profile

एपीआई ड्राइव करें

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

YouTube एपीआई

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