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

OpenID कनेक्ट

Google का OpenID Connect एंडपॉइंट, OpenID सर्टिफ़ाइड है.

Google के OAuth 2.0 एपीआई का इस्तेमाल, पुष्टि करने और अनुमति देने, दोनों कामों के लिए किया जा सकता है. इस दस्तावेज़ में, पुष्टि करने के लिए OAuth 2.0 के लागू होने के बारे में बताया गया है. यह OpenID Connect स्पेसिफ़िकेशन के मुताबिक है और OpenID सर्टिफ़ाइड है. Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना में मौजूद दस्तावेज़, इस सेवा पर भी लागू होते हैं. अगर आपको इस प्रोटोकॉल को इंटरैक्टिव तरीके से एक्सप्लोर करना है, तो हमारा सुझाव है कि आप Google OAuth 2.0 Playground का इस्तेमाल करें. Stack Overflow पर मदद पाने के लिए, अपने सवालों को 'google-oauth' से टैग करें.

ध्यान दें: अपनी वेबसाइट पर "Google से साइन इन करें" बटन जोड़ने के लिए, Google Identity Services का इस्तेमाल करें. यह OpenID Connect प्रोटोकॉल पर बनाई गई, हमारी साइन इन क्लाइंट लाइब्रेरी है. यह लाइब्रेरी, OpenID Connect फ़ॉर्मैट में आईडी टोकन उपलब्ध कराती है. 'Google से साइन इन करें' फ़्लो को लागू करने के लिए, नेटिव Android ऐप्लिकेशन को क्रेडेंशियल मैनेजर एपीआई का इस्तेमाल करना चाहिए.

OAuth 2.0 सेट अप करना

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

OAuth 2.0 क्रेडेंशियल पाना

उपयोगकर्ताओं की पुष्टि करने और Google के एपीआई का ऐक्सेस पाने के लिए, आपके पास OAuth 2.0 क्रेडेंशियल होने चाहिए. इनमें क्लाइंट आईडी और क्लाइंट सीक्रेट शामिल हैं.

要查看给定OAuth 2.0凭据的客户端ID和客户端密钥，请单击以下文本：选择凭据。在打开的窗口中，选择您的项目和所需的凭证，然后单击“ 查看” 。

或者，从API Console的“ 凭据”页面中查看您的客户端ID和客户端密钥：

Go to the Credentials page.
单击您的凭证名称或铅笔（）图标。您的客户ID和密码位于页面顶部。

रीडायरेक्ट यूआरआई सेट करना

API Console में सेट किया गया रीडायरेक्ट यूआरआई यह तय करता है कि Google, पुष्टि करने के आपके अनुरोधों के जवाब कहां भेजता है.

要创建，查看或编辑给定OAuth 2.0凭据的重定向URI，请执行以下操作：

Go to the Credentials page.
在页面的OAuth 2.0客户端ID部分中，点击一个凭据。
查看或编辑重定向URI。

如果“凭据”页面上没有OAuth 2.0客户端ID部分，则您的项目没有OAuth凭据。要创建一个，点击创建凭证 。

उपयोगकर्ता की सहमति वाली स्क्रीन को पसंद के मुताबिक बनाना

OAuth 2.0 की पुष्टि करने की प्रोसेस में, उपयोगकर्ताओं को सहमति देने के लिए एक स्क्रीन दिखती है. इस स्क्रीन पर, उपयोगकर्ता को यह जानकारी दी जाती है कि वह कौनसी जानकारी दे रहा है और उस पर कौनसी शर्तें लागू होंगी. उदाहरण के लिए, जब उपयोगकर्ता लॉग इन करता है, तो उससे आपके ऐप्लिकेशन को अपने ईमेल पते और खाते की बुनियादी जानकारी का ऐक्सेस देने के लिए कहा जा सकता है. इस जानकारी को ऐक्सेस करने का अनुरोध, scope पैरामीटर का इस्तेमाल करके किया जाता है. आपका ऐप्लिकेशन, इस पैरामीटर को अपने पुष्टि करने के अनुरोध में शामिल करता है. Google के अन्य एपीआई का ऐक्सेस पाने के लिए भी स्कोप का इस्तेमाल किया जा सकता है.

उपयोगकर्ता की सहमति वाली स्क्रीन पर, ब्रैंडिंग की जानकारी भी दिखती है. जैसे, आपके प्रॉडक्ट का नाम, लोगो, और होम पेज का यूआरएल. API Consoleमें जाकर, ब्रैंडिंग की जानकारी को कंट्रोल किया जा सकता है.

要启用项目的同意屏幕：

在Consent Screen page中打开Google API Console 。
If prompted, select a project, or create a new one.
填写表格，然后点击保存。

सहमति वाले इस डायलॉग बॉक्स से पता चलता है कि जब अनुरोध में OAuth 2.0 और Google Drive के स्कोप का कॉम्बिनेशन मौजूद होगा, तो उपयोगकर्ता को क्या दिखेगा. (यह सामान्य डायलॉग, Google OAuth 2.0 Playground का इस्तेमाल करके जनरेट किया गया था. इसलिए, इसमें ब्रैंडिंग की जानकारी शामिल नहीं है, जो API Consoleमें सेट की जाएगी.)

सेवा को ऐक्सेस करना

Google और तीसरे पक्ष, लाइब्रेरी उपलब्ध कराते हैं. इनका इस्तेमाल करके, उपयोगकर्ताओं की पुष्टि करने और Google के एपीआई का ऐक्सेस पाने के लिए, लागू करने से जुड़ी कई जानकारी को मैनेज किया जा सकता है. उदाहरण के लिए, Google Identity Services और Google क्लाइंट लाइब्रेरी, जो कई प्लैटफ़ॉर्म के लिए उपलब्ध हैं.

ध्यान दें: सही तरीके से लागू करने से जुड़ी सुरक्षा से जुड़ी समस्याओं को देखते हुए, हमारा सुझाव है कि आप पहले से लिखी गई लाइब्रेरी या सेवा का फ़ायदा लें. उपयोगकर्ताओं की पुष्टि करना, उनकी और आपकी सुरक्षा के लिहाज़ से ज़रूरी है. आम तौर पर, दूसरों के लिखे गए ऐसे कोड का इस्तेमाल करना सबसे सही तरीका होता है जिसे अच्छी तरह से डीबग किया गया हो. ज़्यादा जानकारी के लिए, क्लाइंट लाइब्रेरी देखें.

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

उपयोगकर्ता की पुष्टि करना

