OpenID कनेक्ट

Google का OpenID Connect एंडपॉइंट, OpenID सर्टिफ़ाइड है.

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

OAuth 2.0 सेट अप करना

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

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

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

किसी OAuth 2.0 क्रेडेंशियल के लिए क्लाइंट आईडी और क्लाइंट सीक्रेट देखने के लिए, यहां दिए गए टेक्स्ट पर क्लिक करें: क्रेडेंशियल चुनें. खुलने वाली विंडो में, अपना प्रोजेक्ट और अपनी पसंद के क्रेडेंशियल चुनें. इसके बाद, देखें पर क्लिक करें.

इसके अलावा,Cloud Consoleमें जाकर Clients page में अपना क्लाइंट आईडी और क्लाइंट सीक्रेट देखें:

  1. Go to the Clients page.
  2. अपने क्लाइंट के नाम या बदलाव करें () आइकॉन पर क्लिक करें. आपका क्लाइंट आईडी और सीक्रेट, पेज पर सबसे ऊपर मौजूद होता है.

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

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

किसी OAuth 2.0 क्रेडेंशियल के लिए, रीडायरेक्ट यूआरआई बनाने, देखने या उनमें बदलाव करने के लिए, यह तरीका अपनाएं:

  1. Go to the Clients page.
  2. क्लाइंट पर क्लिक करें.
  3. रीडायरेक्ट यूआरआई देखें या उनमें बदलाव करें.

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

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

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

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

अपने प्रोजेक्ट के लिए सहमति वाली स्क्रीन चालू करने के लिए:

  1. Google Cloud Consoleमें Branding page खोलें.
  2. If prompted, select a project, or create a new one.
  3. फ़ॉर्म भरें और सेव करें पर क्लिक करें.

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

सहमति पेज का उदाहरण
पहली इमेज. सहमति वाले पेज का स्क्रीनशॉट

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

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

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

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

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

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

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

सर्वर फ़्लो

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

  1. फ़र्ज़ीवाड़े को रोकने के लिए स्टेट टोकन बनाना
  2. Google को पुष्टि करने का अनुरोध भेजना
  3. फ़र्ज़ीवाड़े से रोकने के लिए इस्तेमाल किए जाने वाले स्टेट टोकन की पुष्टि करना
  4. ऐक्सेस टोकन और आईडी टोकन के लिए code को एक्सचेंज करना
  5. आईडी टोकन से उपयोगकर्ता की जानकारी पाना
  6. उपयोगकर्ता की पुष्टि करना

1. फ़र्ज़ीवाड़े से रोकने वाला स्टेट टोकन बनाना

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

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

नीचे दिए गए कोड से, यूनीक सेशन टोकन जनरेट करने का तरीका पता चलता है.

PHP

इस उदाहरण का इस्तेमाल करने के लिए, आपको PHP के लिए Google APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// 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 APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// 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 APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

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

यहां OpenID Connect ऑथेंटिकेशन यूआरआई का पूरा उदाहरण दिया गया है. इसमें पढ़ने में आसानी हो, इसके लिए लाइन ब्रेक और स्पेस का इस्तेमाल किया गया है:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

अगर आपका ऐप्लिकेशन, लोगों से उनकी कोई नई जानकारी मांगता है या उनके खाते का ऐक्सेस मांगता है, तो उन्हें सहमति देनी होगी. ऐसा तब भी करना होगा, जब उन्होंने पहले इस ऐक्सेस को मंज़ूरी न दी हो.

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

जवाब उस redirect_uri को भेजा जाता है जिसे आपने request में बताया है. सभी जवाब, क्वेरी स्ट्रिंग में दिखाए जाते हैं:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

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

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

PHP

इस उदाहरण का इस्तेमाल करने के लिए, आपको PHP के लिए Google APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// 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

इस उदाहरण का इस्तेमाल करने के लिए, आपको Java के लिए Google APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

// 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

इस उदाहरण का इस्तेमाल करने के लिए, आपको Python के लिए Google APIs क्लाइंट लाइब्रेरी डाउनलोड करनी होगी.

# 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 Cloud Console Clients pageसे मिला क्लाइंट आईडी. इसके बारे में OAuth 2.0 क्रेडेंशियल पाना लेख में बताया गया है.
client_secret यह वह क्लाइंट सीक्रेट होता है जो आपको Cloud Console Clients pageसे मिलता है. इसके बारे में OAuth 2.0 क्रेडेंशियल पाना लेख में बताया गया है.
redirect_uri client_id के लिए, अनुमति दिया गया रीडायरेक्ट यूआरआई. यह Cloud Consoleमें बताया गया है. साथ ही, Clients 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 से HTTPS चैनल के ज़रिए कम्यूनिकेट कर रहे हैं. साथ ही, Google पर अपनी पहचान की पुष्टि करने के लिए, अपने क्लाइंट सीक्रेट का इस्तेमाल कर रहे हैं. इसलिए, आपको भरोसा हो सकता है कि आपको मिला टोकन, Google से मिला है और मान्य है. अगर आपका सर्वर, ऐप्लिकेशन के अन्य कॉम्पोनेंट को आईडी टोकन पास करता है, तो यह बहुत ज़रूरी है कि अन्य कॉम्पोनेंट, टोकन का इस्तेमाल करने से पहले टोकन की पुष्टि करें.

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

