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 प्रॉडक्ट की, जैसे कि Google Home या Google Assistant.
2. आपके पास Google से अनुमति लेने वाला स्टेटमेंट होना चाहिए, जैसे कि "साइन इन करने का मतलब है कि आपने Google को अपने डिवाइसों को कंट्रोल करने की अनुमति दी है." Google Home डेवलपर की नीतियों के लिए, Google के डिवाइस कंट्रोल करने की अनुमति देने वाला सेक्शन देखें.

सुझाव

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

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

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

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

4. सदस्यता रद्द करने की सुविधा. इसकी मदद से, उपयोगकर्ताओं को वापस आने या रद्द करने का तरीका दिया जा सकता है, अगर वे लिंक नहीं करना चाहते.

5. साइन इन करने की प्रोसेस हटाएं. पक्का करें कि उपयोगकर्ताओं के पास Google खाते में साइन इन करने के लिए, साफ़ तरीका हो. जैसे, उपयोगकर्ता नाम और पासवर्ड के लिए फ़ील्ड या Google से साइन इन करें.

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

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

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

8. अपना लोगो शामिल करें. सहमति वाली स्क्रीन पर अपनी कंपनी का लोगो दिखाएं. अपना लोगो डालने के लिए, स्टाइल से जुड़े दिशा-निर्देशों का इस्तेमाल करें. अगर आपको 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	ज़रूरी नहीं: उपयोगकर्ता की प्रोफ़ाइल फ़ोटो.