उपयोगकर्ता की पुष्टि करने के लिए, आईडी टोकन पाना और उसकी पुष्टि करना ज़रूरी है. आईडी टोकन, OpenID Connect की एक स्टैंडर्ड सुविधा है. इसे इंटरनेट पर पहचान की पुष्टि करने के लिए डिज़ाइन किया गया है.

उपयोगकर्ता की पुष्टि करने और आईडी टोकन पाने के लिए, आम तौर पर इस्तेमाल किए जाने वाले तरीकों को "सर्वर" फ़्लो और "इंप्लिसिट" फ़्लो कहा जाता है. सर्वर फ़्लो की मदद से, किसी ऐप्लिकेशन के बैक-एंड सर्वर को ब्राउज़र या मोबाइल डिवाइस का इस्तेमाल करके, व्यक्ति की पहचान की पुष्टि करने की अनुमति मिलती है. एपीआई के लिए, इम्प्लीसिट फ़्लो का इस्तेमाल तब किया जाता है, जब क्लाइंट-साइड ऐप्लिकेशन (आम तौर पर, ब्राउज़र में चलने वाला JavaScript ऐप्लिकेशन) को अपने बैक-एंड सर्वर के बजाय, सीधे एपीआई को ऐक्सेस करना हो.

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

सर्वर फ़्लो

पक्का करें कि आपने अपने ऐप्लिकेशन को API Console में सेट अप किया हो, ताकि वह इन प्रोटोकॉल का इस्तेमाल कर सके और उपयोगकर्ताओं की पुष्टि कर सके. जब कोई उपयोगकर्ता Google से लॉग इन करने की कोशिश करता है, तो आपको:

जाल से बचने के लिए स्टेटस टोकन बनाना
Google को पुष्टि का अनुरोध भेजना
जाल से बचने के लिए इस्तेमाल होने वाले स्टेटस टोकन की पुष्टि करना
code को ऐक्सेस टोकन और आईडी टोकन के लिए एक्सचेंज करना
आईडी टोकन से उपयोगकर्ता की जानकारी पाना
उपयोगकर्ता की पुष्टि करना

1. जालसाजी रोकने के लिए स्टेटस टोकन बनाना

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

स्टेट टोकन के लिए, 30 या उससे ज़्यादा वर्णों की स्ट्रिंग एक अच्छा विकल्प है. इसे बनाने के लिए, अच्छी क्वालिटी के रैंडम-नंबर जनरेटर का इस्तेमाल किया जाता है. दूसरा है, आपके कुछ सेशन स्टेट वैरिएबल को एक ऐसी कुंजी से हस्ताक्षर करके जनरेट किया गया है जो आपके बैक-एंड पर गुप्त रखी जाती है.

नीचे दिए गए कोड में, यूनीक सेशन टोकन जनरेट करने का तरीका बताया गया है.

PHP

इस सैंपल का इस्तेमाल करने के लिए, आपको PHP के लिए Google APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

Java

इस सैंपल का इस्तेमाल करने के लिए, आपको Java के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

Python

इस सैंपल का इस्तेमाल करने के लिए, आपको Python के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Google को पुष्टि करने का अनुरोध भेजना

अगला चरण, सही यूआरआई पैरामीटर के साथ एचटीटीपीएस GET अनुरोध बनाना है. इस प्रोसेस के सभी चरणों में, एचटीटीपी के बजाय एचटीटीपीएस का इस्तेमाल करें. एचटीटीपी कनेक्शन को अनुमति नहीं दी जाती. आपको authorization_endpoint मेटाडेटा वैल्यू का इस्तेमाल करके, डिस्कवरी दस्तावेज़ से बेस यूआरआई पाना चाहिए. यहां दी गई चर्चा में यह माना गया है कि बेस यूआरआई https://accounts.google.com/o/oauth2/v2/auth है.

बुनियादी अनुरोध के लिए, ये पैरामीटर दें:

client_id, जो आपको API Console Credentials page से मिलता है.
response_type, जो ऑथराइज़ेशन कोड फ़्लो के बुनियादी अनुरोध में होना चाहिए code. (ज़्यादा जानकारी के लिए, response_type पर जाएं.)
scope, जो बुनियादी अनुरोध में openid email होना चाहिए. (ज़्यादा जानकारी के लिए, scope पर जाएं.)
redirect_uri आपके सर्वर पर मौजूद वह एचटीटीपी एंडपॉइंट होना चाहिए जिसे Google से रिस्पॉन्स मिलेगा. यह वैल्यू, API Console Credentials pageमें कॉन्फ़िगर किए गए OAuth 2.0 क्लाइंट के लिए, अनुमति वाले किसी एक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. अगर यह वैल्यू, अनुमति वाले यूआरआई से मेल नहीं खाती है, तो अनुरोध redirect_uri_mismatch गड़बड़ी के साथ पूरा नहीं होगा.
state में, नकली होने से रोकने वाले यूनीक सेशन टोकन की वैल्यू के साथ-साथ, उपयोगकर्ता के आपके ऐप्लिकेशन पर वापस आने पर कॉन्टेक्स्ट को वापस पाने के लिए ज़रूरी अन्य जानकारी भी शामिल होनी चाहिए. जैसे, शुरुआती यूआरएल. (ज़्यादा जानकारी के लिए, state पर जाएं.)
nonce आपके ऐप्लिकेशन से जनरेट की गई एक रैंडम वैल्यू होती है. यह मौजूद होने पर, रीप्ले की सुरक्षा की सुविधा चालू होती है.
login_hint, उपयोगकर्ता का ईमेल पता या sub स्ट्रिंग हो सकती है, जो उपयोगकर्ता के Google आईडी के बराबर होती है. अगर आपने login_hint नहीं दिया है और उपयोगकर्ता फ़िलहाल लॉग इन है, तो सहमति वाली स्क्रीन पर, आपके ऐप्लिकेशन को उपयोगकर्ता का ईमेल पता रिलीज़ करने के लिए अनुमति का अनुरोध शामिल होता है. (ज़्यादा जानकारी के लिए, login_hint पर जाएं.)
Google Workspace या Cloud संगठन से जुड़े किसी खास डोमेन के उपयोगकर्ताओं के लिए, OpenID Connect फ़्लो को ऑप्टिमाइज़ करने के लिए, hd पैरामीटर का इस्तेमाल करें. ज़्यादा जानकारी के लिए, hd पर जाएं.

यहां पूरी तरह से पुष्टि करने वाले OpenID Connect यूआरआई का उदाहरण दिया गया है. इसमें, पढ़ने के लिए लाइन ब्रेक और स्पेस शामिल किए गए हैं:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

