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

OpenGL कनेक्ट

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

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 क्रेडेंशियल पाना

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

किसी दिए गए 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 सेवाएं और Google क्लाइंट लाइब्रेरी. ये अलग-अलग प्लैटफ़ॉर्म के लिए उपलब्ध हैं.

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

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

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

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

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

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

सर्वर फ़्लो

पक्का करें कि आपने 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 पर ज़्यादा पढ़ें.)
hd क्लाउड पैरामीटर का इस्तेमाल करके, Google Cloud संगठन से जुड़े किसी खास डोमेन के उपयोगकर्ताओं के लिए OpenConnect कनेक्ट करें. (hd पर ज़्यादा पढ़ें.)

यहां पढ़ने के लिए, हर पंक्ति में खाली जगह और खाली जगह के साथ, कनेक्ट किए गए OAuth यूआरआई का एक उदाहरण दिया गया है:

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

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

PHP

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

Java

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

Python

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

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

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

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

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

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

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

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

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

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

आईडी टोकन एक JWT (JSON वेब टोकन) होता है. यह क्रिप्टोग्राफ़िक हस्ताक्षर वाला JSON6 ऑब्जेक्ट है. आम तौर पर, इस्तेमाल करने से पहले ज़रूरी है कि आप किसी आईडी टोकन की पुष्टि करें. हालांकि, सीधे 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` वैल्यू के साथ जारी किया जाता है, तो यह दावा हमेशा शामिल होगा. इस दावे का इस्तेमाल, क्रॉस-साइट अनुरोध के जालसाज़ी से बचने के लिए, दूसरे तरीके के तौर पर किया जा सकता है. हालांकि, अगर आप कदम 1 और कदम 3 का पालन करते हैं, तो ऐक्सेस टोकन की पुष्टि करना ज़रूरी नहीं है.
`azp`		आधिकारिक प्रज़ेंटर का `client_id`. इस दावे की ज़रूरत सिर्फ़ तब होती है, जब आईडी टोकन का अनुरोध करने वाला पक्ष, आईडी टोकन की ऑडियंस के बराबर न हो. Google पर हाइब्रिड ऐप्लिकेशन बनाने के मामले में ऐसा हो सकता है. ऐसे वेब ऐप्लिकेशन और Android ऐप्लिकेशन का OAuth 2.0 `client_id` अलग-अलग होता है. हालांकि, दोनों के लिए एक जैसा Google API प्रोजेक्ट शेयर होता है.
`email`		उपयोगकर्ता का ईमेल पता. हो सकता है कि यह वैल्यू यूनीक न हो और मुख्य कुंजी के तौर पर इस्तेमाल करने के लिए सही न हो. सिर्फ़ तब दिया जाता है जब आपके दायरे में, `email` के दायरे की वैल्यू शामिल होती है.
`email_verified`		सही है, अगर उपयोगकर्ता के ईमेल पते की पुष्टि हो चुकी है, नहीं तो गलत है.
`family_name`		उपयोगकर्ता का उपनाम या उपनाम. `name` का दावा होने पर दिया जा सकता है.
`given_name`		उपयोगकर्ता का नाम या पहला नाम. `name` का दावा होने पर दिया जा सकता है.
`hd`		उपयोगकर्ता के Google Cloud संगठन से जुड़ा डोमेन. सिर्फ़ तब दिया जाता है, जब उपयोगकर्ता किसी Google Cloud संगठन से जुड़ा हो.
`locale`		उपयोगकर्ता की भाषा, जिसे BCP 47 भाषा वाले टैग से दिखाया जाता है. यह तब दिया जा सकता है, जब `name` दावा मौजूद हो.
`name`		दिखाई देने वाले फ़ॉर्म में उपयोगकर्ता का पूरा नाम. इन स्थितियों में जानकारी दी जा सकती है: अनुरोध के दायरे में, "प्रोफ़ाइल" स्ट्रिंग शामिल थी आईडी रीफ़्रेश करने के लिए, टोकन रीफ़्रेश किया जाता है `name` दावों के मौजूद होने पर, उनका इस्तेमाल अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट करने के लिए किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
`nonce`		पुष्टि करने के अनुरोध में, आपके ऐप्लिकेशन से मिला `nonce` का मान. आपको रीप्ले हमलों से बचने के लिए, यह ज़रूरी है कि वीडियो को सिर्फ़ एक बार प्रज़ेंट किया जा रहा हो.
`picture`		उपयोगकर्ता की प्रोफ़ाइल फ़ोटो का यूआरएल. इन स्थितियों में जानकारी दी जा सकती है: अनुरोध के दायरे में, "प्रोफ़ाइल" स्ट्रिंग शामिल थी आईडी रीफ़्रेश करने के लिए, टोकन रीफ़्रेश किया जाता है `picture` दावों के मौजूद होने पर, उनका इस्तेमाल अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट करने के लिए किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.
`profile`		उपयोगकर्ता के प्रोफ़ाइल पेज का यूआरएल. इन स्थितियों में जानकारी दी जा सकती है: अनुरोध के दायरे में, "प्रोफ़ाइल" स्ट्रिंग शामिल थी आईडी रीफ़्रेश करने के लिए, टोकन रीफ़्रेश किया जाता है `profile` दावों के मौजूद होने पर, उनका इस्तेमाल अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड को अपडेट करने के लिए किया जा सकता है. ध्यान दें कि इस दावे के मौजूद होने की कोई गारंटी नहीं है.

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

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

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

उन्नत विषय

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

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

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

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

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

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

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

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

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

आईडी टोकन की पुष्टि करने के लिए कई चरणों का पालन करना होगा:

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

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

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

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

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

उपयोगकर्ता की प्रोफ़ाइल से जुड़ी जानकारी हासिल की जा रही है

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

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

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

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

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

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

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

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

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

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

OpenConnect का अनुपालन

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

OpenGL कनेक्ट

OAuth 2.0 सेट अप करना

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

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

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

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

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

सर्वर फ़्लो

1. एक एंटी-नकली राज्य टोकन बनाएं

PHP

Java

Python

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

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

PHP

Java

Python

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

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

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

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

उन्नत विषय

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

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

फिर से सहमति देने का अनुरोध करना

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

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

उपयोगकर्ता की प्रोफ़ाइल से जुड़ी जानकारी हासिल की जा रही है

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

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

OpenConnect का अनुपालन

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