OpenGL कनेक्ट

Google और #39;sOpen Connect अंतिम एंडपॉइंट है.

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

OAuth 2.0 सेट अप करना

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

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

उपयोगकर्ताओं को प्रमाणित करने और Google' के एपीआई का ऐक्सेस पाने के लिए, आपको क्लाइंट आईडी और क्लाइंट सीक्रेट के साथ-साथ OAuth 2.0 क्रेडेंशियल की ज़रूरत होगी.

किसी दिए गए OAuth 2.0 क्रेडेंशियल के लिए क्लाइंट आईडी और क्लाइंट सीक्रेट देखने के लिए, निम्न टेक्स्ट पर क्लिक करें : क्रेडेंशियल का चयन करें । खुलने वाली विंडो में, अपनी परियोजना और इच्छित क्रेडेंशियल चुनें, फिर देखें पर क्लिक करें।

या, API Console में क्रेडेंशियल पेज से अपनी क्लाइंट आईडी और क्लाइंट सीक्रेट API Console :

  1. Go to the Credentials page.
  2. अपने क्रेडेंशियल या पेंसिल ( ) आइकन के नाम पर क्लिक करें। आपकी क्लाइंट आईडी और रहस्य पृष्ठ के शीर्ष पर हैं।

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

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

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

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

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

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

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

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

अपनी परियोजना की सहमति स्क्रीन को सक्षम करने के लिए:

  1. खोलें Consent Screen page में Google API Console ।
  2. If prompted, select a project, or create a new one.
  3. फॉर्म भरें और सेव पर क्लिक करें ।

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

सहमति वाले पेज का स्क्रीन शॉट

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

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

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

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

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

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

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

सर्वर फ़्लो

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

  1. एंटी-फ़र्ज़ी स्टेट टोकन बनाना
  2. Google को पुष्टि करने का अनुरोध भेजना
  3. एंटी-फ़र्जी स्थिति टोकन की पुष्टि करें
  4. ऐक्सेस टोकन और आईडी टोकन के लिए code को इस्तेमाल करें
  5. आईडी टोकन से उपयोगकर्ता की जानकारी पाना
  6. उपयोगकर्ता की पुष्टि करना

1. एंटी-फ़र्जी स्टेट टोकन बनाएं

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

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

यह कोड यूनीक सेशन टोकन जनरेट करने के बारे में बताता है.

PHP

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

// 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 से जवाब मिलेगा. यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले किसी एक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. इसे आपने API Console Credentials pageमें कॉन्फ़िगर किया था. अगर यह मान किसी आधिकारिक यूआरआई से मेल नहीं खाता है, तो अनुरोध पूरा नहीं होने पर redirect_uri_mismatch गड़बड़ी दिखेगी.
  • state में एंटी-फ़र्ज़ी यूनीक सेशन टोकन की वैल्यू शामिल होनी चाहिए. साथ ही, इससे उपयोगकर्ता को आपके ऐप्लिकेशन पर वापस आने पर होने वाली जानकारी, जैसे कि शुरुआती यूआरएल के बारे में भी जानकारी मिलेगी. (state पर ज़्यादा पढ़ें.)
  • nonce, आपके ऐप्लिकेशन से जनरेट की गई एक रैंडम वैल्यू होती है, जो मौजूद होने पर, जानकारी को फिर से चलाने की सुविधा चालू करती है.
  • login_hint, उपयोगकर्ता का # ईमेल पता या sub स्ट्रिंग हो सकता है, जो उपयोगकर्ता के Google आईडी के बराबर होता है. अगर आप login_hint की जानकारी नहीं देते और उपयोगकर्ता फ़िलहाल लॉग इन है, तो सहमति वाली स्क्रीन में, उपयोगकर्ता के ईमेल पते को आपके ऐप्लिकेशन पर रिलीज़ करने की अनुमति पाने का अनुरोध शामिल होता है. (login_hint पर ज़्यादा पढ़ें.)
  • hd पैरामीटर का इस्तेमाल करके, Google Cloud संगठन से जुड़े किसी खास डोमेन के उपयोगकर्ताओं के लिए, OpenConnect का फ़्लो ऑप्टिमाइज़ करें. (hd पर ज़्यादा पढ़ें.)

यहां, ओपन कनेक्ट ऑथेंटिकेशन के पूरे यूआरआई का उदाहरण दिया गया है. इसमें लाइन ब्रेक और खाली जगहों के साथ-साथ, पढ़ने के लिए जगह की जानकारी भी है:

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

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