अगर आपका ऐप्लिकेशन, उपयोगकर्ताओं से कोई नई जानकारी मांगता है या फिर आपका ऐप्लिकेशन किसी ऐसे खाते का ऐक्सेस मांगता है जिसकी अनुमति उपयोगकर्ताओं ने पहले नहीं दी है, तो उन्हें सहमति देनी होगी.

3. फ़र्ज़ी होने से रोकने वाले स्टेटस टोकन की पुष्टि करना

जवाब उस redirect_uri पर भेजा जाता है जिसे आपने अनुरोध में बताया है. सभी जवाब, क्वेरी स्ट्रिंग में दिखाए जाते हैं, जैसा कि यहां दिखाया गया है:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

आपको सर्वर पर इस बात की पुष्टि करनी होगी कि Google से मिला state, पहले चरण में बनाए गए आपके सेशन टोकन से मैच करता है या नहीं. राउंड-ट्रिप पुष्टि करने की इस सुविधा से, यह पक्का करने में मदद मिलती है कि अनुरोध, उपयोगकर्ता ने किया है, न कि नुकसान पहुंचाने वाली स्क्रिप्ट ने.

यहां दिए गए कोड में, पहले चरण में बनाए गए सेशन टोकन की पुष्टि करने का तरीका बताया गया है:

PHP

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

Java

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

Python

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. ऐक्सेस टोकन और आईडी टोकन के लिए `code` एक्सचेंज करना

रिस्पॉन्स में code पैरामीटर शामिल होता है. यह एक बार इस्तेमाल होने वाला ऑथराइज़ेशन कोड होता है. आपका सर्वर, इसे ऐक्सेस टोकन और आईडी टोकन के लिए बदल सकता है. आपका सर्वर, एचटीटीपीएस POST अनुरोध भेजकर, यह एक्सचेंज करता है. POST अनुरोध, टोकन एंडपॉइंट पर भेजा जाता है. इसे token_endpoint मेटाडेटा वैल्यू का इस्तेमाल करके, डिस्कवरी दस्तावेज़ से वापस पाया जा सकता है. यहां बताई गई बातचीत में यह माना गया है कि एंडपॉइंट https://oauth2.googleapis.com/token है. अनुरोध में, POST बॉडी में ये पैरामीटर शामिल होने चाहिए:

फ़ील्ड
`code`	शुरुआती अनुरोध से मिला ऑथराइज़ेशन कोड.
`client_id`	API Console Credentials pageसे मिलने वाला क्लाइंट आईडी, जैसा कि OAuth 2.0 क्रेडेंशियल पाना में बताया गया है.
`client_secret`	API Console Credentials pageसे मिलने वाला क्लाइंट सीक्रेट, जैसा कि OAuth 2.0 क्रेडेंशियल पाना में बताया गया है.
`redirect_uri`	API Console Credentials pageमें बताए गए `client_id` के लिए, अनुमति वाला रीडायरेक्ट यूआरआई. इस बारे में ज़्यादा जानने के लिए, रीडायरेक्ट यूआरआई सेट करना लेख पढ़ें.
`grant_type`	इस फ़ील्ड में `authorization_code` की वैल्यू होनी चाहिए, जैसा कि OAuth 2.0 स्पेसिफ़िकेशन में बताया गया है.

असल अनुरोध कुछ ऐसा दिख सकता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

इस अनुरोध के सही जवाब में, JSON कलेक्शन में ये फ़ील्ड शामिल होते हैं:

फ़ील्ड
`access_token`	ऐसा टोकन जिसे Google API को भेजा जा सकता है.
`expires_in`	ऐक्सेस टोकन के बचे हुए लाइफ़टाइम की जानकारी, सेकंड में.
`id_token`	ऐसा JWT जिसमें उपयोगकर्ता की पहचान की जानकारी होती है और जिस पर Google ने डिजिटल हस्ताक्षर किया हो.
`scope`	`access_token` से मिले ऐक्सेस के दायरे, स्पेस से अलग की गई, केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं.
`token_type`	यह बताता है कि किस तरह का टोकन दिखाया गया है. फ़िलहाल, इस फ़ील्ड की वैल्यू हमेशा `Bearer` होती है.
`refresh_token`	(ज़रूरी नहीं) यह फ़ील्ड सिर्फ़ तब मौजूद होता है, जब पुष्टि के अनुरोध में `access_type` पैरामीटर को `offline` पर सेट किया गया हो. ज़्यादा जानकारी के लिए, रीफ़्रेश टोकन लेख पढ़ें.

5. आईडी टोकन से उपयोगकर्ता की जानकारी पाना

आईडी टोकन एक JWT (JSON वेब टोकन) है. यह क्रिप्टोग्राफ़िक तरीके से हस्ताक्षर किया गया, Base64 में एन्कोड किया गया JSON ऑब्जेक्ट है. आम तौर पर, आईडी टोकन का इस्तेमाल करने से पहले, उसकी पुष्टि करना ज़रूरी होता है. हालांकि, आपके पास यह भरोसा करने का विकल्प है कि आपको जो टोकन मिला है वह असल में Google से मिला है और वह मान्य है. ऐसा इसलिए है, क्योंकि आपने किसी मध्यस्थ के बिना, एचटीटीपीएस चैनल पर सीधे Google से संपर्क किया है और Google से अपनी पहचान की पुष्टि करने के लिए, क्लाइंट सीक्रेट का इस्तेमाल किया है. अगर आपका सर्वर, आईडी टोकन को आपके ऐप्लिकेशन के अन्य कॉम्पोनेंट को पास करता है, तो यह ज़रूरी है कि अन्य कॉम्पोनेंट, इसका इस्तेमाल करने से पहले टोकन की पुष्टि कर लें.

ज़्यादातर एपीआई लाइब्रेरी, पुष्टि करने की प्रोसेस को base64url-encoded वैल्यू को डिकोड करने और उसमें मौजूद JSON को पार्स करने के साथ जोड़ती हैं. इसलिए, आईडी टोकन में मौजूद दावों को ऐक्सेस करने पर, आपको टोकन की पुष्टि करनी पड़ सकती है.

आईडी टोकन का पेलोड

आईडी टोकन एक JSON ऑब्जेक्ट होता है, जिसमें नाम/वैल्यू पेयर का एक सेट होता है. यहां एक उदाहरण दिया गया है, जिसे पढ़ने के लिए फ़ॉर्मैट किया गया है:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Google आईडी टोकन में ये फ़ील्ड (जिन्हें दावे कहा जाता है) शामिल हो सकते हैं:

