OAuth 2.0 सर्वर लागू करना

हर smart home कार्रवाई में उपयोगकर्ताओं की पुष्टि करने का एक तरीका शामिल होना चाहिए.

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

इस पेज पर, OAuth 2.0 सर्वर को सेट अप करने का तरीका बताया गया है, ताकि यह आपकी smart home कार्रवाई के साथ काम कर सके.

OAuth के साथ Google खाता लिंक करना

ऑथराइज़ेशन कोड फ़्लो में, आपको दो एंडपॉइंट की ज़रूरत होगी:

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

• टोकन एक्सचेंज एंडपॉइंट, जो दो तरह के एक्सचेंज के लिए ज़िम्मेदार है:

  1. लंबे समय तक चलने वाले रीफ़्रेश टोकन और कम समय तक चलने वाले ऐक्सेस टोकन के लिए, ऑथराइज़ेशन कोड को एक्सचेंज करता है. यह बातचीत तब होती है, जब उपयोगकर्ता खाता जोड़ने के फ़्लो से गुज़रता है.
  2. यह लंबे समय तक चलने वाले रीफ़्रेश टोकन को कम समय के लिए इस्तेमाल होने वाले ऐक्सेस टोकन के लिए एक्सचेंज करता है. यह एक्सचेंज तब होता है, जब Google को नए ऐक्सेस टोकन की ज़रूरत होती है, क्योंकि टोकन की समयसीमा खत्म हो चुकी होती है.

डिज़ाइन से जुड़े दिशा-निर्देश

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

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

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

सुझाव

हमारा सुझाव है कि आप ये काम करें:

1. Google की निजता नीति दिखाएं. सहमति वाली स्क्रीन पर Google की निजता नीति का लिंक शामिल करें.

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

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

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

5. उपयोगकर्ता का खाता बदलने की सुविधा. उपयोगकर्ताओं को अपना खाता(खाते) बदलने का तरीका बताएं. यह खास तौर पर तब फ़ायदेमंद होता है, जब उपयोगकर्ताओं के पास कई खाते होते हों.

   • अगर किसी उपयोगकर्ता को एक खाते से दूसरे खाते पर जाने के लिए, सहमति वाली स्क्रीन बंद करनी पड़ती है, तो Google को ऐसी गड़बड़ी की जानकारी भेजें जिसे ठीक किया जा सकता है. ऐसा इसलिए, ताकि उपयोगकर्ता OAuth लिंकिंग की मदद से, अपने मनचाहे खाते में साइन इन कर सके.

6. अपना लोगो शामिल करें. सहमति वाली स्क्रीन पर अपनी कंपनी का लोगो दिखाएं. अपना लोगो लगाने के लिए, अपनी स्टाइल से जुड़े दिशा-निर्देशों का पालन करें. अगर आपको Google का लोगो भी दिखाना है, तो लोगो और ट्रेडमार्क देखें.

ऑथराइज़ेशन कोड का फ़्लो

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

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

Google के शुरू किए गए OAuth 2.0 के ऑथराइज़ेशन कोड फ़्लो सेशन में ये फ़्लो होते हैं:

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

अनुमति के लिए अनुरोध मैनेज करना

जब आपको OAuth 2.0 के ऑथराइज़ेशन कोड फ़्लो का इस्तेमाल करके, खाता जोड़ने की प्रोसेस पूरी करनी होती है, तो Google इस अनुरोध के साथ उपयोगकर्ता को आपके ऑथराइज़ेशन एंडपॉइंट पर भेजता है. अनुरोध में ये पैरामीटर शामिल होते हैं:

ऑथराइज़ेशन एंडपॉइंट पैरामीटर
client_id	वह क्लाइंट आईडी जो आपने Google को असाइन किया है.
redirect_uri	वह यूआरएल जिस पर आप इस अनुरोध का जवाब भेजेंगे.
state	हिसाब-किताब की वह वैल्यू जो रीडायरेक्ट यूआरआई में बिना किसी बदलाव के Google को वापस भेज दी जाती है.
scope	ज़रूरी नहीं: दायरे की स्ट्रिंग का सेट, जो अलग-अलग डेटा स्ट्रिंग का इस्तेमाल करके, यह तय करता है कि Google किस डेटा के लिए अनुमति देने का अनुरोध कर रहा है.
response_type	जवाब में मिलने वाली वैल्यू किस तरह की है. OAuth 2.0 के ऑथराइज़ेशन कोड फ़्लो के लिए, रिस्पॉन्स टाइप हमेशा code होता है.
user_locale	Google खाते की भाषा की सेटिंग आरएफ़सी5646 फ़ॉर्मैट में इस्तेमाल की जाती है. इसकी मदद से, उपयोगकर्ता के पसंदीदा कॉन्टेंट को स्थानीय भाषा में लिखा जाता है.

