इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

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

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

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

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

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

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

'ऑथराइज़ेशन हेडर' से ऐक्सेस टोकन और ऐक्सेस टोकन से जुड़े उपयोगकर्ता की रिटर्न की जानकारी पाएं.
अगर ऐक्सेस टोकन अमान्य है, तो WWW-Authenticate रिस्पॉन्स हेडर का इस्तेमाल करके, एचटीटीपी 401 वाली बिना अनुमति वाली गड़बड़ी दिखाएं. यहां उपयोगकर्ता जानकारी से जुड़ी गड़बड़ी के रिस्पॉन्स का एक उदाहरण दिया गया है:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
अगर लिंक करने की प्रोसेस के दौरान 401 बिना अनुमति वाला या कोई दूसरा गड़बड़ी वाला रिस्पॉन्स मिलता है, तो गड़बड़ी को वापस नहीं पाया जा सकेगा. साथ ही, वापस लाया गया टोकन खारिज कर दिया जाएगा और उपयोगकर्ता को फिर से लिंक करने की प्रोसेस शुरू करनी होगी.

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

पीछे जाएं

डेवलपर चेकलिस्ट

आगे बढ़ें

ऐक्शन प्रोजेक्ट बनाना