दावा	दिया गया	ब्यौरा
`aud`	हमेशा	वह ऑडियंस जिसके लिए यह आईडी टोकन बनाया गया है. यह आपके ऐप्लिकेशन के OAuth 2.0 क्लाइंट आईडी में से एक होना चाहिए.
`exp`	हमेशा	आईडी टोकन की समयसीमा खत्म होने की तारीख. इस तारीख को या इसके बाद, आईडी टोकन स्वीकार नहीं किया जाना चाहिए. इसे यूनिक्स टाइम (पूर्णांक सेकंड) में दिखाया जाता है.
`iat`	हमेशा	आईडी टोकन जारी करने का समय. इसे यूनिक्स टाइम (पूर्णांक सेकंड) में दिखाया जाता है.
`iss`	हमेशा	जवाब देने वाले के लिए आइडेंटिफ़ायर. Google आईडी टोकन के लिए, हमेशा `https://accounts.google.com` या `accounts.google.com` का इस्तेमाल करें.
`sub`	हमेशा	उपयोगकर्ता का आइडेंटिफ़ायर, जो सभी Google खातों में यूनीक होता है और इसका फिर से इस्तेमाल नहीं किया जाता. किसी Google खाते में, अलग-अलग समय पर एक से ज़्यादा ईमेल पते हो सकते हैं. हालांकि, `sub` की वैल्यू कभी नहीं बदलती. अपने ऐप्लिकेशन में, उपयोगकर्ता के यूनीक आइडेंटिफ़ायर के तौर पर `sub` का इस्तेमाल करें. इसमें ज़्यादा से ज़्यादा 255 केस-सेंसिटिव ASCII वर्ण इस्तेमाल किए जा सकते हैं.
`at_hash`		ऐक्सेस टोकन हैश. इसकी मदद से यह पुष्टि की जाती है कि ऐक्सेस टोकन, पहचान टोकन से जुड़ा है या नहीं. अगर आईडी टोकन को सर्वर फ़्लो में `access_token` वैल्यू के साथ जारी किया जाता है, तो यह दावा हमेशा शामिल किया जाता है. इस दावे का इस्तेमाल, किसी दूसरी साइट से किए जाने वाले अनुरोधों से बचाव करने के लिए, वैकल्पिक तरीके के तौर पर किया जा सकता है. हालांकि, अगर पहला चरण और तीसरा चरण पूरा किया जाता है, तो ऐक्सेस टोकन की पुष्टि करना ज़रूरी नहीं है.
`azp`		आधिकारिक प्रज़ेंटर का `client_id`. इस दावे की ज़रूरत सिर्फ़ तब होती है, जब आईडी टोकन का अनुरोध करने वाली पार्टी, आईडी टोकन की ऑडियंस से अलग हो. ऐसा हो सकता है कि Google पर, हाइब्रिड ऐप्लिकेशन के लिए ऐसा हो. इनमें वेब ऐप्लिकेशन और Android ऐप्लिकेशन के लिए, OAuth 2.0 का अलग-अलग `client_id` हो, लेकिन एक ही Google API प्रोजेक्ट का इस्तेमाल किया जा रहा हो.
`email`		उपयोगकर्ता का ईमेल पता. यह सिर्फ़ तब दिखता है, जब आपने अपने अनुरोध में `email` दायरा शामिल किया हो. हो सकता है कि इस दावे की वैल्यू, इस खाते के लिए यूनीक न हो और समय के साथ बदल सकती है. इसलिए, आपको अपने उपयोगकर्ता रिकॉर्ड से लिंक करने के लिए, इस वैल्यू का इस्तेमाल मुख्य आइडेंटिफ़ायर के तौर पर नहीं करना चाहिए. Google Workspace या Cloud के संगठनों के उपयोगकर्ताओं की पहचान करने के लिए, `email` दावे के डोमेन पर भी भरोसा नहीं किया जा सकता. इसके बजाय, `hd` दावे का इस्तेमाल करें.
`email_verified`		अगर उपयोगकर्ता के ईमेल पते की पुष्टि हो चुकी है, तो यह वैल्यू 'सही' होगी. अगर पुष्टि नहीं हुई है, तो यह वैल्यू 'गलत' होगी.
`family_name`		उपयोगकर्ता का उपनाम या उपनाम. यह एट्रिब्यूट तब दिया जा सकता है, जब कोई `name` दावा मौजूद हो.
`given_name`		उपयोगकर्ता का नाम या नाम. यह एट्रिब्यूट तब दिया जा सकता है, जब कोई `name` दावा मौजूद हो.
`hd`		उपयोगकर्ता के Google Workspace या Cloud संगठन से जुड़ा डोमेन. यह सिर्फ़ तब दिखता है, जब उपयोगकर्ता किसी Google Cloud संगठन से जुड़ा हो. किसी संसाधन का ऐक्सेस सिर्फ़ कुछ डोमेन के सदस्यों के लिए सीमित करते समय, आपको यह दावा देखना होगा. इस दावे के मौजूद न होने का मतलब है कि खाता, Google के होस्ट किए गए डोमेन से नहीं जुड़ा है.
`locale`		उपयोगकर्ता की स्थानीय भाषा, जिसे BCP 47 भाषा टैग से दिखाया जाता है. `name` दावा मौजूद होने पर, यह एट्रिब्यूट दिया जा सकता है.
`name`		उपयोगकर्ता का पूरा नाम, जिसे दिखाया जा सकता है. यह जानकारी तब दी जा सकती है, जब: अनुरोध के दायरे में "प्रोफ़ाइल" स्ट्रिंग शामिल थी टोकन रीफ़्रेश करने पर आईडी टोकन मिलता है `name` दावे मौजूद होने पर, उनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
`nonce`		पुष्टि करने के अनुरोध में, आपके ऐप्लिकेशन की ओर से दी गई `nonce` की वैल्यू. आपको रीप्ले हमलों से सुरक्षा देने के लिए, यह पक्का करना चाहिए कि कोड सिर्फ़ एक बार दिखाया जाए.
`picture`		उपयोगकर्ता की प्रोफ़ाइल फ़ोटो का यूआरएल. यह जानकारी तब दी जा सकती है, जब: अनुरोध के दायरे में "प्रोफ़ाइल" स्ट्रिंग शामिल थी टोकन रीफ़्रेश करने पर आईडी टोकन मिलता है `picture` दावे मौजूद होने पर, उनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
`profile`		उपयोगकर्ता के प्रोफ़ाइल पेज का यूआरएल. यह जानकारी तब दी जा सकती है, जब: अनुरोध के दायरे में "प्रोफ़ाइल" स्ट्रिंग शामिल थी टोकन रीफ़्रेश करने पर आईडी टोकन मिलता है `profile` दावे मौजूद होने पर, उनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.

