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

OpenSSL कनेक्ट

Google का OpenID Connect एंडपॉइंट, OpenID से प्रमाणित है.

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

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

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 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उपयोगकर्ता की पुष्टि की जा रही है

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

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

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

सर्वर फ़्लो

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

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

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

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

PHP

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

Java

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

Python

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

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

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

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

असली अनुरोध नीचे दिए गए उदाहरण की तरह दिख सकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उन्नत विषय

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

अन्य Google 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 ऑथेंटिकेशन एपीआई ने स्वीकार किया है.

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

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

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

अपने सर्वर पर आईडी टोकन भेजने के कुछ सामान्य उदाहरण यहां दिए गए हैं:

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

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

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

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

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

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

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

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

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

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

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

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

अगर आपको उपयोगकर्ता का ईमेल पता शामिल करना है, तो email के लिए एक अतिरिक्त स्कोप वैल्यू तय की जा सकती है. profile और email, दोनों के बारे में बताने के लिए, अपने पुष्टि करने के अनुरोध यूआरआई में यह पैरामीटर शामिल किया जा सकता है:
```
scope=openid%20profile%20email
```
अनुमति देने वाले हेडर में अपना ऐक्सेस टोकन जोड़ें. इसके बाद, 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 को लागू करना आसान बना देती हैं:

OpenID Connect का अनुपालन

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

OpenSSL कनेक्ट

OAuth 2.0 सेट अप करना

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

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

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

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

उपयोगकर्ता की पुष्टि की जा रही है

सर्वर फ़्लो

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

PHP

Java

Python

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

3. एंटी-फ़ोरगरी स्टेट टोकन की पुष्टि करें

PHP

Java

Python

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

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

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

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

उन्नत विषय

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

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

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

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

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

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

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

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

OpenID Connect का अनुपालन

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