name के दावे मौजूद होने पर, उनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड अपडेट किए जा सकते हैं. ध्यान दें कि यह दावा हमेशा मौजूद नहीं होता.
nonce पुष्टि करने के अनुरोध में, आपके ऐप्लिकेशन से दी गई nonce की वैल्यू. आपको इस वैल्यू को सिर्फ़ एक बार दिखाकर, रीप्ले अटैक से बचना चाहिए.
picture उपयोगकर्ता की प्रोफ़ाइल फ़ोटो का यूआरएल. यह एट्रिब्यूट तब सबमिट किया जा सकता है, जब:
  • अनुरोध के स्कोप में "profile" स्ट्रिंग शामिल थी
  • यह आईडी टोकन, टोकन रीफ़्रेश करने पर मिलता है

picture के दावे मौजूद होने पर, इनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड अपडेट किए जा सकते हैं. ध्यान दें कि यह दावा हमेशा मौजूद नहीं होता.
profile उपयोगकर्ता की प्रोफ़ाइल पेज का यूआरएल. यह एट्रिब्यूट तब सबमिट किया जा सकता है, जब:
  • अनुरोध के स्कोप में "profile" स्ट्रिंग शामिल थी
  • यह आईडी टोकन, टोकन रीफ़्रेश करने पर मिलता है

profile के दावे मौजूद होने पर, इनका इस्तेमाल करके अपने ऐप्लिकेशन के उपयोगकर्ता रिकॉर्ड अपडेट किए जा सकते हैं. ध्यान दें कि यह दावा हमेशा मौजूद नहीं होता.

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

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

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

उन्नत विषय

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

Google के अन्य एपीआई का ऐक्सेस