6. उपयोगकर्ता की पुष्टि करना

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

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

उन्नत विषय

नीचे दिए गए सेक्शन में, Google OAuth 2.0 API के बारे में ज़्यादा जानकारी दी गई है. यह जानकारी उन डेवलपर के लिए है जिन्हें पुष्टि और अनुमति से जुड़ी ऐडवांस ज़रूरी शर्तों के बारे में जानकारी चाहिए.

Google के अन्य एपीआई का ऐक्सेस

पुष्टि करने के लिए OAuth 2.0 का इस्तेमाल करने का एक फ़ायदा यह है कि उपयोगकर्ता की पुष्टि करने के साथ-साथ, आपके ऐप्लिकेशन को उपयोगकर्ता की ओर से, Google के अन्य एपीआई (जैसे, YouTube, Google Drive, कैलेंडर या संपर्क) का इस्तेमाल करने की अनुमति मिल सकती है. इसके लिए, Google को भेजे जाने वाले पुष्टि करने के अनुरोध में, ऐसे अन्य स्कोप शामिल करें जिनकी आपको ज़रूरत है. उदाहरण के लिए, पुष्टि करने के अनुरोध में उपयोगकर्ता के उम्र समूह को जोड़ने के लिए, openid email https://www.googleapis.com/auth/profile.agerange.read का स्कोप पैरामीटर पास करें. सहमति स्क्रीन पर, उपयोगकर्ता को सही तरीके से कहा गया हो. Google से मिले ऐक्सेस टोकन की मदद से, उन सभी एपीआई को ऐक्सेस किया जा सकता है जिनके लिए आपने ऐक्सेस का अनुरोध किया था और जिन्हें आपको ऐक्सेस दिया गया था.

ध्यान दें: अगर आपका ऐप्लिकेशन कई स्कोप के लिए अनुरोध कर रहा है, तो सहमति वाली स्क्रीन पर टेक्स्ट की कई लाइनें दिखेंगी. आपका ऐप्लिकेशन जितने ज़्यादा स्कोप के लिए अनुरोध करेगा, उपयोगकर्ता की सहमति मिलने की संभावना उतनी ही कम होगी. इसलिए, आपके ऐप्लिकेशन को सिर्फ़ उन स्कोप के लिए अनुरोध करना चाहिए जिनकी उसे ज़रूरत है.

रीफ़्रेश टोकन

एपीआई ऐक्सेस के अनुरोध में, code एक्सचेंज के दौरान वापस किए जाने वाले रीफ़्रेश टोकन का अनुरोध किया जा सकता है. रीफ़्रेश टोकन की मदद से, आपके ऐप्लिकेशन को Google के एपीआई का ऐक्सेस तब भी मिलता रहता है, जब उपयोगकर्ता आपके ऐप्लिकेशन में मौजूद न हो. रीफ़्रेश टोकन का अनुरोध करने के लिए, पुष्टि करने के अनुरोध में access_type पैरामीटर को offline पर सेट करें.

इन बातों पर ध्यान दें:

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

ज़्यादा जानकारी के लिए, ऐक्सेस टोकन को रीफ़्रेश करना (ऑफ़लाइन ऐक्सेस) देखें.

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

prompt पैरामीटर के बारे में ज़्यादा जानने के लिए, पुष्टि करने के लिए यूआरआई पैरामीटर टेबल में prompt देखें.

पुष्टि करने के लिए यूआरआई पैरामीटर

नीचे दी गई टेबल में, Google के OAuth 2.0 पुष्टि करने वाले एपीआई के ज़रिए स्वीकार किए गए पैरामीटर के बारे में ज़्यादा जानकारी दी गई है.

