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

ज़रूरी शर्तें
- आपको यह बताना होगा कि उपयोगकर्ता का खाता Google से लिंक किया जाएगा. हालांकि, यह Google Home या Google Assistant जैसे किसी खास Google प्रॉडक्ट से नहीं लिंक किया जाएगा.
- आपके पास Google का अनुमति देने वाला स्टेटमेंट होना चाहिए. जैसे, "साइन इन करके, Google को अपने डिवाइसों को कंट्रोल करने की अनुमति दी जाती है." Google Home Developer Program की नीतियों में, Google डिवाइस कंट्रोल करने की अनुमति देने से जुड़ा सेक्शन देखें.
- आपको वेब OAuth लिंकिंग पेज खोलना होगा. साथ ही, यह पक्का करना होगा कि उपयोगकर्ताओं के पास अपने Google खाते में साइन इन करने का कोई आसान तरीका हो. जैसे, उनके उपयोगकर्ता नाम और पासवर्ड के लिए फ़ील्ड. Google से साइन इन करने (GSI) के ऐसे तरीके का इस्तेमाल न करें जिससे उपयोगकर्ताओं को वेब OAuth लिंकिंग पेज पर रीडायरेक्ट किए बिना, लिंक करने की सुविधा मिलती हो. यह Google की नीति का उल्लंघन है.
- OAuth लिंक करने वाले पेज पर, आपको इनमें से कम से कम एक आइटम शामिल करना होगा. इससे यह पता चलेगा कि उपयोगकर्ता किस इंटिग्रेशन को लिंक कर रहा है:
- कंपनी का लोगो
- कंपनी का नाम
- इंटीग्रेशन का नाम
- ऐप्लिकेशन का आइकॉन
सुझाव
हमारा सुझाव है कि आप ये काम करें:
Google की निजता नीति दिखाओ. सहमति वाली स्क्रीन पर, Google की निजता नीति का लिंक शामिल करें.
शेयर किया जाने वाला डेटा. उपयोगकर्ता को साफ़ तौर पर और कम शब्दों में बताएं कि Google को उसका कौनसा डेटा चाहिए और क्यों चाहिए.
कॉल-टू-ऐक्शन साफ़ तौर पर बताया गया हो. सहमति लेने के लिए दिखाई जाने वाली स्क्रीन पर, कॉल-टू-ऐक्शन साफ़ तौर पर बताएं. जैसे, “सहमति दें और लिंक करें.” ऐसा इसलिए, क्योंकि उपयोगकर्ताओं को यह पता होना चाहिए कि खातों को लिंक करने के लिए, उन्हें Google के साथ कौनसा डेटा शेयर करना होगा.
सदस्यता रद्द करने की सुविधा. अगर उपयोगकर्ता खाता लिंक नहीं करना चाहते हैं, तो उन्हें वापस जाने या अनुरोध रद्द करने का विकल्प दें.
साइन इन करने की आसान प्रोसेस. पक्का करें कि उपयोगकर्ताओं के पास अपने Google खाते में साइन इन करने का कोई आसान तरीका हो. जैसे, उनके उपयोगकर्ता नाम और पासवर्ड के लिए फ़ील्ड या Google से साइन इन करें.
अनलिंक करने की सुविधा. उपयोगकर्ताओं को खाता अनलिंक करने का तरीका उपलब्ध कराएं. जैसे, आपके प्लैटफ़ॉर्म पर खाता सेटिंग का यूआरएल. इसके अलावा, Google खाते का लिंक शामिल किया जा सकता है. इससे उपयोगकर्ता, लिंक किए गए खाते को मैनेज कर सकते हैं.
उपयोगकर्ता खाते को बदलने की सुविधा. उपयोगकर्ताओं को उनके खाते स्विच करने का तरीका सुझाएं. यह खास तौर पर तब फ़ायदेमंद होता है, जब उपयोगकर्ताओं के पास एक से ज़्यादा खाते हों.
- अगर किसी उपयोगकर्ता को खाते बदलने के लिए, सहमति वाली स्क्रीन बंद करनी पड़ती है, तो Google को ऐसी गड़बड़ी की जानकारी भेजें जिसे ठीक किया जा सकता हो. इससे उपयोगकर्ता, OAuth लिंकिंग का इस्तेमाल करके, अपने पसंदीदा खाते में साइन इन कर पाएगा.
अपना लोगो शामिल करें. सहमति वाली स्क्रीन पर, अपनी कंपनी का लोगो दिखाएं. लोगो को सही जगह पर रखने के लिए, स्टाइल से जुड़े दिशा-निर्देशों का इस्तेमाल करें. अगर आपको Google का लोगो भी दिखाना है, तो लोगो और ट्रेडमार्क देखें.