पुष्टि करने के लिए OAuth 2.0 का इस्तेमाल करने का एक फ़ायदा यह है कि आपका ऐप्लिकेशन, उपयोगकर्ता की पुष्टि करने के साथ-साथ, उपयोगकर्ता की ओर से Google के अन्य एपीआई (जैसे कि 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 APIs प्रोजेक्ट को दिए गए हों. इस वजह से, prompt=consent को सिर्फ़ तब शामिल करें, जब ज़रूरी हो.

prompt पैरामीटर के बारे में ज़्यादा जानने के लिए, पुष्टि करने के यूआरआई पैरामीटर टेबल में prompt देखें.

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

यहां दी गई टेबल में, Google के OAuth 2.0 ऑथेंटिकेशन एपीआई के ज़रिए स्वीकार किए गए पैरामीटर के बारे में ज़्यादा जानकारी दी गई है.

पैरामीटर ज़रूरी है ब्यौरा
client_id (ज़रूरी है) क्लाइंट आईडी स्ट्रिंग, जिसे Cloud Console Clients pageसे हासिल किया जाता है. इसके बारे में OAuth 2.0 क्रेडेंशियल पाना लेख में बताया गया है.
nonce (ज़रूरी है) आपके ऐप्लिकेशन से जनरेट की गई कोई रैंडम वैल्यू, जो रीप्ले प्रोटेक्शन की सुविधा चालू करती है.
response_type (ज़रूरी है) अगर वैल्यू code है, तो बेसिक ऑथराइज़ेशन कोड फ़्लो लॉन्च करता है. इसके लिए, टोकन एंडपॉइंट को POST की ज़रूरत होती है, ताकि टोकन मिल सकें. अगर वैल्यू token id_token या id_token token है, तो इंप्लिसिट फ़्लो लॉन्च करता है. इसके लिए, रीडायरेक्ट यूआरआई पर JavaScript का इस्तेमाल करना ज़रूरी है, ताकि यूआरआई #fragment आइडेंटिफ़ायर से टोकन वापस पाए जा सकें.
redirect_uri (ज़रूरी है) इस कुकी से यह तय होता है कि जवाब कहां भेजा जाएगा. इस पैरामीटर की वैल्यू, रीडायरेक्ट करने के लिए सेट की गई मान्य वैल्यू में से किसी एक से पूरी तरह मेल खानी चाहिए. ये वैल्यू, Cloud Console Clients page में सेट की जाती हैं. इनमें एचटीटीपी या एचटीटीपीएस स्कीम, केस, और आखिर में '/' शामिल है.
scope (ज़रूरी है)

स्कोप पैरामीटर की वैल्यू openid से शुरू होनी चाहिए. इसके बाद, इसमें profile वैल्यू, email वैल्यू या दोनों शामिल होनी चाहिए.

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

अगर email स्कोप वैल्यू मौजूद है, तो आईडी टोकन में email और email_verified दावे शामिल होते हैं.

OpenID के लिए तय किए गए इन स्कोप के अलावा, स्कोप आर्ग्युमेंट में अन्य स्कोप वैल्यू भी शामिल की जा सकती हैं. स्कोप की सभी वैल्यू को स्पेस से अलग किया जाना चाहिए. उदाहरण के लिए, अगर आपको किसी उपयोगकर्ता के Google Drive में मौजूद हर फ़ाइल का ऐक्सेस चाहिए, तो आपका स्कोप पैरामीटर openid profile email https://www.googleapis.com/auth/drive.file हो सकता है.

उपलब्ध स्कोप के बारे में जानकारी पाने के लिए, Google APIs के लिए OAuth 2.0 के स्कोप या उस Google API का दस्तावेज़ देखें जिसका आपको इस्तेमाल करना है.
state (ज़रूरी नहीं, लेकिन इसका सुझाव दिया जाता है)

यह एक ओपेक स्ट्रिंग है, जो प्रोटोकॉल में राउंड-ट्रिप की जाती है. इसका मतलब है कि इसे बेसिक फ़्लो में यूआरआई पैरामीटर के तौर पर दिखाया जाता है. साथ ही, इसे इंप्लिसिट फ़्लो में यूआरआई #fragment आइडेंटिफ़ायर के तौर पर दिखाया जाता है.

state, अनुरोधों और जवाबों को आपस में जोड़ने के लिए मददगार हो सकता है. आपकी redirect_uri का अनुमान लगाया जा सकता है. इसलिए, state वैल्यू का इस्तेमाल करने से, आपको यह भरोसा मिल सकता है कि आने वाला कनेक्शन, आपके ऐप्लिकेशन से शुरू की गई पुष्टि करने की किसी अनुरोध का नतीजा है.अगर इस state वैरिएबल में कोई रैंडम स्ट्रिंग जनरेट की जाती है या क्लाइंट की किसी स्थिति (जैसे, कुकी) के हैश को एन्कोड किया जाता है, तो जवाब की पुष्टि की जा सकती है. इससे यह पुष्टि की जा सकती है कि अनुरोध और जवाब, एक ही ब्राउज़र से मिले हैं. इससे, किसी दूसरी साइट से किए जाने वाले फ़र्ज़ी अनुरोध जैसे हमलों से सुरक्षा मिलती है.
access_type (ज़रूरी नहीं) offline और online को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. इसका असर ऑफ़लाइन ऐक्सेस में बताया गया है. अगर ऐक्सेस टोकन का अनुरोध किया जा रहा है, तो क्लाइंट को रीफ़्रेश टोकन तब तक नहीं मिलता, जब तक कि offline की वैल्यू तय नहीं की जाती.
claims (ज़रूरी नहीं) claims पैरामीटर का इस्तेमाल, एक या उससे ज़्यादा वैकल्पिक फ़ील्ड तय करने के लिए किया जाता है. इन्हें userinfo एंडपॉइंट या पुष्टि करने के अनुरोध वाले आईडी टोकन के जवाब के टाइप में शामिल किया जाता है. यह वैल्यू, एक JSON ऑब्जेक्ट है. इसमें रिस्पॉन्स टाइप और अनुरोध किए गए दावे शामिल होते हैं. दावे के ये अनुरोध, Google के सर्वर स्वीकार करते हैं:
दावे के अनुरोध
auth_time यह कुकी, उपयोगकर्ता की पुष्टि किए जाने के आखिरी समय का अनुरोध करती है. आईडी टोकन के जवाब में auth_time को फ़ील्ड के तौर पर दिखाने के लिए, claims अनुरोध पैरामीटर शामिल करें: claims={"id_token":{"auth_time":{"essential":true}}} सेटिंग में चालू होना चाहिए.
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

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

अगर कोई वैल्यू तय नहीं की गई है और उपयोगकर्ता ने पहले ऐक्सेस करने की अनुमति नहीं दी है, तो उपयोगकर्ता को सहमति वाली स्क्रीन दिखाई जाती है.
hl (ज़रूरी नहीं) यह BCP 47 भाषा का टैग है. इसका इस्तेमाल, साइन इन करने, खाता चुनने, और सहमति लेने वाली स्क्रीन के लिए डिसप्ले लैंग्वेज तय करने के लिए किया जाता है. अगर यह पैरामीटर नहीं दिया जाता है, तो भाषा डिफ़ॉल्ट रूप से उपयोगकर्ता के Google खाते या ब्राउज़र की सेटिंग के हिसाब से सेट हो जाती है. उदाहरण के लिए, यूज़र इंटरफ़ेस (यूआई) को ब्रिटिश अंग्रेज़ी में देखने का अनुरोध करने के लिए, पैरामीटर को en-GB पर सेट करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिस्कवरी दस्तावेज़

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

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

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

Google की OpenID 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 Discovery के मौजूदा वर्शन से कॉपी किया गया है:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

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

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

यहां दी गई क्लाइंट लाइब्रेरी, लोकप्रिय फ़्रेमवर्क के साथ इंटिग्रेट करके, OAuth 2.0 को लागू करने की प्रोसेस को आसान बनाती हैं:

OpenID Connect के नियमों का पालन

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