पैरामीटर	ज़रूरी है	ब्यौरा
`client_id`	(ज़रूरी है)	क्लाइंट आईडी की वह स्ट्रिंग जो आपको API Console Credentials pageसे मिलती है, जैसा कि OAuth 2.0 क्रेडेंशियल पाना में बताया गया है.
`nonce`	(ज़रूरी है)	आपके ऐप्लिकेशन से जनरेट की गई एक रैंडम वैल्यू, जो रीप्ले प्रोटेक्शन की सुविधा चालू करती है.
`response_type`	(ज़रूरी है)	अगर वैल्यू `code` है, तो सामान्य ऑथराइज़ेशन कोड फ़्लो शुरू होता है. इसके लिए, टोकन पाने के लिए टोकन एंडपॉइंट के लिए `POST` की ज़रूरत होती है. अगर वैल्यू `token id_token` या `id_token token` है, तो इंप्लिसिट फ़्लो शुरू होता है. इसके लिए, रीडायरेक्ट यूआरआई पर JavaScript का इस्तेमाल करना ज़रूरी होता है, ताकि यूआरआई `#fragment` आइडेंटिफ़ायर से टोकन वापस पाए जा सकें.
`redirect_uri`	(ज़रूरी है)	यह तय करता है कि जवाब कहां भेजा जाए. इस पैरामीटर की वैल्यू, API Console Credentials page में सेट की गई, अनुमति वाली रीडायरेक्ट वैल्यू से पूरी तरह मैच करनी चाहिए. इसमें एचटीटीपी या एचटीटीपीएस स्कीम, केस, और आखिर में मौजूद '/' (अगर कोई हो) शामिल है.
`scope`	(ज़रूरी है)	स्कोप पैरामीटर, `openid` वैल्यू से शुरू होना चाहिए. इसके बाद, इसमें `profile` वैल्यू, `email` वैल्यू या दोनों शामिल होनी चाहिए. अगर `profile` स्कोप की वैल्यू मौजूद है, तो हो सकता है कि आईडी टोकन में उपयोगकर्ता के डिफ़ॉल्ट `profile` दावे शामिल हों. हालांकि, इसकी कोई गारंटी नहीं है. अगर `email` स्कोप की वैल्यू मौजूद है, तो आईडी टोकन में `email` और `email_verified` क्लेम शामिल होते हैं. OpenID के लिए खास तौर पर बनाए गए इन स्कोप के अलावा, आपके स्कोप आर्ग्युमेंट में अन्य स्कोप वैल्यू भी शामिल हो सकती हैं. स्कोप की सभी वैल्यू को स्पेस से अलग किया जाना चाहिए. उदाहरण के लिए, अगर आपको किसी उपयोगकर्ता के Google Drive में मौजूद हर फ़ाइल का ऐक्सेस चाहिए, तो आपका स्कोप पैरामीटर `openid profile email https://www.googleapis.com/auth/drive.file` हो सकता है. उपलब्ध स्कोप के बारे में जानकारी पाने के लिए, Google API के लिए OAuth 2.0 के दायरे देखें या उस Google API के दस्तावेज़ देखें जिसका इस्तेमाल करना है.
`state`	(ज़रूरी नहीं, लेकिन इसका सुझाव दिया जाता है)	एक ओपेक स्ट्रिंग, जो प्रोटोकॉल में राउंड-ट्रिप की जाती है. इसका मतलब है कि इसे बुनियादी फ़्लो में यूआरआई पैरामीटर के तौर पर और इंप्लिसिट फ़्लो में यूआरआई `#fragment` के आइडेंटिफ़ायर के तौर पर दिखाया जाता है. `state`, अनुरोधों और जवाबों को जोड़ने के लिए मददगार हो सकता है. आपके `redirect_uri` का अनुमान लगाया जा सकता है. इसलिए, `state` वैल्यू का इस्तेमाल करने से, आपको यह पक्का करने में मदद मिल सकती है कि कोई इनकमिंग कनेक्शन, आपके ऐप्लिकेशन से शुरू किए गए पुष्टि करने के अनुरोध का नतीजा है.अगर आपने किसी रैंडम स्ट्रिंग को जनरेट किया है या इस `state` वैरिएबल में किसी क्लाइंट स्टेटस (जैसे, कुकी) के हैश को कोड में बदला है, तो जवाब की पुष्टि की जा सकती है. इससे यह भी पक्का किया जा सकता है कि अनुरोध और जवाब, एक ही ब्राउज़र से शुरू हुए हैं. इससे किसी दूसरी साइट से किए जाने वाले फ़र्ज़ी अनुरोधों जैसे हमलों से सुरक्षा मिलती है.
`access_type`	(ज़रूरी नहीं)	`offline` और `online` को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. इस असर के बारे में जानकारी, ऑफ़लाइन ऐक्सेस में दी गई है. अगर ऐक्सेस टोकन का अनुरोध किया जा रहा है, तो क्लाइंट को `offline` की वैल्यू तय किए जाने तक रीफ़्रेश टोकन नहीं मिलता.
`display`	(ज़रूरी नहीं)	पुष्टि करने वाला सर्वर, पुष्टि करने और सहमति देने के लिए यूज़र इंटरफ़ेस के पेजों को कैसे दिखाता है, यह बताने के लिए ASCII स्ट्रिंग वैल्यू. यहां दी गई वैल्यू तय की गई हैं और Google के सर्वर इन्हें स्वीकार करते हैं. हालांकि, इनका इस पर कोई असर नहीं पड़ता: `page`, `popup`, `touch`, और `wap`.
`hd`	(ज़रूरी नहीं)	Google Cloud संगठन के मालिकाना हक वाले खातों के लिए, लॉगिन की प्रोसेस को आसान बनाएं. Google Cloud के संगठन के डोमेन (उदाहरण के लिए, `mycollege.edu`) को शामिल करके, यह बताया जा सकता है कि खाता चुनने के यूज़र इंटरफ़ेस (यूआई) को उस डोमेन के खातों के लिए ऑप्टिमाइज़ किया जाना चाहिए. सिर्फ़ एक Google Cloud संगठन के डोमेन के बजाय, Google Cloud के संगठन के खातों के लिए आम तौर पर ऑप्टिमाइज़ करने के लिए, तारे के निशान (``) की वैल्यू सेट करें: `hd=`. यह कंट्रोल करने के लिए कि आपका ऐप्लिकेशन कौन ऐक्सेस कर सकता है, इस यूज़र इंटरफ़ेस (यूआई) ऑप्टिमाइज़ेशन पर भरोसा न करें. ऐसा इसलिए, क्योंकि क्लाइंट-साइड के अनुरोधों में बदलाव किया जा सकता है. पक्का करें कि वापस किए गए आईडी टोकन में `hd` दावे की वैल्यू, आपकी उम्मीद के मुताबिक हो (उदाहरण के लिए, `mycolledge.edu`). अनुरोध पैरामीटर के उलट, आईडी टोकन `hd` दावा, Google के सिक्योरिटी टोकन में शामिल होता है. इसलिए, इस वैल्यू पर भरोसा किया जा सकता है.
`include_granted_scopes`	(ज़रूरी नहीं)	अगर इस पैरामीटर को `true` वैल्यू के साथ दिया जाता है और अनुमति का अनुरोध स्वीकार कर लिया जाता है, तो अनुमति में अन्य स्कोप के लिए, इस उपयोगकर्ता/ऐप्लिकेशन कॉम्बिनेशन को दी गई पिछली अनुमतियां शामिल होंगी. बढ़ी हुई अनुमति देखें. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के फ़्लो की मदद से, अनुमति को धीरे-धीरे बढ़ाया नहीं जा सकता.
`login_hint`	(ज़रूरी नहीं)	जब आपके ऐप्लिकेशन को पता होता है कि वह किस उपयोगकर्ता की पुष्टि करने की कोशिश कर रहा है, तो वह पुष्टि करने वाले सर्वर को संकेत के तौर पर यह पैरामीटर दे सकता है. यह हिंट देने पर, खाता चुनने वाला टूल नहीं दिखता. साथ ही, साइन इन फ़ॉर्म पर ईमेल बॉक्स में जानकारी पहले से भरी होती है या सही सेशन चुना जाता है. ऐसा तब होता है, जब उपयोगकर्ता एक से ज़्यादा खातों से साइन इन कर रहा हो. इससे, आपके ऐप्लिकेशन के गलत उपयोगकर्ता खाते में लॉग इन करने पर होने वाली समस्याओं से बचा जा सकता है. वैल्यू, ईमेल पता या `sub` स्ट्रिंग हो सकती है. यह स्ट्रिंग, उपयोगकर्ता के Google आईडी के बराबर होती है.
`prompt`	(ज़रूरी नहीं)	स्पेस से अलग की गई स्ट्रिंग वैल्यू की सूची, जिसमें यह जानकारी होती है कि अनुमति देने वाला सर्वर, उपयोगकर्ता से फिर से पुष्टि करने और सहमति देने के लिए कहता है या नहीं. ये वैल्यू हो सकती हैं: `none` अनुमति देने वाला सर्वर, पुष्टि करने या उपयोगकर्ता की सहमति वाली कोई स्क्रीन नहीं दिखाता. अगर उपयोगकर्ता की पुष्टि पहले से नहीं की गई है और अनुरोध किए गए स्कोप के लिए सहमति पहले से कॉन्फ़िगर नहीं की गई है, तो यह गड़बड़ी दिखाएगा. मौजूदा पुष्टि और/या सहमति की जांच करने के लिए, `none` का इस्तेमाल किया जा सकता है. `consent` क्लाइंट को जानकारी भेजने से पहले, अनुमति देने वाला सर्वर उपयोगकर्ता से सहमति मांगता है. `select_account` अनुमति देने वाला सर्वर, उपयोगकर्ता से कोई उपयोगकर्ता खाता चुनने के लिए कहता है. इससे, अनुमति देने वाले सर्वर पर एक से ज़्यादा खाते रखने वाले उपयोगकर्ता को, उन खातों में से किसी एक को चुनने की अनुमति मिलती है जिनके लिए उनके पास मौजूदा सेशन हो सकते हैं. अगर कोई वैल्यू नहीं दी गई है और उपयोगकर्ता ने पहले ऐक्सेस की अनुमति नहीं दी है, तो उपयोगकर्ता को सहमति वाली स्क्रीन दिखाई जाती है.