ऑथराइज़ेशन कोड का फ़्लो
OAuth 2.0 सर्वर के ऑथराइज़ेशन कोड फ़्लो को लागू करने के लिए, दो एंडपॉइंट की ज़रूरत होती है. आपकी सेवा, इन्हें HTTPS के ज़रिए उपलब्ध कराती है. पहला एंडपॉइंट, ऑथराइज़ेशन एंडपॉइंट है. यह डेटा ऐक्सेस करने के लिए, उपयोगकर्ताओं की सहमति लेने या सहमति का पता लगाने के लिए ज़िम्मेदार होता है. ऑथराइज़ेशन एंडपॉइंट, उन लोगों को साइन-इन यूज़र इंटरफ़ेस (यूआई) दिखाता है जिन्होंने पहले से साइन इन नहीं किया है. साथ ही, यह अनुरोध किए गए ऐक्सेस के लिए सहमति रिकॉर्ड करता है. दूसरा एंडपॉइंट, टोकन एक्सचेंज एंडपॉइंट होता है. इसका इस्तेमाल एन्क्रिप्ट (सुरक्षित) की गई स्ट्रिंग पाने के लिए किया जाता है. इन्हें टोकन कहा जाता है. ये टोकन, किसी उपयोगकर्ता को आपकी सेवा ऐक्सेस करने की अनुमति देते हैं.
जब किसी Google ऐप्लिकेशन को आपकी सेवा के किसी एपीआई को कॉल करने की ज़रूरत होती है, तो Google इन एंडपॉइंट का इस्तेमाल एक साथ करता है. इससे वह आपके उपयोगकर्ताओं से, उनकी ओर से इन एपीआई को कॉल करने की अनुमति ले पाता है.
Google की ओर से शुरू किए गए OAuth 2.0 ऑथराइज़ेशन कोड फ़्लो सेशन का फ़्लो इस तरह होता है:
- Google, उपयोगकर्ता के ब्राउज़र में आपका ऑथराइज़ेशन एंडपॉइंट खोलता है. अगर किसी कार्रवाई के लिए, सिर्फ़ आवाज़ से कंट्रोल होने वाले डिवाइस पर फ़्लो शुरू किया गया है, तो Google उस कार्रवाई को फ़ोन पर ट्रांसफ़र कर देता है.
- अगर उपयोगकर्ता ने पहले से साइन इन नहीं किया है, तो वह साइन इन करता है. इसके बाद, अगर उसने पहले से अनुमति नहीं दी है, तो वह Google को आपके एपीआई की मदद से अपना डेटा ऐक्सेस करने की अनुमति देता है.
- आपकी सेवा, ऑथराइज़ेशन कोड बनाती है और उसे Google को भेजती है. इसके लिए, उपयोगकर्ता के ब्राउज़र को वापस Google पर रीडायरेक्ट करें. साथ ही, अनुरोध से जुड़ा ऑथराइज़ेशन कोड अटैच करें.
- Google, ऑथराइज़ेशन कोड को आपके टोकन एक्सचेंज एंडपॉइंट पर भेजता है. यह कोड की पुष्टि करता है और ऐक्सेस टोकन और रीफ़्रेश टोकन दिखाता है. ऐक्सेस टोकन, कम समय तक चलने वाला टोकन होता है. आपकी सेवा, एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल के तौर पर इसे स्वीकार करती है. रिफ़्रेश टोकन, लंबे समय तक इस्तेमाल किया जा सकने वाला टोकन होता है. Google इसे सेव कर सकता है और इसका इस्तेमाल, नए ऐक्सेस टोकन पाने के लिए कर सकता है. ऐसा तब किया जाता है, जब ऐक्सेस टोकन की समयसीमा खत्म हो जाती है.
- उपयोगकर्ता के खाता लिंक करने की प्रोसेस पूरी करने के बाद, Google से भेजे गए हर अनुरोध में ऐक्सेस टोकन शामिल होता है.
ऐक्सेस के अनुरोध मैनेज करना
जब आपको OAuth 2.0 ऑथराइज़ेशन कोड फ़्लो का इस्तेमाल करके खाता लिंक करना होता है, तो Google उपयोगकर्ता को आपके ऑथराइज़ेशन एंडपॉइंट पर भेजता है. इस अनुरोध में ये पैरामीटर शामिल होते हैं:
ऑथराइज़ेशन एंडपॉइंट के पैरामीटर | |
---|---|
client_id |
Google को असाइन किया गया क्लाइंट आईडी. |
redirect_uri |
वह यूआरएल जिस पर आपको इस अनुरोध का जवाब भेजना है. |
state |
यह हिसाब-किताब की ऐसी वैल्यू होती है जिसे रीडायरेक्ट यूआरआई में बिना बदलाव किए, Google को वापस भेज दिया जाता है. |
scope |
ज़रूरी नहीं: यह स्पेस से अलग किया गया स्कोप स्ट्रिंग का एक सेट होता है. इससे यह पता चलता है कि Google किस डेटा के लिए अनुमति मांग रहा है. |
response_type |
जवाब में किस तरह की वैल्यू दिखानी है. OAuth 2.0 के ऑथराइज़ेशन कोड फ़्लो के लिए, रिस्पॉन्स टाइप हमेशा code होता है.
|
उदाहरण के लिए, अगर आपका ऑथराइज़ेशन एंडपॉइंट https://myservice.example.com/auth
पर उपलब्ध है, तो अनुरोध कुछ ऐसा दिख सकता है:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code
साइन इन करने के अनुरोधों को मैनेज करने के लिए, अनुमति देने वाले एंडपॉइंट के लिए यह तरीका अपनाएं:
- पुष्टि करें कि
client_id
, Google को असाइन किए गए क्लाइंट आईडी से मेल खाता हो. साथ ही, यह भी पुष्टि करें किredirect_uri
, Google की ओर से आपकी सेवा के लिए दिए गए रीडायरेक्ट यूआरएल से मेल खाता हो. ये जांच इसलिए ज़रूरी हैं, ताकि अनचाहे या गलत तरीके से कॉन्फ़िगर किए गए क्लाइंट ऐप्लिकेशन को ऐक्सेस न दिया जाए. अगर आपने एक से ज़्यादा OAuth 2.0 फ़्लो इस्तेमाल किए हैं, तो यह भी पक्का करें किresponse_type
code
हो. - यह कुकी यह पता लगाती है कि उपयोगकर्ता ने आपकी सेवा में साइन इन किया है या नहीं. अगर उपयोगकर्ता ने साइन इन नहीं किया है, तो अपनी सेवा के लिए साइन इन या साइन अप करने की प्रोसेस पूरी करें.
- Google के लिए एक अनुमति कोड जनरेट करें, ताकि वह आपके एपीआई को ऐक्सेस कर सके. अनुमति देने वाला कोड, स्ट्रिंग वैल्यू हो सकता है. हालांकि, यह कोड उपयोगकर्ता, टोकन का इस्तेमाल करने वाले क्लाइंट, और कोड के खत्म होने के समय के बारे में यूनीक जानकारी देता हो. साथ ही, इसका अनुमान नहीं लगाया जा सकता हो. आम तौर पर, आपको अनुमति देने वाले कोड जारी करने होते हैं. ये कोड करीब 10 मिनट बाद काम नहीं करते.
- पुष्टि करें कि
redirect_uri
पैरामीटर से तय किए गए यूआरएल का फ़ॉर्मैट यह है:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- उपयोगकर्ता के ब्राउज़र को
redirect_uri
पैरामीटर से तय किए गए यूआरएल पर रीडायरेक्ट करें.code
औरstate
पैरामीटर जोड़कर रीडायरेक्ट करते समय, अभी जनरेट किया गया अनुमति कोड और बिना बदलाव वाली ओरिजनल स्थिति की वैल्यू शामिल करें. यहां नतीजे के तौर पर मिले यूआरएल का एक उदाहरण दिया गया है:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
टोकन एक्सचेंज करने के अनुरोधों को मैनेज करना
आपकी सेवा का टोकन एक्सचेंज एंडपॉइंट, दो तरह के टोकन एक्सचेंज के लिए ज़िम्मेदार होता है:
- ऐक्सेस टोकन और रीफ़्रेश टोकन के लिए ऑथराइज़ेशन कोड बदलना
- रीफ़्रेश टोकन के बदले ऐक्सेस टोकन पाना
टोकन एक्सचेंज के अनुरोधों में ये पैरामीटर शामिल होते हैं:
टोकन एक्सचेंज एंडपॉइंट के पैरामीटर | |
---|---|
client_id |
यह स्ट्रिंग, अनुरोध के सोर्स की पहचान Google के तौर पर करती है. इस स्ट्रिंग को आपके सिस्टम में, Google के यूनीक आइडेंटिफ़ायर के तौर पर रजिस्टर किया जाना चाहिए. |
client_secret |
ऐसी सीक्रेट स्ट्रिंग जिसे आपने अपनी सेवा के लिए, Google के साथ रजिस्टर किया है. |
grant_type |
एक्सचेंज किया जा रहा टोकन किस तरह का है. यह authorization_code या refresh_token में से कोई एक हो सकता है. |
code |
जब grant_type=authorization_code होता है, तब यह पैरामीटर वह कोड होता है जो Google को आपके साइन-इन या टोकन एक्सचेंज एंडपॉइंट से मिला होता है. |
redirect_uri |
जब grant_type=authorization_code हो, तब यह पैरामीटर, अनुमति के शुरुआती अनुरोध में इस्तेमाल किया गया यूआरएल होता है. |
refresh_token |
grant_type=refresh_token होने पर, यह पैरामीटर वह रीफ़्रेश टोकन होता है जो Google को आपके टोकन एक्सचेंज एंडपॉइंट से मिला था. |
कॉन्फ़िगर करें कि Google, आपके सर्वर पर क्रेडेंशियल कैसे भेजता है
इसे लागू करने के तरीके के आधार पर, आपका अनुमति देने वाला सर्वर, अनुरोध के मुख्य हिस्से या अनुरोध के हेडर में क्लाइंट क्रेडेंशियल पाने की उम्मीद करता है.
डिफ़ॉल्ट रूप से, Google अनुरोध के मुख्य हिस्से में क्रेडेंशियल भेजता है. अगर आपके अनुमति सर्वर को अनुरोध हेडर में क्लाइंट क्रेडेंशियल की ज़रूरत है, तो आपको अपने Cloud-to-cloud इंटिग्रेशन को इसके मुताबिक कॉन्फ़िगर करना होगा:
प्रोजेक्ट की सूची में, उस प्रोजेक्ट के बगल में मौजूद खोलें पर क्लिक करें जिस पर आपको काम करना है.
क्लाउड-टू-क्लाउड में जाकर, डेवलप करें चुनें.
अपने इंटिग्रेशन के बगल में मौजूद, खोलें पर क्लिक करें.
नीचे स्क्रोल करके अनुमतियां (ज़रूरी नहीं) सेक्शन पर जाएं. इसके बाद, Google को एचटीटीपी बेसिक ऑथ हेडर के ज़रिए Client-ID और सीक्रेट ट्रांसमिट करने की अनुमति दें चेकबॉक्स को चुनें.
अपने बदलावों को सेव करने के लिए, सेव करें पर क्लिक करें.
ऐक्सेस टोकन और रीफ़्रेश टोकन के लिए ऑथराइज़ेशन कोड बदलना
जब उपयोगकर्ता साइन इन कर लेता है और आपका ऑथराइज़ेशन एंडपॉइंट, Google को कुछ समय के लिए इस्तेमाल किया जा सकने वाला ऑथराइज़ेशन कोड भेज देता है, तब Google आपके टोकन एक्सचेंज एंडपॉइंट को एक अनुरोध भेजता है. इस अनुरोध में, ऑथराइज़ेशन कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन के बदले एक्सचेंज करने के लिए कहा जाता है.
इन अनुरोधों के लिए, grant_type
की वैल्यू authorization_code
होती है. साथ ही, code
की वैल्यू, ऑथराइज़ेशन कोड की वह वैल्यू होती है जिसे आपने पहले Google को दिया था. यहां ऑथराइज़ेशन कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन से बदलने के अनुरोध का उदाहरण दिया गया है:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI
ऑथराइज़ेशन कोड के बदले ऐक्सेस टोकन और रीफ़्रेश टोकन पाने के लिए, आपका टोकन एक्सचेंज एंडपॉइंट, POST
अनुरोधों का जवाब देता है. इसके लिए, वह यह तरीका अपनाता है:
- पुष्टि करें कि
client_id
, अनुरोध के ऑरिजिन को अनुमति वाले ऑरिजिन के तौर पर पहचानता हो. साथ ही,client_secret
की वैल्यू, अनुमानित वैल्यू से मेल खाती हो. - पुष्टि करें कि ऑथराइज़ेशन कोड मान्य हो और उसकी समयसीमा खत्म न हुई हो. साथ ही, अनुरोध में दिया गया क्लाइंट आईडी, ऑथराइज़ेशन कोड से जुड़े क्लाइंट आईडी से मेल खाता हो.
- पुष्टि करें कि
redirect_uri
पैरामीटर से तय किया गया यूआरएल, पुष्टि के शुरुआती अनुरोध में इस्तेमाल की गई वैल्यू के जैसा ही है. - अगर ऊपर दी गई सभी शर्तों की पुष्टि नहीं की जा सकती, तो एचटीटीपी 400 अमान्य अनुरोध वाली गड़बड़ी दिखाएं. साथ ही, मुख्य हिस्से के तौर पर
{"error": "invalid_grant"}
दिखाएं. - इसके अलावा, ऑथराइज़ेशन कोड से मिले उपयोगकर्ता आईडी का इस्तेमाल करके, रीफ़्रेश टोकन और ऐक्सेस टोकन जनरेट करें. ये टोकन, स्ट्रिंग वैल्यू हो सकते हैं. हालांकि, ये टोकन उस उपयोगकर्ता और क्लाइंट को खास तौर पर दिखाने चाहिए जिसके लिए टोकन बनाया गया है. साथ ही, ये टोकन ऐसे होने चाहिए जिनका अनुमान न लगाया जा सके. ऐक्सेस टोकन के लिए, टोकन के खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी करने के एक घंटे बाद यह समय खत्म हो जाता है. रीफ़्रेश टोकन की समयसीमा खत्म नहीं होती.
- एचटीटीपीएस रिस्पॉन्स के मुख्य हिस्से में, यह JSON ऑब्जेक्ट दिखाएं:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "refresh_token": "REFRESH_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
Google, उपयोगकर्ता के लिए ऐक्सेस टोकन और रीफ़्रेश टोकन को सेव करता है. साथ ही, ऐक्सेस टोकन के खत्म होने की तारीख को रिकॉर्ड करता है. ऐक्सेस टोकन की समयसीमा खत्म होने पर, Google आपके टोकन एक्सचेंज एंडपॉइंट से नया ऐक्सेस टोकन पाने के लिए, रिफ़्रेश टोकन का इस्तेमाल करता है.
रीफ़्रेश टोकन के बदले ऐक्सेस टोकन पाना
जब ऐक्सेस टोकन की समयसीमा खत्म हो जाती है, तो Google आपके टोकन एक्सचेंज एंडपॉइंट को एक अनुरोध भेजता है. इस अनुरोध में, रीफ़्रेश टोकन को नए ऐक्सेस टोकन से बदलने के लिए कहा जाता है.
इन अनुरोधों के लिए, grant_type
की वैल्यू refresh_token
होती है. साथ ही, refresh_token
की वैल्यू, उस रीफ़्रेश टोकन की वैल्यू होती है जिसे आपने पहले Google को दिया था. यहां रीफ़्रेश टोकन को ऐक्सेस टोकन से बदलने के अनुरोध का एक उदाहरण दिया गया है:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
रीफ़्रेश टोकन को ऐक्सेस टोकन से बदलने के लिए, टोकन एक्सचेंज एंडपॉइंट, POST
अनुरोधों का जवाब देता है. इसके लिए, वह यह तरीका अपनाता है:
- पुष्टि करें कि
client_id
से, अनुरोध के सोर्स के तौर पर Google की पहचान होती हो. साथ ही, यह भी पुष्टि करें किclient_secret
की वैल्यू, उम्मीद के मुताबिक हो. - पुष्टि करें कि रीफ़्रेश टोकन मान्य है और अनुरोध में दिया गया क्लाइंट आईडी, रीफ़्रेश टोकन से जुड़े क्लाइंट आईडी से मेल खाता है.
- अगर ऊपर दी गई सभी शर्तों की पुष्टि नहीं की जा सकती, तो एचटीटीपी 400
खराब अनुरोध वाली गड़बड़ी दिखाएं. साथ ही, मुख्य हिस्से के तौर पर
{"error": "invalid_grant"}
दिखाएं. - अगर ऐसा नहीं है, तो ऐक्सेस टोकन जनरेट करने के लिए, रीफ़्रेश टोकन से मिले उपयोगकर्ता आईडी का इस्तेमाल करें. ये टोकन, स्ट्रिंग वैल्यू हो सकते हैं. हालांकि, ये उस उपयोगकर्ता और क्लाइंट को खास तौर पर दिखाने चाहिए जिसके लिए टोकन बनाया गया है. साथ ही, इनका अनुमान नहीं लगाया जा सकता. ऐक्सेस टोकन के लिए, टोकन के खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी करने के एक घंटे बाद यह समय खत्म हो जाता है.
- HTTPS रिस्पॉन्स के मुख्य हिस्से में, यहां दिया गया JSON ऑब्जेक्ट दिखाएं:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
उपयोगकर्ता की जानकारी के अनुरोधों को मैनेज करना
userinfo एंडपॉइंट, OAuth 2.0 से सुरक्षित किया गया एक ऐसा संसाधन है जो लिंक किए गए उपयोगकर्ता के बारे में दावे दिखाता है. नीचे दिए गए इस्तेमाल के उदाहरणों को छोड़कर, userinfo एंडपॉइंट को लागू और होस्ट करना ज़रूरी नहीं है:
- Google One Tap की मदद से, लिंक किए गए खाते में साइन इन करें.
- AndroidTV पर बिना किसी रुकावट के सदस्यता.
आपके टोकन एंडपॉइंट से ऐक्सेस टोकन पाने के बाद, Google आपके userinfo एंडपॉइंट पर एक अनुरोध भेजता है, ताकि लिंक किए गए उपयोगकर्ता की प्रोफ़ाइल की बुनियादी जानकारी फिर से मिल सके.
userinfo एंडपॉइंट अनुरोध के हेडर | |
---|---|
Authorization header |
बेयरर टाइप का ऐक्सेस टोकन. |
उदाहरण के लिए, अगर आपका userinfo एंडपॉइंट यहां उपलब्ध है
https://myservice.example.com/userinfo
, अनुरोध कुछ ऐसा दिख सकता है:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
अपने userinfo एंडपॉइंट पर अनुरोधों को मैनेज करने के लिए यह तरीका अपनाएं:
- ऑथराइज़ेशन हेडर से ऐक्सेस टोकन निकालें और ऐक्सेस टोकन से जुड़े उपयोगकर्ता की जानकारी दिखाएं.
- अगर ऐक्सेस टोकन अमान्य है, तो
WWW-Authenticate
रिस्पॉन्स हेडर का इस्तेमाल करके, एचटीटीपी 401 बिना अनुमति वाली गड़बड़ी दिखाएं. नीचे userinfo गड़बड़ी के जवाब का एक उदाहरण दिया गया है: अगर लिंक करने की प्रोसेस के दौरान, बिना अनुमति वाली 401 या गड़बड़ी वाला कोई भी गड़बड़ी का मैसेज मिलता है, तो इस गड़बड़ी को ठीक नहीं किया जा सकेगा. साथ ही, वापस मिले टोकन को खारिज कर दिया जाएगा और उपयोगकर्ता को फिर से लिंक करने की प्रोसेस शुरू करनी होगी.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
अगर ऐक्सेस टोकन मान्य है, तो वापस जाएं और एचटीटीपीएस के मुख्य हिस्से में, यहां दिए गए JSON ऑब्जेक्ट के साथ एचटीटीपी 200 रिस्पॉन्स भेजें जवाब:
अगर आपका userinfo एंडपॉइंट, एचटीटीपी 200 सक्सेस रिस्पॉन्स देता है, तो हासिल किए गए टोकन और दावे, उपयोगकर्ता के Google खाते से रजिस्टर किए जाते हैं.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }
userinfo एंडपॉइंट रिस्पॉन्स sub
एक यूनीक आईडी, जो आपके सिस्टम में उपयोगकर्ता की पहचान करता है. email
उपयोगकर्ता का ईमेल पता. given_name
ज़रूरी नहीं: उपयोगकर्ता का नाम. family_name
ज़रूरी नहीं: उपयोगकर्ता का सरनेम. name
ज़रूरी नहीं: उपयोगकर्ता का पूरा नाम. picture
ज़रूरी नहीं: उपयोगकर्ता की प्रोफ़ाइल फ़ोटो.