OpenSSL कनेक्ट

Google के OAuth 2.0 API का इस्तेमाल, पुष्टि करने और अनुमति देने, दोनों के लिए किया जा सकता है. इस दस्तावेज़ में, पुष्टि करने के लिए हमारे 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 की पुष्टि करने वाले सिस्टम का इस्तेमाल करे, आपको OAuth 2.0 क्रेडेंशियल पाने के लिए Google API Console में एक प्रोजेक्ट सेट अप करना होगा. साथ ही, एक रीडायरेक्ट यूआरआई सेट करना होगा और (ज़रूरी नहीं) ब्रैंडिंग की उस जानकारी को पसंद के मुताबिक बनाना होगा जो आपके उपयोगकर्ताओं को उपयोगकर्ता की सहमति वाली स्क्रीन पर दिखती है. 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. अपने क्रेडेंशियल या पेंसिल ( create ) आइकन के नाम पर क्लिक करें। आपकी क्लाइंट आईडी और रहस्य पृष्ठ के शीर्ष पर हैं।

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

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

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

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

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

एपीआई ऐक्सेस के अनुरोध में, code एक्सचेंज के दौरान रीफ़्रेश टोकन पाने का अनुरोध किया जा सकता है. रीफ़्रेश टोकन से आपके ऐप्लिकेशन को Google API का लगातार ऐक्सेस मिलता है, जब उपयोगकर्ता आपके ऐप्लिकेशन में मौजूद नहीं होता. रीफ़्रेश टोकन का अनुरोध करने के लिए, अपने पुष्टि करने के अनुरोध में 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 का रेफ़रंस दिया जाएगा. अगर टोकन सिग्नेचर मान्य है, तो रिस्पॉन्स के तौर पर JWT पेलोड अपने डिकोड किए गए JSON ऑब्जेक्ट फ़ॉर्म में होगा.

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

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

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

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

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

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

   scope=openid%20profile%20email

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

खोज के लिए दस्तावेज़

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

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

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

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

यहां इस तरह के दस्तावेज़ का उदाहरण दिया गया है. फ़ील्ड के नाम वे हैं जिनके बारे में 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 को लागू करना आसान बना देती हैं:

• Java के लिए Google API क्लाइंट लाइब्रेरी
• Python के लिए Google API क्लाइंट लाइब्रेरी
• .NET के लिए Google API क्लाइंट लाइब्रेरी
• Ruby के लिए Google API क्लाइंट लाइब्रेरी
• PHP के लिए Google API क्लाइंट लाइब्रेरी
• Google Web Toolkit के लिए OAuth 2.0 लाइब्रेरी
• Mac OAuth 2.0 नियंत्रकों के लिए Google टूलबॉक्स

OpenID Connect का अनुपालन

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