// 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

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

// 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

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

# 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 दिए गए client_id के लिए आधिकारिक रीडायरेक्ट यूआरआई, API Console Credentials page, जैसा कि <i class="ph-0-3"> में बताया गया है, रीडायरेक्ट यूआरआई सेट करें.
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 वेब टोकन) होता है. यह JSON64 में कोड में बदला गया, JSON फ़ाइल होता है जो क्रिप्टोग्राफ़िक तरीके से साइन किया जाता है. आम तौर पर, इस्तेमाल करने से पहले यह ज़रूरी है कि आप किसी आईडी टोकन की पुष्टि करें. हालांकि, आप Google के साथ सीधे तौर पर इंटरैक्ट कर रहे हैं. इसके लिए, आपको किसी ऐसे यूआरएल का इस्तेमाल करना होगा जो Google की तरफ़ से मान्य नहीं है. इसलिए, आपको इस बात का भरोसा हो सकता है कि आपको मिला टोकन वाकई Google से मिला है और यह मान्य है. अगर आपका सर्वर आईडी टोकन को आपके ऐप्लिकेशन के दूसरे कॉम्पोनेंट में पास करता है, तो यह ज़रूरी है कि इस्तेमाल करने से पहले, दूसरे कॉम्पोनेंट टोकन की पुष्टि करें.

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

आईडी टोकन#39; पेलोड

आईडी टोकन एक 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 हमेशा खत्म होने का समय जिसके बाद आईडी टोकन स्वीकार नहीं किया जाना चाहिए. Unix समय (पूर्णांक सेकंड) में दिखाया गया.
iat हमेशा आईडी टोकन जारी करने का समय. यूनिक्स समय (पूर्णांक सेकंड) में दिखाया जाता है.
iss हमेशा जवाब जारी करने वाले का पहचानकर्ता. Google आईडी टोकन के लिए हमेशा https://accounts.google.com या accounts.google.com.
sub हमेशा उपयोगकर्ता के लिए एक पहचानकर्ता, जो सभी Google खातों में खास होता है और उसका दोबारा इस्तेमाल नहीं किया जाता है. एक Google खाते में अलग-अलग समय पर कई ईमेल पते हो सकते हैं. हालांकि, sub का मान कभी नहीं बदला जाता. अपने ऐप्लिकेशन में उपयोगकर्ता के लिए, खास पहचानकर्ता कुंजी के तौर पर sub का इस्तेमाल करें. केस-सेंसिटिव ASCII वर्णों की ज़्यादा से ज़्यादा 255 वर्ण.
at_hash ऐक्सेस टोकन हैश. इस बात की पुष्टि करता है कि ऐक्सेस टोकन, पहचान टोकन से जुड़ा है. अगर आईडी टोकन को सर्वर फ़्लो में access_token वैल्यू के साथ जारी किया जाता है, तो यह दावा हमेशा शामिल होता है. इस दावे का इस्तेमाल किसी दूसरे तरीके से की जाने वाली धोखाधड़ी से बचने के लिए किया जा सकता है. हालांकि, अगर आप पहले चरण और तीसरे चरण का पालन करते हैं, तो ऐक्सेस टोकन की पुष्टि करना ज़रूरी नहीं होता.
azp अनुमति वाले प्रज़ेंटर का client_id. इस दावे की ज़रूरत सिर्फ़ तब होती है, जब आईडी टोकन का अनुरोध करने वाला पक्ष, आईडी टोकन के ऑडियंस से अलग होता है. Google के हाइब्रिड ऐप्लिकेशन के लिए इन मामलों में ऐसा हो सकता है कि किसी वेब ऐप्लिकेशन और Android ऐप्लिकेशन का OAuth 2.0 client_id अलग-अलग हो, लेकिन Google API का एक ही प्रोजेक्ट शेयर हो.
email उपयोगकर्ता का ईमेल पता. हो सकता है कि यह वैल्यू उपयोगकर्ता के लिए अलग न हो और यह मुख्य कुंजी के तौर पर इस्तेमाल करने के लिए सही न हो. सिर्फ़ तब उपलब्ध कराया जाता है, जब आपके दायरे में email दायरे की वैल्यू शामिल हो.
email_verified अगर उपयोगकर्ता के ईमेल पते की पुष्टि हो गई है, तो सही है. अगर ऐसा नहीं है, तो गलत है.
family_name उपयोगकर्ता का उपनाम (उपनाम) या उपनाम. name का दावा होने पर दिया जा सकता है.
given_name उपयोगकर्ता (जिन्हें) नाम या नाम दिया गया है. name का दावा होने पर दिया जा सकता है.
hd उपयोगकर्ता के Google Cloud संगठन से जुड़ा डोमेन. इसकी जानकारी सिर्फ़ तब दी जाती है, जब उपयोगकर्ता किसी Google Cloud संगठन से जुड़ा हो.
locale उपयोगकर्ता और #39; की स्थान-भाषा, जिसे BCP 47 भाषा के टैग से दिखाया जाता है. इसकी जानकारी तब दी जा सकती है, जब name दावा मौजूद हो.
name दिखने वाले फ़ॉर्म में उपयोगकर्ता का पूरा नाम. शायद तब दिया जाए, जब:
  • अनुरोध के दायरे में स्ट्रिंग &कोटेशन; कोटेशन शामिल है;
  • आईडी टोकन, टोकन रीफ़्रेश करने के बाद दिखता है