आईडी टोकन की पुष्टि करना

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

यहां ऐसी सामान्य स्थितियां दी गई हैं जिनमें आपको अपने सर्वर पर आईडी टोकन भेजने पड़ सकते हैं:

पुष्टि किए जाने वाले अनुरोधों के साथ आईडी टोकन भेजना. आईडी टोकन से आपको यह पता चलता है कि अनुरोध करने वाला कौनसा उपयोगकर्ता है और आईडी टोकन किस क्लाइंट को दिया गया है.

आईडी टोकन संवेदनशील होते हैं और अगर उन्हें इंटरसेप्ट किया जाता है, तो उनका गलत इस्तेमाल किया जा सकता है. आपको यह पक्का करना होगा कि इन टोकन को सिर्फ़ एचटीटीपीएस पर और सिर्फ़ पोस्ट डेटा या अनुरोध हेडर के ज़रिए ट्रांसमिट करके, सुरक्षित तरीके से हैंडल किया जाए. अगर आपने अपने सर्वर पर आईडी टोकन सेव किए हैं, तो आपको उन्हें सुरक्षित तरीके से सेव करना होगा.

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

आईडी टोकन की पुष्टि करने के लिए, कई चरणों को पूरा करना ज़रूरी है:

पुष्टि करें कि आईडी टोकन पर, जारी करने वाले ने सही तरीके से हस्ताक्षर किया हो. Google से जारी किए गए टोकन पर, डिस्कवरी दस्तावेज़ के jwks_uri मेटाडेटा की वैल्यू में दिए गए यूआरआई पर मौजूद किसी सर्टिफ़िकेट का इस्तेमाल करके हस्ताक्षर किए जाते हैं.
पुष्टि करें कि आईडी टोकन में iss दावे की वैल्यू, https://accounts.google.com या accounts.google.com के बराबर हो.
पुष्टि करें कि आईडी टोकन में aud क्लेम की वैल्यू, आपके ऐप्लिकेशन के क्लाइंट आईडी के बराबर हो.
पुष्टि करें कि आईडी टोकन की समयसीमा खत्म न हुई हो (exp दावा).
अगर आपने अनुरोध में hd पैरामीटर की वैल्यू दी है, तो पुष्टि करें कि आईडी टोकन में hd दावा है, जो किसी Google Cloud संगठन से जुड़े स्वीकार किए गए डोमेन से मैच करता है.

दूसरे से लेकर पांचवें चरण में, सिर्फ़ स्ट्रिंग और तारीख की तुलना की जाती है. यह बहुत आसान है, इसलिए हम यहां इस बारे में ज़्यादा जानकारी नहीं देंगे.

पहला चरण ज़्यादा मुश्किल होता है. इसमें क्रिप्टोग्राफ़िक हस्ताक्षर की जांच की जाती है. डीबग करने के लिए, Google के tokeninfo एंडपॉइंट का इस्तेमाल करके, अपने सर्वर या डिवाइस पर लागू की गई स्थानीय प्रोसेसिंग की तुलना की जा सकती है. मान लें कि आपके आईडी टोकन की वैल्यू XYZ123 है. इसके बाद, आपको यूआरआई का रेफ़रंस हटाना होगा https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. अगर टोकन का हस्ताक्षर मान्य है, तो रिस्पॉन्स के तौर पर, डिकोड किए गए JSON ऑब्जेक्ट फ़ॉर्मैट में JWT पेलोड मिलेगा.

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

Google अपनी सार्वजनिक कुंजियों को बहुत कम बदलता है. इसलिए, एचटीटीपी रिस्पॉन्स के कैश मेमोरी से जुड़े निर्देशों का इस्तेमाल करके, उन्हें कैश मेमोरी में सेव किया जा सकता है. ज़्यादातर मामलों में, tokeninfo एंडपॉइंट का इस्तेमाल करने के मुकाबले, स्थानीय पुष्टि करना ज़्यादा बेहतर होता है. पुष्टि करने के लिए, सर्टिफ़िकेट को वापस लाना और पार्स करना ज़रूरी है. साथ ही, हस्ताक्षर की जांच करने के लिए, सही क्रिप्टोग्राफ़िक कॉल करना भी ज़रूरी है. अच्छी बात यह है कि इस काम के लिए, कई भाषाओं में अच्छी तरह से डीबग की गई लाइब्रेरी उपलब्ध हैं. jwt.io देखें.

उपयोगकर्ता की प्रोफ़ाइल की जानकारी पाना

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

OpenID का पालन करने के लिए, आपको अपने पुष्टि करने के अनुरोध में, openid profile स्कोप वैल्यू शामिल करनी होंगी.

