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

OpenGL कनेक्ट

Google's OAuth 2.0 एपीआई का इस्तेमाल, पुष्टि करने और अनुमति देने, दोनों के लिए किया जा सकता है. इस दस्तावेज़ में, OAuth 2.0 को लागू करने के बारे में बताया गया है. यह पुष्टि करने के लिए, OpenID Connect की शर्तों को पूरा करता है और OpenID सर्टिफ़ाइड है. Google के एपीआई ऐक्सेस करने के लिए, OAuth 2.0 का इस्तेमाल करने से जुड़े दस्तावेज़, इस सेवा पर भी लागू होते हैं. अगर आप इस प्रोटोकॉल को इंटरैक्टिव तरीके से एक्सप्लोर करना चाहते हैं, तो हमारा सुझाव है कि आप Google OAuth 2.0 Playground का इस्तेमाल करें. Stack Overflow पर मदद पाने के लिए, अपने सवालों को #39;google-oauth' के साथ टैग करें.

OAuth 2.0 सेट अप करना

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

To create, view, or edit the redirect URIs for a given OAuth 2.0 credential, do the following:

Go to the Credentials page.
In the OAuth 2.0 client IDs section of the page, click a credential.
View or edit the redirect URIs.

If there is no OAuth 2.0 client IDs section on the Credentials page, then your project has no OAuth credentials. To create one, click Create credentials.

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

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

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

To enable your project's consent screen:

Open the Consent Screen page in the Google API Console.
If prompted, select a project, or create a new one.
Fill out the form and click Save.

यहां दिया गया सहमति डायलॉग दिखाता है कि अनुरोध में OAuth 2.0 और Google Drive के स्कोप के कॉम्बिनेशन मौजूद होने पर, उपयोगकर्ता को क्या दिखेगा. (यह सामान्य डायलॉग, Google OAuth 2.0 प्लेग्राउंड का इस्तेमाल करके जनरेट किया गया था. इसलिए, इसमें ऐसे ब्रैंड की जानकारी शामिल नहीं है जिसे 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 संगठन से जुड़े किसी खास डोमेन के उपयोगकर्ताओं के लिए, Open Connect फ़्लो ऑप्टिमाइज़ करें. (hd पर ज़्यादा पढ़ें.)

यहां पर एक पेज, Open 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, आपके कदम 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`	दिए गए `client_id` के लिए, एक ऐसा आधिकारिक यूआरआई यूआरआई जिसे API Consoleमें Credentials pageके बारे में बताया गया है, जैसा कि रीडायरेक्ट यूआरआई सेट करना में बताया गया है.
`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 को पार्स करने के काम के साथ काम करती हैं. इसलिए, हो सकता है कि आप आईडी टोकन में मिलने वाले दावों को ऐक्सेस करते ही, टोकन की पुष्टि कर लें.

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

आईडी टोकन एक 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` का इस्तेमाल, उपयोगकर्ता की खास पहचानकर्ता कुंजी के तौर पर करें. केस-सेंसिटिव ASCII वर्णों की ज़्यादा से ज़्यादा 255 वर्ण.
`at_hash`		ऐक्सेस टोकन हैश. इस बात की पुष्टि करता है कि ऐक्सेस टोकन, पहचान टोकन से जुड़ा है. अगर आईडी फ़्लो को सर्वर फ़्लो में `access_token` वैल्यू के साथ जारी किया जाता है, तो यह दावा हमेशा शामिल होता है. इस दावे का इस्तेमाल, दूसरे तरीकों से किए जाने वाले धोखाधड़ी के हमलों से बचने के लिए, दूसरे तरीके के तौर पर किया जा सकता है. हालांकि, अगर आप पहले चरण और कदम 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`	(ज़रूरी है)	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 में सेट किया है. इसमें एचटीटीपी या एचटीटीपीएस स्कीम, केस, और पीछे के यूआरएल #39;/' (अगर कोई हो) शामिल हैं.
`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 एपीआई का इस्तेमाल करना चाहते हैं उसके दस्तावेज़ देखें.
`state`	(ज़रूरी नहीं, लेकिन खास तौर पर सुझाया गया)	एक अपारदर्शिता स्ट्रिंग जो प्रोटोकॉल में राउंड-ट्रिप होती है; यानी, इसे बुनियादी फ़्लो में यूआरआई पैरामीटर के रूप में और इंप्लिसिट फ़्लो में यूआरआई `#fragment` आइडेंटिफ़ायर के रूप में दिखाया जाता है. `state`, एक-दूसरे से जुड़े अनुरोधों और जवाबों के साथ काम आ सकता है. `state` की वैल्यू का इस्तेमाल करके, `redirect_uri` के बारे में अनुमान लगाया जा सकता है. इससे, यह पक्का करने में मदद मिलती है कि आने वाला कनेक्शन, ऐप्लिकेशन से शुरू किए गए पुष्टि करने के अनुरोध का नतीजा है. अगर आपने इस रैंडम वैरिएबल में कोई स्ट्रिंग जनरेट की है या कुछ क्लाइंट स्टेटस (उदाहरण के लिए, कुकी) का हैश एन्कोड किया है, तो एक ही ब्राउज़र में अनुरोध और रिस्पॉन्स की पुष्टि करने के लिए भी रिस्पॉन्स की पुष्टि की जा सकती है. इससे क्रॉस-साइट अनुरोध और धोखाधड़ी जैसे हमलों से सुरक्षा मिलती है.
`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 स्टैंडर्ड का इस्तेमाल कर सकते हैं:

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

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

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

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

लागू करने की प्रोसेस को आसान बनाने और ज़्यादा सुविधाजनक तरीके से काम करने के लिए, Open Connect को एक मशहूर जगह और Google की OpenConnect सेवा के लिए डिस्कवरी दस्तावेज़ यहां से हासिल किया जा सकता है:

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

{
  "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 की खास सुविधाओं के लिए, ज़रूरी सुविधाओं के साथ काम करता है. ऐसे सभी क्लाइंट जिन्हें Open Connect के साथ काम करने के लिए डिज़ाइन किया गया है, उन्हें इस सेवा के साथ काम करना चाहिए (OpenID अनुरोध ऑब्जेक्ट के अपवाद के बिना).

OpenGL कनेक्ट

OAuth 2.0 सेट अप करना

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

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

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

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

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

सर्वर फ़्लो

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

PHP

Java

Python

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

3. जालसाज़ी की स्थिति वाले टोकन की पुष्टि करें

PHP

Java

Python

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

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

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

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

उन्नत विषय

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

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

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

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

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

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

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

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

OpenID Connect अनुपालन

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