name दावे होने पर, आप उनका इस्तेमाल अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड अपडेट करने के लिए कर सकते हैं. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
nonce पुष्टि करने के अनुरोध में आपके ऐप्लिकेशन से मिली nonce की वैल्यू. आपको यह पक्का करना चाहिए कि आपका कॉन्टेंट सिर्फ़ एक बार प्रज़ेंट किया जा रहा हो. इसके लिए, आपको रीप्ले हमलों से सुरक्षा देनी होगी.
picture उपयोगकर्ता की प्रोफ़ाइल फ़ोटो का यूआरएल. शायद तब दिया जाए, जब:
  • अनुरोध के दायरे में स्ट्रिंग &कोटेशन; कोटेशन शामिल है;
  • आईडी टोकन, टोकन रीफ़्रेश करने के बाद दिखता है

जब picture दावे मौजूद होते हैं, तब आप उनका इस्तेमाल अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड अपडेट करने के लिए कर सकते हैं. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
profile उपयोगकर्ता के प्रोफ़ाइल पेज का यूआरएल. शायद तब दिया जाए, जब:
  • अनुरोध के दायरे में स्ट्रिंग &कोटेशन; कोटेशन शामिल है;
  • आईडी टोकन, टोकन रीफ़्रेश करने के बाद दिखता है

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

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

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

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

उन्नत विषय

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

अन्य Google API का ऐक्सेस

पुष्टि करने के लिए OAuth 2.0 इस्तेमाल करने का एक फ़ायदा यह भी है कि उपयोगकर्ता की पुष्टि करते समय, आपके ऐप्लिकेशन को उपयोगकर्ता की ओर से, Google के अन्य एपीआई (जैसे कि YouTube, Google Drive, Calendar या Contacts) की मदद लेने की अनुमति मिल सकती है. ऐसा करने के लिए, आपको Google को भेजे जाने वाले पुष्टि करने के अनुरोध में अन्य दायरों को शामिल करना होगा. उदाहरण के लिए, अपनी पुष्टि करने के अनुरोध में उपयोगकर्ता और #39 लोगों का उम्र समूह जोड़ने के लिए, 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's OAuth 2.0 की पुष्टि करने वाले एपीआई से स्वीकार किए जाते हैं.

पैरामीटर ज़रूरी है ब्यौरा
client_id (ज़रूरी है) क्लाइंट आईडी स्ट्रिंग, जो आपको API Console Credentials pageसे मिलती है, जैसा कि OAuth 2.0 क्रेडेंशियल पाएं में बताया गया है.
nonce (ज़रूरी है) आपके ऐप्लिकेशन से जनरेट किया गया कोई भी मान जो रीप्ले सुरक्षा को चालू करता है.
response_type (ज़रूरी है) अगर वैल्यू code है, तो सामान्य ऑथराइज़ेशन कोड फ़्लो लॉन्च किया जाता है. साथ ही, टोकन पाने के लिए, टोकन एंडपॉइंट पर POST की ज़रूरत होती है. अगर वैल्यू token id_token या id_token token है, तो इंप्लिसिट फ़्लो को लॉन्च करें. इसके लिए, यूआरआई #fragment आइडेंटिफ़ायर से टोकन पाने के लिए, रीडायरेक्ट यूआरआई पर JavaScript का इस्तेमाल करना ज़रूरी है.
redirect_uri (ज़रूरी है) तय करता है कि जवाब कहां भेजा जाए. इस पैरामीटर की वैल्यू, API Console Credentials page में सेट की गई अनुमति वाली वैल्यू में से किसी एक से पूरी तरह मेल खानी चाहिए. इनमें एचटीटीपी या एचटीटीपीएस स्कीम, केस, और ट्रेलिंग '/' (अगर कोई हो) शामिल हैं.
scope (ज़रूरी है)