अगर आपको उपयोगकर्ता का ईमेल पता शामिल करना है, तो email के लिए अतिरिक्त स्कोप की वैल्यू दी जा सकती है. profile और email, दोनों के बारे में बताने के लिए, पुष्टि करने के अनुरोध वाले यूआरएल में यह पैरामीटर शामिल किया जा सकता है:
```
scope=openid%20profile%20email
```
ऑथराइज़ेशन हेडर में अपना ऐक्सेस टोकन जोड़ें और userinfo एंडपॉइंट पर एचटीटीपीएस GET अनुरोध करें. आपको userinfo_endpoint मेटाडेटा वैल्यू का इस्तेमाल करके, डिस्कवरी दस्तावेज़ से इसे वापस पाना होगा. userinfo रिस्पॉन्स में, उपयोगकर्ता के बारे में जानकारी शामिल होती है, जैसा कि OpenID Connect Standard Claims और डिस्कवरी दस्तावेज़ की claims_supported मेटाडेटा वैल्यू में बताया गया है. उपयोगकर्ता या उनके संगठन, कुछ फ़ील्ड को उपलब्ध कराने या छिपाने का विकल्प चुन सकते हैं. इसलिए, हो सकता है कि आपको ऐक्सेस के लिए मंज़ूरी वाले दायरे में, हर फ़ील्ड की जानकारी न मिले.

डिस्कवरी दस्तावेज़

OpenID Connect प्रोटोकॉल में, उपयोगकर्ताओं की पुष्टि करने के लिए कई एंडपॉइंट का इस्तेमाल करना ज़रूरी है. साथ ही, टोकन, उपयोगकर्ता की जानकारी, और सार्वजनिक कुंजियों जैसे संसाधनों का अनुरोध करने के लिए भी ऐसा करना ज़रूरी है.

लागू करने की प्रोसेस को आसान बनाने और सुविधाओं को बेहतर बनाने के लिए, OpenID Connect में "डिस्कवरी दस्तावेज़" का इस्तेमाल किया जा सकता है. यह एक JSON दस्तावेज़ है, जो किसी जानी-पहचानी जगह पर मौजूद होता है. इसमें की-वैल्यू पेयर होते हैं, जो OpenID Connect प्रोवाइडर के कॉन्फ़िगरेशन के बारे में जानकारी देते हैं. इसमें अनुमति, टोकन, रद्द करने, उपयोगकर्ता की जानकारी, और सार्वजनिक-कुंजियों के एंडपॉइंट के यूआरआई भी शामिल होते हैं. Google की OpenID Connect सेवा के लिए डिस्कवरी दस्तावेज़ को यहां से वापस पाया जा सकता है:

https://accounts.google.com/.well-known/openid-configuration

Google की OpenID Connect सेवाओं का इस्तेमाल करने के लिए, आपको अपने ऐप्लिकेशन में डिस्कवरी-दस्तावेज़ का यूआरआई (https://accounts.google.com/.well-known/openid-configuration) को हार्ड-कोड करना होगा. आपका ऐप्लिकेशन दस्तावेज़ को फ़ेच करता है और रिस्पॉन्स में कैश मेमोरी के नियम लागू करता है. इसके बाद, ज़रूरत के हिसाब से उससे एंडपॉइंट यूआरआई हासिल करता है. उदाहरण के लिए, किसी उपयोगकर्ता की पुष्टि करने के लिए, आपका कोड authorization_endpoint मेटाडेटा वैल्यू (यहां दिए गए उदाहरण में https://accounts.google.com/o/oauth2/v2/auth) को, Google को भेजे जाने वाले पुष्टि करने के अनुरोधों के लिए, बेस यूआरआई के तौर पर वापस लाएगा.

यहां ऐसे दस्तावेज़ का उदाहरण दिया गया है. फ़ील्ड के नाम, OpenID Connect डिस्कवरी 1.0 में बताए गए हैं. उनके मतलब जानने के लिए, उस दस्तावेज़ को देखें. ये वैल्यू सिर्फ़ उदाहरण के तौर पर दी गई हैं और इनमें बदलाव हो सकता है. हालांकि, इन्हें Google डिस्कवरी दस्तावेज़ के हाल ही के वर्शन से कॉपी किया गया है:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

डिस्कवरी दस्तावेज़ की वैल्यू को कैश मेमोरी में सेव करके, एचटीटीपी राउंड-ट्रिप से बचा जा सकता है. स्टैंडर्ड एचटीटीपी कैश मेमोरी में सेव करने वाले हेडर का इस्तेमाल किया जाता है और इनका पालन किया जाना चाहिए.

क्लाइंट लाइब्रेरी

यहां दी गई क्लाइंट लाइब्रेरी, लोकप्रिय फ़्रेमवर्क के साथ इंटिग्रेट करके, OAuth 2.0 को लागू करना आसान बनाती हैं:

OpenID Connect का पालन करना

Google का OAuth 2.0 ऑथेंटिकेशन सिस्टम, OpenID Connect Core स्पेसिफ़िकेशन की ज़रूरी सुविधाओं के साथ काम करता है. OpenID Connect के साथ काम करने के लिए डिज़ाइन किया गया कोई भी क्लाइंट, इस सेवा के साथ काम करना चाहिए. हालांकि, OpenID अनुरोध ऑब्जेक्ट के लिए ऐसा नहीं करना चाहिए.

OpenID कनेक्ट

OAuth 2.0 सेट अप करना

OAuth 2.0 क्रेडेंशियल पाना

रीडायरेक्ट यूआरआई सेट करना

उपयोगकर्ता की सहमति वाली स्क्रीन को पसंद के मुताबिक बनाना

सेवा को ऐक्सेस करना

उपयोगकर्ता की पुष्टि करना

सर्वर फ़्लो

1. जालसाजी रोकने के लिए स्टेटस टोकन बनाना

PHP

Java

Python

2. Google को पुष्टि करने का अनुरोध भेजना

3. फ़र्ज़ी होने से रोकने वाले स्टेटस टोकन की पुष्टि करना

PHP

Java

Python

4. ऐक्सेस टोकन और आईडी टोकन के लिए code एक्सचेंज करना

5. आईडी टोकन से उपयोगकर्ता की जानकारी पाना

आईडी टोकन का पेलोड

6. उपयोगकर्ता की पुष्टि करना

उन्नत विषय

Google के अन्य एपीआई का ऐक्सेस

रीफ़्रेश टोकन

फिर से सहमति देने के लिए कहा जा रहा है

पुष्टि करने के लिए यूआरआई पैरामीटर

आईडी टोकन की पुष्टि करना

उपयोगकर्ता की प्रोफ़ाइल की जानकारी पाना

डिस्कवरी दस्तावेज़

क्लाइंट लाइब्रेरी

OpenID Connect का पालन करना

4. ऐक्सेस टोकन और आईडी टोकन के लिए `code` एक्सचेंज करना