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' से टैग करें.

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 क्रेडेंशियल होने चाहिए. इनमें क्लाइंट आईडी और क्लाइंट सीक्रेट शामिल हैं.

To view the client ID and client secret for a given OAuth 2.0 credential, click the following text: Select credential. In the window that opens, choose your project and the credential you want, then click View.

Or, view your client ID and client secret from the Credentials page in API Console:

1. Go to the Credentials page.
2. Click the name of your credential or the pencil (create) icon. Your client ID and secret are at the top of the page.

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

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

किसी दिए गए OAuth 2.0 क्रेडेंशियल के लिए रीडायरेक्ट URI को बनाने, देखने या संपादित करने के लिए, निम्नलिखित करें:

1. Go to the Credentials page.
2. पृष्ठ के OAuth 2.0 क्लाइंट आईडी अनुभाग में, एक क्रेडेंशियल पर क्लिक करें।
3. अनुप्रेषित URI को देखें या संपादित करें।

यदि क्रेडेंशियल पेज पर कोई OAuth 2.0 क्लाइंट आईडी अनुभाग नहीं है, तो आपकी परियोजना में कोई OAuth क्रेडेंशियल नहीं है। एक बनाने के लिए, क्रेडेंशियल्स बनाएँ पर क्लिक करें ।

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

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

उपयोगकर्ता की सहमति वाली स्क्रीन पर, ब्रैंडिंग की जानकारी भी दिखती है. जैसे, आपके प्रॉडक्ट का नाम, लोगो, और होम पेज का यूआरएल. 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 Playground का इस्तेमाल करके जनरेट किया गया था. इसलिए, इसमें ब्रैंडिंग की जानकारी शामिल नहीं है, जो API Consoleमें सेट की जाएगी.)

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

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

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

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

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

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

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

सर्वर फ़्लो

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

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

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

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

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

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

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

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

# 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, पहले चरण में बनाए गए आपके सेशन टोकन से मैच करता है या नहीं. राउंड-ट्रिप पुष्टि करने की इस सुविधा से, यह पक्का करने में मदद मिलती है कि अनुरोध, उपयोगकर्ता ने किया है, न कि नुकसान पहुंचाने वाली स्क्रिप्ट ने.

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

// 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);
}

// 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.");
}

# 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 बॉडी में ये पैरामीटर शामिल होने चाहिए:

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

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 कलेक्शन में ये फ़ील्ड शामिल होते हैं:

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 आईडी टोकन में ये फ़ील्ड (जिन्हें दावे कहा जाता है) शामिल हो सकते हैं:

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 पुष्टि करने वाले एपीआई के ज़रिए स्वीकार किए गए पैरामीटर के बारे में ज़्यादा जानकारी दी गई है.

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

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

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

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

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

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

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

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

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

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

   scope=openid%20profile%20email

2. ऑथराइज़ेशन हेडर में अपना ऐक्सेस टोकन जोड़ें और 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 को लागू करना आसान बनाती हैं:

• Java के लिए Google APIs क्लाइंट लाइब्रेरी
• Python के लिए Google APIs क्लाइंट लाइब्रेरी
• .NET के लिए Google API क्लाइंट लाइब्रेरी
• Ruby के लिए Google API क्लाइंट लाइब्रेरी
• PHP के लिए Google APIs क्लाइंट लाइब्रेरी
• Google Web Toolkit के लिए OAuth 2.0 लाइब्रेरी
• Mac के लिए Google Toolbox OAuth 2.0 कंट्रोलर

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

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