स्कोप पैरामीटर openid वैल्यू से शुरू होना चाहिए और फिर इसमें profile वैल्यू, email वैल्यू या दोनों शामिल होने चाहिए.

अगर profile के दायरे में वैल्यू मौजूद है, तो हो सकता है कि आईडी टोकन में उपयोगकर्ता और #39; के डिफ़ॉल्ट profile दावे शामिल हों.

अगर email के दायरे की वैल्यू मौजूद है, तो आईडी टोकन में email और email_verified दावे शामिल हैं.

इन OpenGL-खास स्कोप के अलावा, आपके दायरे के तर्क में दूसरी स्कोप वैल्यू भी शामिल हो सकती हैं. दायरे के सभी मान स्पेस से अलग किए हुए होने चाहिए. उदाहरण के लिए, अगर आप उपयोगकर्ता की # Google Drive को हर फ़ाइल के हिसाब से ऐक्सेस करना चाहते हैं, तो आपका दायरे का पैरामीटर, openid profile email https://www.googleapis.com/auth/drive.file हो सकता है.

उपलब्ध दायरों के बारे में जानकारी के लिए, Google API के लिए OAuth 2.0 दायरे या Google API के वे दस्तावेज़ देखें जिनका आप इस्तेमाल करना चाहते हैं.
state (ज़रूरी नहीं, लेकिन इस्तेमाल करने का सुझाव दिया जाता है)

एक अपारदर्शिता स्ट्रिंग जो प्रोटोकॉल में राउंड-ट्रिप की जाती है; इसका मतलब है कि उसे बेसिक फ़्लो में यूआरआई पैरामीटर के तौर पर और इंप्लिसिट फ़्लो में यूआरआई #fragment आइडेंटिफ़ायर के तौर पर दिखाया जाता है.

state, अनुरोधों और जवाबों से जुड़ी जानकारी के लिए काम का हो सकता है. 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 स्ट्रिंग हो सकती है, जो उपयोगकर्ता के ईमेल आईडी के बराबर होता है.
prompt (ज़रूरी नहीं) स्ट्रिंग की ऐसी वैल्यू की सूची जिसे देखकर यह तय किया जा सकता है कि क्या अनुमति देने वाला सर्वर, उपयोगकर्ता को फिर से पुष्टि करने और सहमति देने के लिए कहता है या नहीं. इसकी ये वैल्यू हो सकती हैं:
  • none

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

  • consent

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

  • select_account

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

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

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

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

ये कुछ सामान्य स्थितियां हैं, जहां आप अपने सर्वर को आईडी टोकन भेज सकते हैं:

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

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

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

आईडी टोकन की पुष्टि करने के लिए, यह तरीका अपनाना होगा:

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

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

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

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

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

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

उपयोगकर्ता के बारे में अतिरिक्त प्रोफ़ाइल जानकारी पाने के लिए, आप ऐक्सेस टोकन (जो आपके ऐप्लिकेशन को प्रामाणिकता फ़्लो के दौरान मिलता है) और OpenID Connect मानक का इस्तेमाल कर सकते हैं:

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

    अगर आप उपयोगकर्ता का # ईमेल पता शामिल करना चाहते हैं, तो आप email का एक दूसरा दायरा मान बता सकते हैं. अपने profile और email, दोनों को तय करने के लिए आप पुष्टि करने के अनुरोध वाले यूआरआई में ये पैरामीटर शामिल कर सकते हैं:

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

खोज से जुड़ा दस्तावेज़

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

लागू करने को आसान बनाने और सुविधा को आसान बनाने के लिए, OpenGL Connect & Google और #39;sOpen Connect सेवा के लिए खोज दस्तावेज़ यहां से पुनर्प्राप्त किया जा सकता है:

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

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

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

{
  "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 को लागू करना आसान बनाती हैं:

OpenGL कनेक्ट का पालन

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