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

OpenGL कनेक्ट

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

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 के एपीआई को ऐक्सेस किया जा सके.

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

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

Go to the Credentials page.
Click the name of your credential or the pencil () icon. Your client ID and secret are at the top of the 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 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 स्ट्रिंग है. इसलिए, अच्छी क्वालिटी के रैंडम नंबर जनरेटर का इस्तेमाल करके वर्ण बनाए जाते हैं. दूसरा, हैश के तौर पर आपके कुछ सेशन की स्थिति वाले वैरिएबल पर साइन किया जाता है. इस कुंजी को आपके बैकएंड पर गुप्त रखा जाता है.

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

129

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

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

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

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

129

// 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 वेब टोकन) होता है. यह क्रिप्टोग्राफ़िक तरीके से साइन किया गया Base64 कोड में बदला गया JSON ऑब्जेक्ट होता है. आम तौर पर, आपको आईडी का इस्तेमाल करने से पहले ही, आईडी टोकन की पुष्टि करना ज़रूरी होता है. हालांकि, सीधे 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` स्कोप वैल्यू शामिल हो.
`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`	(ज़रूरी है)	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` दावे शामिल होते हैं. इन OpenSSL-खास स्कोप के अलावा, आपके स्कोप आर्ग्युमेंट में दूसरी स्कोप वैल्यू भी शामिल की जा सकती हैं. दायरे की सभी वैल्यू, स्पेस से अलग की गई होनी चाहिए. उदाहरण के लिए, अगर आपको किसी उपयोगकर्ता के 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=`. आपका ऐप्लिकेशन कौन ऐक्सेस कर सकता है, इसे कंट्रोल करने के लिए, इस यूज़र इंटरफ़ेस (यूआई) ऑप्टिमाइज़ेशन पर भरोसा न करें. क्लाइंट-साइड अनुरोधों में बदलाव किए जा सकते हैं. यह पक्का करें कि पुष्टि की गई हो कि लौटाए गए आईडी टोकन की `hd` वैल्यू, आपकी उम्मीद से मेल खाती हो (जैसे कि `mycolledge.edu`). अनुरोध पैरामीटर के उलट, आईडी टोकन `hd` का दावा Google के सुरक्षा टोकन में शामिल होता है. इसलिए, वैल्यू पर भरोसा किया जा सकता है.
`include_granted_scopes`	(ज़रूरी नहीं)	अगर यह पैरामीटर `true` वैल्यू के साथ दिया गया है और अनुमति देने का अनुरोध किया गया है, तो अनुमति में अन्य दायरों के लिए, इस उपयोगकर्ता/ऐप्लिकेशन कॉम्बिनेशन को पहले दी गई अनुमतियां शामिल होंगी. इंक्रीमेंटल ऑथराइज़ेशन देखें. ध्यान रखें कि इंस्टॉल किए गए ऐप्लिकेशन फ़्लो की मदद से, इंक्रीमेंटल ऑथराइज़ेशन नहीं किया जा सकता.
`login_hint`	(ज़रूरी नहीं)	जब आपके ऐप्लिकेशन को यह पता चल जाता है कि किस उपयोगकर्ता की पुष्टि करने की कोशिश की जा रही है, तो इस पैरामीटर से पुष्टि करने वाले सर्वर को मदद मिल सकती है. इस संकेत को पास करने से खाता चुनने वाले को रोक दिया जाता है या साइन इन फ़ॉर्म में ईमेल बॉक्स को पहले से भर दिया जाता है या सही सेशन (अगर उपयोगकर्ता एक से ज़्यादा साइन इन का इस्तेमाल कर रहा है) चुनता है, जो आपके ऐप्लिकेशन को गलत उपयोगकर्ता खाते में लॉग इन करने पर होने वाली समस्याओं से बचने में मदद कर सकता है. वैल्यू एक ईमेल पता या `sub` स्ट्रिंग हो सकती है, जो उपयोगकर्ता के Google आईडी के बराबर होती है.
`prompt`	(ज़रूरी नहीं)	यह स्ट्रिंग वैल्यू की खाली जगह की सूची होती है, जिसमें यह बताया जाता है कि ऑथराइज़ेशन सर्वर, उपयोगकर्ता को फिर से पुष्टि करने और सहमति देने के लिए कहता है या नहीं. ये वैल्यू हो सकती हैं: `none` अनुमति देने वाला सर्वर, पुष्टि करने या उपयोगकर्ता की सहमति से जुड़ी स्क्रीन नहीं दिखाता है. अगर उपयोगकर्ता की पुष्टि नहीं की गई है और अनुरोध किए गए दायरों के लिए पहले से कॉन्फ़िगर नहीं की गई है, तो यह गड़बड़ी वाला मैसेज दिखाएगा. मौजूदा पुष्टि और/या सहमति की जांच करने के लिए, `none` का इस्तेमाल किया जा सकता है. `consent` अनुमति देने वाला सर्वर, क्लाइंट को जानकारी वापस करने से पहले, उपयोगकर्ता की सहमति लेने का अनुरोध करता है. `select_account` ऑथराइज़ेशन सर्वर, उपयोगकर्ता को उपयोगकर्ता खाता चुनने का अनुरोध करता है. इससे, उपयोगकर्ता को अनुमति देने वाले सर्वर पर एक से ज़्यादा खाते चुने जा सकते हैं. साथ ही, कई खातों में से किसी एक को चुना जा सकता है. अगर कोई वैल्यू तय नहीं की गई है और उपयोगकर्ता ने पहले ऐक्सेस को अनुमति नहीं दी है, तो उपयोगकर्ता को सहमति वाली स्क्रीन दिखाई जाती है.

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

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

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

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

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

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

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

पुष्टि करें कि आईडी टोकन जारी करने वाले ने सही से हस्ताक्षर किया है. 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 स्टैंडर्ड का इस्तेमाल करने का विकल्प है:

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

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

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

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

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

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

Google की OpenGL 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 डिस्कवरी के असल दस्तावेज़ के नए वर्शन से कॉपी किया जाता है:

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

OpenSSL Connect की शर्तों का पालन

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

OpenGL कनेक्ट

OAuth 2.0 सेट अप करना

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

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

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

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

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

सर्वर फ़्लो

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

129

Java

Python

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

3. नकली इन्वेंट्री की पुष्टि करने वाले टोकन की पुष्टि करें

129

Java

Python

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

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

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

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

उन्नत विषय

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

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

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

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

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

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

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

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

OpenSSL Connect की शर्तों का पालन

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