उदाहरण के लिए, अगर आपका अनुमति देने वाला एंडपॉइंट 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&user_locale=LOCALE

साइन इन के अनुरोधों को मैनेज करने के लिए, अपने ऑथराइज़ेशन एंडपॉइंट के लिए यह तरीका अपनाएं:

1. पुष्टि करें कि client_id, Google को असाइन किए गए क्लाइंट आईडी से मेल खाता है. साथ ही, यह redirect_uri उस रीडायरेक्ट यूआरएल से मेल खाता है जो Google ने आपको अपनी सेवा के लिए दिया है. इन जांचों से, अनचाहे या गलत कॉन्फ़िगर किए गए क्लाइंट ऐप्लिकेशन को ऐक्सेस देने से बचा जा सकता है. अगर आप एक से ज़्यादा OAuth 2.0 फ़्लो की सुविधा देते हैं, तो यह भी पुष्टि करें कि response_type code है.
2. यह देखें कि उपयोगकर्ता ने आपकी सेवा में साइन इन किया है या नहीं. अगर उपयोगकर्ता साइन इन नहीं है, तो अपनी सेवा और साइन इन करने की प्रोसेस पूरी करें.
3. Google को एपीआई ऐक्सेस करने के लिए अनुमति देने वाला कोड जनरेट करें. ऑथराइज़ेशन कोड कोई भी स्ट्रिंग वैल्यू हो सकती है, लेकिन इसे उपयोगकर्ता को खास तौर पर दिखाना चाहिए, टोकन किस क्लाइंट का है, और कोड की समयसीमा खत्म होने का समय होना चाहिए. साथ ही, इसे अनुमान नहीं लगाया जा सकता. आम तौर पर, ऑथराइज़ेशन कोड जारी किए जाते हैं, जिनकी समयसीमा करीब 10 मिनट बाद खत्म हो जाती है.
4. पुष्टि करें कि redirect_uri पैरामीटर के बारे में दिए गए यूआरएल में यह फ़ॉर्म हो:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. उपयोगकर्ता के ब्राउज़र को उस यूआरएल पर रीडायरेक्ट करें जो 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 आपके टोकन एक्सचेंज एंडपॉइंट को ऐक्सेस कोड के लिए ऐक्सेस टोकन मांगता है. यह टोकन, रीफ़्रेश टोकन के लिए भेजा जाता है.

इन अनुरोधों के लिए, 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 अनुरोधों का जवाब नीचे दिए गए तरीकों से देता है:

1. पुष्टि करें कि client_id, अनुरोध किए गए ऑरिजिन की पहचान अनुमति वाले ऑरिजिन के तौर पर करता है और client_secret अनुमानित वैल्यू से मेल खाता है.
2. पुष्टि करें कि ऑथराइज़ेशन कोड मान्य है और उसकी समयसीमा खत्म नहीं हुई है. साथ ही, यह भी देखें कि अनुरोध में दिया गया क्लाइंट आईडी, ऑथराइज़ेशन कोड से जुड़े क्लाइंट आईडी से मेल खाता हो या नहीं.
3. पुष्टि करें कि redirect_uri पैरामीटर के लिए दिया गया यूआरएल, अनुमति के शुरुआती अनुरोध में इस्तेमाल किए गए यूआरएल जैसा ही है.
4. अगर आप ऊपर दिए गए सभी मानदंडों की पुष्टि नहीं कर पाते हैं, तो {"error": "invalid_grant"} के मुख्य भाग के तौर पर, एचटीटीपी 400 खराब अनुरोध की गड़बड़ी दिखाएं.
5. नहीं तो, एक रीफ़्रेश टोकन और एक ऐक्सेस टोकन जनरेट करने के लिए ऑथराइज़ेशन कोड में दिए गए User-ID का इस्तेमाल करें. ये टोकन कोई भी स्ट्रिंग वैल्यू हो सकते हैं, लेकिन ये उपयोगकर्ता और उसके टोकन के लिए अलग से होने चाहिए और इनका अनुमान नहीं लगाया जा सकता. ऐक्सेस टोकन के लिए, टोकन की समयसीमा खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी करने के एक घंटे बाद ऐसा किया जाता है. रीफ़्रेश टोकन की अवधि खत्म नहीं होती.
6. एचटीटीपीएस के रिस्पॉन्स के मुख्य हिस्से में, यह 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 के अनुरोधों का पालन करता है. इसके लिए वह यह तरीका अपनाता है:

