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

OpenID कनेक्ट

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

ध्यान दें:

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

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 में क्लाइंट पेज पर जाकर, अपना क्लाइंट आईडी और क्लाइंट सीक्रेट देखें:

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

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

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

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

क्लाइंट पेज पर जाएं.
क्लाइंट पर क्लिक करें.
रीडायरेक्ट यूआरआई देखें या उनमें बदलाव करें.

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

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

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

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

अपने प्रोजेक्ट की ऐसी स्क्रीन जहां OAuth के लिए सहमति दी जाती है, उसे चालू करने के लिए:

Google Cloud Console में ब्रैंडिंग पेज खोलें.
अगर कहा जाए, तो कोई प्रोजेक्ट चुनें या नया प्रोजेक्ट बनाएं.
फ़ॉर्म भरें और सेव करें पर क्लिक करें.

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

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

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

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

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

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

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

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

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

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

सर्वर फ़्लो

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

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

1. धोखाधड़ी रोकने के लिए स्टेट टोकन बनाना

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

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

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//developers.google.com/oauthplayground&
 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://developers.google.com/oauthplayground?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

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

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

PHP

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

Java

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

Python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

दावा करें	दिया गया	ब्यौरा
`aud`	हमेशा	वह ऑडियंस जिसके लिए यह आईडी टोकन बनाया गया है. यह आपके ऐप्लिकेशन के OAuth 2.0 क्लाइंट आईडी में से एक होना चाहिए.
`exp`	हमेशा	समयसीमा खत्म होने का समय, जिसके बाद आईडी टोकन स्वीकार नहीं किया जाना चाहिए. इसे Unix epoch टाइम (सेकंड में पूर्णांक) में दिखाया जाता है.
`iat`	हमेशा	आईडी टोकन जारी किए जाने का समय. इसे Unix epoch टाइम (सेकंड में पूर्णांक) में दिखाया जाता है.
`iss`	हमेशा	जवाब जारी करने वाले के लिए आइडेंटिफ़ायर. Google आईडी टोकन के लिए, हमेशा `https://accounts.google.com` या `accounts.google.com` का इस्तेमाल करें.
`sub`	हमेशा	उपयोगकर्ता का आइडेंटिफ़ायर, जो सभी Google खातों के लिए यूनीक होता है और जिसका दोबारा इस्तेमाल नहीं किया जाता. एक Google खाते में अलग-अलग समय पर कई ईमेल पते हो सकते हैं. हालांकि, `sub` वैल्यू कभी नहीं बदलती. अपने ऐप्लिकेशन में `sub` का इस्तेमाल, उपयोगकर्ता के लिए यूनीक आइडेंटिफ़ायर कुंजी के तौर पर करें. केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) ASCII वर्णों की संख्या 255 से ज़्यादा नहीं होनी चाहिए.
`amr`		स्ट्रिंग की एक JSON कलेक्शन, जो Google खाते में साइन इन करने के लिए इस्तेमाल किए गए पुष्टि करने के तरीकों की पहचान करती है. अगर यह मौजूद है, तो इसमें इनमें से एक या उससे ज़्यादा संभावित [IANA.AMR] वैल्यू शामिल होती हैं: `hwk` को हार्डवेयर बटन का इस्तेमाल किया गया `mfa` कई चरणों में पुष्टि करने की प्रोसेस पूरी हो गई है `pwd` पासवर्ड इस्तेमाल किया गया `sms` पुष्टि करने के लिए एसएमएस का इस्तेमाल किया गया `swk` सॉफ़्टवेयर पासकी का इस्तेमाल किया गया था, जैसे कि पासकी `tel` को पुष्टि करने के लिए, फ़ोन कॉल का इस्तेमाल किया गया था यह सिर्फ़ तब मौजूद होता है, जब पुष्टि करने के अनुरोध में `amr` दावा शामिल किया गया हो और सेटिंग में जाकर इसे चालू किया गया हो.
`auth_time`		उपयोगकर्ता की पुष्टि होने का समय. यह एक JSON नंबर होता है, जो Unix epoch (1 जनवरी, 1970, 00:00:00 यूटीसी) के बाद से बीते हुए सेकंड की संख्या दिखाता है. यह तब उपलब्ध कराया जाता है, जब पुष्टि करने के अनुरोध में `auth_time` दावा शामिल किया जाता है और सेटिंग में चालू किया जाता है.
`at_hash`		ऐक्सेस टोकन हैश. यह पुष्टि करता है कि ऐक्सेस टोकन, आइडेंटिटी टोकन से जुड़ा है. अगर आईडी टोकन को सर्वर फ़्लो में `access_token` वैल्यू के साथ जारी किया जाता है, तो यह दावा हमेशा शामिल किया जाता है. इस दावे का इस्तेमाल, किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीएसआरएफ़) वाले हमलों से बचने के लिए, एक वैकल्पिक तरीके के तौर पर किया जा सकता है. हालांकि, अगर आपने पहला चरण और तीसरा चरण पूरा किया है, तो ऐक्सेस टोकन की पुष्टि करना ज़रूरी नहीं है.
`azp`		आधिकारिक तौर पर प्रज़ेंट करने वाले व्यक्ति का `client_id`. इस दावे की ज़रूरत सिर्फ़ तब होती है, जब आईडी टोकन का अनुरोध करने वाली पार्टी, आईडी टोकन की ऑडियंस से अलग हो. Google पर हाइब्रिड ऐप्लिकेशन के लिए ऐसा हो सकता है. इनमें वेब ऐप्लिकेशन और Android ऐप्लिकेशन का OAuth 2.0 `client_id` अलग-अलग होता है, लेकिन वे एक ही Google API प्रोजेक्ट शेयर करते हैं.
`email`		उपयोगकर्ता का ईमेल पता. यह सिर्फ़ तब उपलब्ध कराया जाता है, जब आपने अपने अनुरोध में `email` स्कोप को शामिल किया हो. इस दावे की वैल्यू, इस खाते के लिए यूनीक नहीं हो सकती. साथ ही, यह समय के साथ बदल सकती है. इसलिए, आपको इस वैल्यू का इस्तेमाल, अपने उपयोगकर्ता रिकॉर्ड से लिंक करने के लिए मुख्य आइडेंटिफ़ायर के तौर पर नहीं करना चाहिए. Google Workspace या Google Cloud संगठनों के उपयोगकर्ताओं की पहचान करने के लिए, `email` दावे के डोमेन पर भी भरोसा नहीं किया जा सकता. इसके बजाय, `hd` दावे का इस्तेमाल करें. चेतावनी: किसी उपयोगकर्ता के यूनीक आइडेंटिफ़ायर के तौर पर, `email` फ़ील्ड का इस्तेमाल न करें. हमेशा `sub` फ़ील्ड का इस्तेमाल करें.
`email_verified`		अगर उपयोगकर्ता के ईमेल पते की पुष्टि हो गई है, तो True; अगर नहीं हुई है, तो False.
`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 का स्कोप पैरामीटर पास करें. उपयोगकर्ता को ऐसी स्क्रीन जहां OAuth के लिए सहमति दी जाती है पर सही तरीके से प्रॉम्प्ट किया जाता है. Google से मिलने वाले ऐक्सेस टोकन की मदद से, आपका ऐप्लिकेशन उन सभी एपीआई को ऐक्सेस कर पाएगा जिनके लिए आपने ऐक्सेस का अनुरोध किया था और आपको ऐक्सेस दिया गया था.

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

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

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

इन बातों पर ध्यान दें:

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

ज़्यादा जानकारी के लिए, ऐक्सेस टोकन को रीफ़्रेश करना (बिना इंटरनेट के इस्तेमाल) देखें.

उपयोगकर्ता को अपने ऐप्लिकेशन को फिर से अनुमति देने के लिए कहा जा सकता है. इसके लिए, आपको अपने पुष्टि करने के अनुरोध में, prompt पैरामीटर को consent पर सेट करना होगा. prompt=consent शामिल होने पर, जब भी आपका ऐप्लिकेशन ऐक्सेस के स्कोप की अनुमति का अनुरोध करता है, तब सहमति वाली स्क्रीन दिखती है. भले ही, आपके Google API प्रोजेक्ट को पहले ही सभी स्कोप की अनुमति मिल चुकी हो. इसलिए, prompt=consent को सिर्फ़ तब शामिल करें, जब ज़रूरी हो.

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

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

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

पैरामीटर ज़रूरी है ब्यौरा

client_id (ज़रूरी है) क्लाइंट आईडी स्ट्रिंग, जो आपको Cloud Console के क्लाइंट पेज से मिलती है. इसके बारे में OAuth 2.0 क्रेडेंशियल पाना में बताया गया है.

nonce (ज़रूरी है) आपके ऐप्लिकेशन से जनरेट की गई कोई रैंडम वैल्यू, जो रीप्ले प्रोटेक्शन की सुविधा चालू करती है.

response_type (ज़रूरी है) अगर वैल्यू code है, तो बेसिक ऑथराइज़ेशन कोड फ़्लो लॉन्च होता है. टोकन पाने के लिए, टोकन एंडपॉइंट पर POST की ज़रूरत होती है. अगर वैल्यू token id_token या id_token token है, तो इंप्लिसिट फ़्लो लॉन्च होता है. इसके लिए, रीडायरेक्ट यूआरआई पर JavaScript का इस्तेमाल करना ज़रूरी है, ताकि यूआरआई #fragment आइडेंटिफ़ायर से टोकन वापस पाए जा सकें.

redirect_uri (ज़रूरी है) इससे यह तय होता है कि जवाब कहां भेजा जाए. इस पैरामीटर की वैल्यू, Cloud Console के क्लाइंट पेज पर सेट की गई, अनुमति वाली रीडायरेक्ट वैल्यू में से किसी एक से पूरी तरह मेल खानी चाहिए. इसमें एचटीटीपी या एचटीटीपीएस स्कीम, केस, और आखिर में मौजूद '/' (अगर कोई है) शामिल है.

scope

(ज़रूरी है)

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

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

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

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

claims

(ज़रूरी नहीं)

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

दावे के अनुरोध

amr उपयोगकर्ता की पिछली बार पुष्टि करने के लिए इस्तेमाल किए गए तरीके का अनुरोध करें. आईडी टोकन के जवाब में amr को फ़ील्ड के तौर पर दिखाने के लिए, claims अनुरोध पैरामीटर शामिल करें: claims={"id_token":{"amr":{"essential":true}}} इसे सेटिंग में जाकर चालू करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "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 के साथ ऐसा नहीं है.

OpenID कनेक्ट संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

OAuth 2.0 सेट अप करना

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

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

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

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

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

सर्वर फ़्लो

1. धोखाधड़ी रोकने के लिए स्टेट टोकन बनाना

PHP

Java

Python

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

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

PHP

Java

Python

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

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

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

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

उन्नत विषय

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

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

दोबारा सहमति देने के लिए अनुरोध करना

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

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

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

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

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

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

OpenID कनेक्ट

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