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

हर Cloud-to-cloud इंटिग्रेशन में, उपयोगकर्ताओं की पुष्टि करने का तरीका शामिल होना चाहिए.

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

इस पेज पर, OAuth 2.0 सर्वर को सेट अप करने का तरीका बताया गया है, ताकि यह आपके Cloud-to-cloud इंटिग्रेशन के साथ काम कर सके.

OAuth की मदद से Google खाते को किसी दूसरे खाते से लिंक करने की सुविधा

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

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

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

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

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

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

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

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

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

सुझाव

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

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

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

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

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

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

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

  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 होता है.

उदाहरण के लिए, अगर आपका ऑथराइज़ेशन एंडपॉइंट 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

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

  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 अनुरोध के मुख्य हिस्से में क्रेडेंशियल भेजता है. अगर अनुमति देने वाले सर्वर को अनुरोध के हेडर में क्लाइंट क्रेडेंशियल की ज़रूरत है, तो आपको Cloud-to-cloud इंटिग्रेशन को इसके मुताबिक कॉन्फ़िगर करना होगा:

Developer Console पर जाएं

  1. प्रोजेक्ट की सूची में से, उस प्रोजेक्ट के बगल में मौजूद खोलें पर क्लिक करें जिस पर आपको काम करना है.

  2. क्लाउड-टू-क्लाउड में जाकर, डेवलप करें को चुनें.

  3. अपने इंटिग्रेशन के बगल में मौजूद, Open पर क्लिक करें.

  4. नीचे की ओर स्क्रोल करके, अनुमतियां (ज़रूरी नहीं) सेक्शन पर जाएं. इसके बाद, Google को एचटीटीपी बेसिक ऑथ हेडर की मदद से, क्लाइंट आईडी और सीक्रेट भेजने की अनुमति दें चेकबॉक्स को चुनें.

  5. अपने बदलावों को सेव करने के लिए, सेव करें पर क्लिक करें.

ऐक्सेस टोकन और रीफ़्रेश टोकन के लिए, ऑथराइज़ेशन कोड को एक्सचेंज करना

जब उपयोगकर्ता साइन इन कर लेता है और आपका ऑथराइज़ेशन एंडपॉइंट, 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. अगर ऊपर दी गई सभी शर्तों की पुष्टि नहीं की जा सकती, तो एचटीटीपी 400 Bad Request गड़बड़ी दिखाएं. साथ ही, बॉडी के तौर पर {"error": "invalid_grant"} दिखाएं.
  5. अगर ऐसा नहीं है, तो ऑथराइज़ेशन कोड से मिले यूज़र आईडी का इस्तेमाल करके, रीफ़्रेश टोकन और ऐक्सेस टोकन जनरेट करें. ये टोकन कोई भी स्ट्रिंग वैल्यू हो सकते हैं. हालांकि, ये टोकन उस उपयोगकर्ता और क्लाइंट को यूनीक तरीके से दिखाने चाहिए जिसके लिए टोकन है. साथ ही, इनका अनुमान नहीं लगाया जा सकता. ऐक्सेस टोकन के लिए, टोकन के खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी होने के एक घंटे बाद वह खत्म हो जाता है. रीफ़्रेश टोकन की समयसीमा खत्म नहीं होती.
  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. अगर ऊपर दी गई सभी शर्तों की पुष्टि नहीं की जा सकती, तो बॉडी के तौर पर {"error": "invalid_grant"} के साथ, एचटीटीपी 400 Bad Request गड़बड़ी दिखाएं.
  4. अगर ऐसा नहीं है, तो ऐक्सेस टोकन जनरेट करने के लिए, रीफ़्रेश टोकन से मिले यूज़र आईडी का इस्तेमाल करें. ये टोकन कोई भी स्ट्रिंग वैल्यू हो सकते हैं. हालांकि, ये टोकन यूनीक होने चाहिए और इनसे उपयोगकर्ता और क्लाइंट की पहचान की जा सके. साथ ही, इनका अनुमान लगाना आसान नहीं होना चाहिए. ऐक्सेस टोकन के लिए, टोकन की समयसीमा खत्म होने का समय भी रिकॉर्ड करें. आम तौर पर, टोकन जारी करने के एक घंटे बाद उसकी समयसीमा खत्म हो जाती है.
  5. एचटीटीपीएस रिस्पॉन्स के मुख्य हिस्से में, यह JSON ऑब्जेक्ट दिखाएं:
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }

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

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

आपके टोकन एंडपॉइंट से ऐक्सेस टोकन पाने के बाद, 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 एंडपॉइंट पर अनुरोधों को मैनेज करने के लिए यह तरीका अपनाएं:

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