1. पुष्टि करें कि client_id, अनुरोध किए गए ऑरिजिन की पहचान Google के तौर पर करता है और client_secret उसकी अनुमानित वैल्यू से मेल खाता है.
2. पुष्टि करें कि रीफ़्रेश टोकन मान्य है. साथ ही, यह भी देखें कि अनुरोध में बताया गया क्लाइंट आईडी, रीफ़्रेश टोकन से जुड़े क्लाइंट आईडी से मेल खाता हो या नहीं.
3. अगर ऊपर दी गई सभी शर्तों की पुष्टि नहीं की जा सकती, तो एचटीटीपी 400 में गड़बड़ी की गड़बड़ी दिखाएं. मुख्य गड़बड़ी के तौर पर, {"error": "invalid_grant"} की गड़बड़ी का अनुरोध करें.
4. नहीं तो, ऐक्सेस टोकन जनरेट करने के लिए रीफ़्रेश टोकन से User-ID का इस्तेमाल करें. ये टोकन कोई भी स्ट्रिंग वैल्यू हो सकते हैं, लेकिन उन्हें खास तौर पर उपयोगकर्ता की जानकारी के साथ-साथ, उस क्लाइंट के बारे में बताना चाहिए जिसके लिए टोकन है. ऐक्सेस टोकन के लिए, टोकन की समयसीमा खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी करने के एक घंटे बाद.
5. एचटीटीपीएस रिस्पॉन्स में मुख्य हिस्से में यह JSON ऑब्जेक्ट दिखाएं:

   {
   "token_type":: "Bearer"
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

देखें

उपयोगकर्ता की जानकारी के अनुरोधों को मैनेज करना

userinfo एंडपॉइंट, OAuth 2.0 सुरक्षित संसाधन है. यह लिंक किए गए उपयोगकर्ता के बारे में दावे करता है. यहां दिए गए इस्तेमाल के उदाहरणों को छोड़कर, उपयोगकर्ता जानकारी एंडपॉइंट को लागू और होस्ट करना ज़रूरी नहीं है:

• Google One टैप से लिंक किए गए खाते से साइन-इन करें.
• AndroidTV पर बिना किसी रुकावट के सदस्यता.

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

userinfo एंडपॉइंट अनुरोध हेडर
Authorization header	Bearer प्रकार का ऐक्सेस टोकन.

उदाहरण के लिए, अगर आपका उपयोगकर्ता जानकारी एंडपॉइंट https://myservice.example.com/userinfo पर उपलब्ध है, तो अनुरोध ऐसा दिख सकता है:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

अगर आप चाहते हैं कि आपके उपयोगकर्ता के जानकारी वाले एंडपॉइंट के अनुरोध हैंडल किए जाएं, तो यह तरीका अपनाएं:

1. 'ऑथराइज़ेशन हेडर' से ऐक्सेस टोकन और ऐक्सेस टोकन से जुड़े उपयोगकर्ता की रिटर्न की जानकारी पाएं.
2. अगर ऐक्सेस टोकन अमान्य है, तो WWW-Authenticate रिस्पॉन्स हेडर का इस्तेमाल करके, एचटीटीपी 401 वाली बिना अनुमति वाली गड़बड़ी दिखाएं. यहां उपयोगकर्ता जानकारी से जुड़ी गड़बड़ी के रिस्पॉन्स का एक उदाहरण दिया गया है:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

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

3. अगर ऐक्सेस टोकन मान्य है, तो एचटीटीपीएस के रिस्पॉन्स में नीचे दिए गए JSON ऑब्जेक्ट के साथ एचटीटीपी 200 रिस्पॉन्स दिखाया जाता है:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }
   

   अगर आपका userinfo एंडपॉइंट एक एचटीटीपी 200 का रिस्पॉन्स देता है, तो वापस लाया गया टोकन और दावे, उपयोगकर्ता के Google खाते के साथ रजिस्टर किए जाते हैं.

   userinfo एंडपॉइंट का जवाब
   sub	एक यूनीक आईडी, जिससे आपके सिस्टम में उपयोगकर्ता की पहचान होती है.
   email	उपयोगकर्ता का ईमेल पता.
   given_name	ज़रूरी नहीं: उपयोगकर्ता का नाम.
   family_name	ज़रूरी नहीं: उपयोगकर्ता का उपनाम.
   name	ज़रूरी नहीं: उपयोगकर्ता का पूरा नाम.
   picture	ज़रूरी नहीं: उपयोगकर्ता की प्रोफ़ाइल फ़ोटो.