Google के OAuth 2.0 एपीआई का इस्तेमाल, पुष्टि करने और अनुमति देने, दोनों के लिए किया जा सकता है. इस दस्तावेज़ में, पुष्टि करने के लिए 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 में क्लाइंट पेज पर जाकर, अपना क्लाइंट आईडी और क्लाइंट सीक्रेट देखें:
- क्लाइंट पेज पर जाएं.
- अपने क्लाइंट के नाम या बदलाव करें (create) आइकॉन पर क्लिक करें. आपका क्लाइंट आईडी और सीक्रेट, पेज पर सबसे ऊपर मौजूद होता है.
रीडायरेक्ट यूआरआई सेट करना
Cloud Console में सेट किया गया रीडायरेक्ट यूआरआई यह तय करता है कि Google, आपके पुष्टि करने के अनुरोधों के जवाब कहां भेजेगा.
किसी OAuth 2.0 क्रेडेंशियल के लिए, रीडायरेक्ट यूआरआई बनाने, देखने या उनमें बदलाव करने के लिए, यह तरीका अपनाएं:
- क्लाइंट पेज पर जाएं.
- क्लाइंट पर क्लिक करें.
- रीडायरेक्ट यूआरआई देखें या उनमें बदलाव करें.
अगर क्लाइंट पेज पर कोई क्लाइंट नहीं दिखता है, तो इसका मतलब है कि आपके प्रोजेक्ट में कोई OAuth क्रेडेंशियल नहीं है. क्लाइंट खाता बनाने के लिए, क्लाइंट खाता बनाएं पर क्लिक करें.
उपयोगकर्ता की सहमति वाली स्क्रीन को पसंद के मुताबिक बनाना
आपके उपयोगकर्ताओं के लिए, OAuth 2.0 की पुष्टि करने की प्रोसेस में सहमति वाली स्क्रीन शामिल होती है. इस स्क्रीन पर, उपयोगकर्ता की ओर से रिलीज़ की जा रही जानकारी और लागू होने वाली शर्तों के बारे में बताया जाता है. उदाहरण के लिए, जब कोई उपयोगकर्ता लॉग इन करता है, तो उससे आपके ऐप्लिकेशन को अपने ईमेल पते और खाते की बुनियादी जानकारी का ऐक्सेस देने के लिए कहा जा सकता है. इस जानकारी को ऐक्सेस करने का अनुरोध, scope पैरामीटर का इस्तेमाल करके किया जाता है. आपका ऐप्लिकेशन इसे पुष्टि करने के अनुरोध में शामिल करता है. अन्य Google API को ऐक्सेस करने का अनुरोध करने के लिए भी, स्कोप का इस्तेमाल किया जा सकता है.
उपयोगकर्ता की सहमति वाली स्क्रीन पर, ब्रैंडिंग की जानकारी भी दिखती है. जैसे, आपके प्रॉडक्ट का नाम, लोगो, और होम पेज का यूआरएल. Cloud Console में ब्रैंडिंग की जानकारी को कंट्रोल किया जा सकता है.
अपने प्रोजेक्ट के लिए सहमति वाली स्क्रीन चालू करने के लिए:
- Google Cloud Console में, ब्रैंडिंग पेज खोलें.
- अगर आपसे पूछा जाए, तो कोई प्रोजेक्ट चुनें या नया प्रोजेक्ट बनाएं.
- फ़ॉर्म भरें और सेव करें पर क्लिक करें.
सहमति वाले इस डायलॉग बॉक्स में दिखाया गया है कि जब अनुरोध में 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 से साइन इन करने की कोशिश करता है, तो आपको ये काम करने होंगे:
- फ़र्ज़ीवाड़े को रोकने के लिए स्टेट टोकन बनाना
- Google को पुष्टि करने का अनुरोध भेजना
- फ़र्ज़ीवाड़े से रोकने के लिए इस्तेमाल किए जाने वाले स्टेट टोकन की पुष्टि करना
- ऐक्सेस टोकन और आईडी टोकन के लिए
codeको एक्सचेंज करना - आईडी टोकन से उपयोगकर्ता की जानकारी पाना
- उपयोगकर्ता की पुष्टि करना
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 के क्लाइंट पेज से हासिल किया जाता है.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नहीं दिया है और उपयोगकर्ता ने लॉग इन किया हुआ है, तो सहमति वाली स्क्रीन में, उपयोगकर्ता के ईमेल पते को आपके ऐप्लिकेशन के साथ शेयर करने की अनुमति देने का अनुरोध शामिल होता है. (ज़्यादा जानकारी के लिए,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//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
इस उदाहरण का इस्तेमाल करने के लिए, आपको 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 के क्लाइंट पेज से मिला क्लाइंट आईडी. इसके बारे में 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 |
(ज़रूरी नहीं)
यह फ़ील्ड सिर्फ़ तब मौजूद होता है, जब प्रमाणीकरण के अनुरोध में |
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 वर्ण इस्तेमाल किए जा सकते हैं. |
amr |
यह स्ट्रिंग का JSON कलेक्शन होता है. इससे, Google खाते में साइन इन करने के लिए इस्तेमाल किए गए पुष्टि करने के तरीकों की पहचान की जाती है. अगर यह मौजूद है, तो इसमें इनमें से एक या ज़्यादा संभावित [IANA.AMR] वैल्यू शामिल होती हैं:
amr का दावा शामिल हो और सेटिंग में चालू हो.
|
|
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 |
उपयोगकर्ता का पूरा नाम, जिसे दिखाया जा सकता है. यह एट्रिब्यूट तब सबमिट किया जा सकता है, जब:
|
|
nonce |
पुष्टि करने के अनुरोध में, आपके ऐप्लिकेशन से दी गई nonce की वैल्यू.
आपको इस वैल्यू को सिर्फ़ एक बार दिखाकर, रीप्ले अटैक से बचना चाहिए. |
|
picture |
उपयोगकर्ता की प्रोफ़ाइल फ़ोटो का यूआरएल. यह एट्रिब्यूट तब सबमिट किया जा सकता है, जब:
|
|
profile |
उपयोगकर्ता की प्रोफ़ाइल पेज का यूआरएल. यह एट्रिब्यूट तब सबमिट किया जा सकता है, जब:
|
6. उपयोगकर्ता की पुष्टि करना
आईडी टोकन से उपयोगकर्ता की जानकारी पाने के बाद, आपको अपने ऐप्लिकेशन के उपयोगकर्ता डेटाबेस से क्वेरी करनी चाहिए. अगर उपयोगकर्ता आपके डेटाबेस में पहले से मौजूद है, तो आपको उस उपयोगकर्ता के लिए ऐप्लिकेशन सेशन शुरू करना चाहिए. हालांकि, ऐसा तब ही करें, जब Google API से मिले रिस्पॉन्स में लॉगिन से जुड़ी सभी ज़रूरी शर्तें पूरी की गई हों.
अगर उपयोगकर्ता, आपके उपयोगकर्ता डेटाबेस में मौजूद नहीं है, तो आपको उसे नए उपयोगकर्ता के साइन-अप फ़्लो पर रीडायरेक्ट करना चाहिए. Google से मिली जानकारी के आधार पर, उपयोगकर्ता को अपने-आप रजिस्टर किया जा सकता है. इसके अलावा, कम से कम उन फ़ील्ड में पहले से जानकारी भरी जा सकती है जिनकी ज़रूरत आपको रजिस्ट्रेशन फ़ॉर्म में होती है. आईडी टोकन में मौजूद जानकारी के अलावा, आपको हमारे उपयोगकर्ता प्रोफ़ाइल एंडपॉइंट पर उपयोगकर्ता की प्रोफ़ाइल की अतिरिक्त जानकारी मिल सकती है.
उन्नत विषय
यहां दिए गए सेक्शन में, Google OAuth 2.0 API के बारे में ज़्यादा जानकारी दी गई है. यह जानकारी उन डेवलपर के लिए है जिन्हें पुष्टि करने और अनुमति देने से जुड़ी ऐडवांस सुविधाओं की ज़रूरत है.
Google के अन्य एपीआई का ऐक्सेस
पुष्टि करने के लिए OAuth 2.0 का इस्तेमाल करने का एक फ़ायदा यह है कि आपका ऐप्लिकेशन, उपयोगकर्ता की पुष्टि करने के साथ-साथ, उपयोगकर्ता की ओर से Google APIs (जैसे, 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 को शामिल करने पर, ऐसी स्क्रीन जहां OAuth के लिए सहमति दी जाती है, तब भी दिखती है, जब आपका ऐप्लिकेशन ऐक्सेस के दायरे की अनुमति का अनुरोध करता है. भले ही, सभी दायरे पहले ही आपके Google APIs प्रोजेक्ट को दिए गए हों. इसलिए, 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 से जुड़े इन स्कोप के अलावा, स्कोप आर्ग्युमेंट में स्कोप की अन्य वैल्यू भी शामिल की जा सकती हैं. स्कोप की सभी वैल्यू को स्पेस से अलग किया जाना चाहिए. उदाहरण के लिए, अगर आपको किसी उपयोगकर्ता के Google Drive में मौजूद हर फ़ाइल का ऐक्सेस चाहिए, तो आपका स्कोप पैरामीटर उपलब्ध स्कोप के बारे में जानकारी पाने के लिए, Google APIs के लिए OAuth 2.0 के स्कोप देखें. इसके अलावा, उस Google API का दस्तावेज़ देखें जिसका आपको इस्तेमाल करना है. |
||||||
state |
(ज़रूरी नहीं, लेकिन हमारा सुझाव है कि आप इसे इस्तेमाल करें) | यह एक ओपेक स्ट्रिंग है, जो प्रोटोकॉल में राउंड-ट्रिप की जाती है. इसका मतलब है कि इसे बेसिक फ़्लो में यूआरआई पैरामीटर के तौर पर दिखाया जाता है. साथ ही, इसे इंप्लिसिट फ़्लो में यूआरआई
|
||||||
access_type |
(ज़रूरी नहीं) | offline और online को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. इसका असर ऑफ़लाइन ऐक्सेस में बताया गया है. अगर ऐक्सेस टोकन का अनुरोध किया जा रहा है, तो क्लाइंट को रीफ़्रेश टोकन तब तक नहीं मिलता, जब तक कि offline की वैल्यू तय नहीं की जाती. |
||||||
claims |
(ज़रूरी नहीं) |
claims पैरामीटर का इस्तेमाल, एक या उससे ज़्यादा वैकल्पिक फ़ील्ड तय करने के लिए किया जाता है. इन फ़ील्ड को userinfo एंडपॉइंट या पुष्टि करने के अनुरोध वाले आईडी टोकन के जवाब के टाइप में शामिल किया जाता है. यह वैल्यू एक JSON ऑब्जेक्ट है. इसमें रिस्पॉन्स टाइप और अनुरोध किए गए दावे शामिल होते हैं. Google के सर्वर, दावे के इन अनुरोधों को स्वीकार करते हैं:
|
||||||
display |
(ज़रूरी नहीं) | यह एक ASCII स्ट्रिंग वैल्यू है. इससे यह तय किया जाता है कि ऑथराइज़ेशन सर्वर, पुष्टि और सहमति लेने के लिए यूज़र इंटरफ़ेस (यूआई) वाले पेज कैसे दिखाता है. यहां दी गई वैल्यू, Google के सर्वर के लिए तय की गई हैं और इन्हें स्वीकार किया जाता है. हालांकि, इनका प्रोटोकॉल फ़्लो के व्यवहार पर कोई असर नहीं पड़ता: page, popup, touch, और wap. |
||||||
hd |
(ज़रूरी नहीं) | Google Cloud संगठन के मालिकाना हक वाले खातों के लिए, लॉगिन प्रोसेस को आसान बनाएं. Google Cloud संगठन के डोमेन (उदाहरण के लिए, mycollege.edu) को शामिल करके, यह बताया जा सकता है कि खाता चुनने वाले यूज़र इंटरफ़ेस (यूआई) को उस डोमेन के खातों के लिए ऑप्टिमाइज़ किया जाना चाहिए. अगर आपको सिर्फ़ एक Google Cloud संगठन के डोमेन के बजाय, सामान्य तौर पर Google Cloud संगठन के खातों के लिए ऑप्टिमाइज़ करना है, तो ऐस्टरिक ( यह यूज़र इंटरफ़ेस (यूआई) ऑप्टिमाइज़ेशन, यह कंट्रोल करने के लिए इस्तेमाल न करें कि कौन आपके ऐप्लिकेशन को ऐक्सेस कर सकता है. ऐसा इसलिए, क्योंकि क्लाइंट-साइड के अनुरोधों में बदलाव किया जा सकता है. यह पुष्टि करें कि लौटाए गए आईडी टोकन में |
||||||
include_granted_scopes |
(ज़रूरी नहीं) | अगर इस पैरामीटर को true वैल्यू के साथ दिया जाता है और अनुमति देने का अनुरोध स्वीकार कर लिया जाता है, तो अनुमति में इस उपयोगकर्ता/ऐप्लिकेशन कॉम्बिनेशन को अन्य स्कोप के लिए दी गई पिछली सभी अनुमतियां शामिल होंगी. अनुमति में बढ़ोतरी देखें.
ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के फ़्लो के साथ, इंक्रीमेंटल ऑथराइज़ेशन नहीं किया जा सकता. |
||||||
login_hint |
(ज़रूरी नहीं) | जब आपके ऐप्लिकेशन को यह पता होता है कि किस उपयोगकर्ता की पुष्टि करनी है, तब वह पुष्टि करने वाले सर्वर को इस पैरामीटर को एक हिंट के तौर पर दे सकता है. इस हिंट को पास करने से, खाता चुनने वाला टूल नहीं दिखता. साथ ही, साइन-इन फ़ॉर्म पर ईमेल बॉक्स में पहले से जानकारी भर जाती है या सही सेशन चुना जाता है. ऐसा तब होता है, जब उपयोगकर्ता एक से ज़्यादा खातों से साइन इन करने की सुविधा का इस्तेमाल कर रहा हो. इससे आपको उन समस्याओं से बचने में मदद मिल सकती है जो आपके ऐप्लिकेशन के गलत उपयोगकर्ता खाते में लॉग इन करने पर होती हैं. वैल्यू, ईमेल पता या sub स्ट्रिंग हो सकती है. यह स्ट्रिंग, उपयोगकर्ता के Google आईडी के बराबर होती है. |
||||||
prompt |
(ज़रूरी नहीं) | यह स्पेस से अलग की गई स्ट्रिंग वैल्यू की सूची होती है. इससे यह तय होता है कि अनुमति देने वाला सर्वर, उपयोगकर्ता को फिर से पुष्टि करने और सहमति देने के लिए कहेगा या नहीं. इन वैल्यू का इस्तेमाल किया जा सकता है:
अगर कोई वैल्यू तय नहीं की गई है और उपयोगकर्ता ने पहले ऐक्सेस करने की अनुमति नहीं दी है, तो उपयोगकर्ता को सहमति वाली स्क्रीन दिखाई जाती है. |
||||||
hl |
(ज़रूरी नहीं) | यह BCP 47 भाषा टैग है. इसका इस्तेमाल, साइन-इन, खाता चुनने, और सहमति लेने वाली स्क्रीन के लिए डिसप्ले की भाषा तय करने के लिए किया जाता है. अगर यह पैरामीटर नहीं दिया जाता है, तो भाषा डिफ़ॉल्ट रूप से उपयोगकर्ता के Google खाते या ब्राउज़र की सेटिंग पर सेट हो जाती है. उदाहरण के लिए, यूज़र इंटरफ़ेस (यूआई) को ब्रिटिश अंग्रेज़ी में दिखाने का अनुरोध करने के लिए, पैरामीटर को en-GB पर सेट करें.
|
||||||
आईडी टोकन की पुष्टि करना
आपको अपने सर्वर पर सभी आईडी टोकन की पुष्टि करनी होगी. ऐसा तब तक करें, जब तक आपको यह पता न चल जाए कि वे सीधे Google से मिले हैं. उदाहरण के लिए, आपके सर्वर को आपके क्लाइंट ऐप्लिकेशन से मिले किसी भी आईडी टोकन की पुष्टि करनी होगी.
यहां कुछ सामान्य स्थितियां दी गई हैं, जिनमें आपको अपने सर्वर पर आईडी टोकन भेजने पड़ सकते हैं:
- ऐसे अनुरोधों के साथ आईडी टोकन भेजना जिनकी पुष्टि करना ज़रूरी है. आईडी टोकन से आपको यह पता चलता है कि अनुरोध किस उपयोगकर्ता ने किया है और किस क्लाइंट को यह आईडी टोकन दिया गया था.
आईडी टोकन संवेदनशील होते हैं. अगर इन्हें इंटरसेप्ट कर लिया जाता है, तो इनका गलत इस्तेमाल किया जा सकता है. आपको यह पक्का करना होगा कि इन टोकन को सुरक्षित तरीके से हैंडल किया जाए. इसके लिए, इन्हें सिर्फ़ एचटीटीपीएस पर ट्रांसमिट करें. साथ ही, सिर्फ़ POST डेटा या अनुरोध हेडर में इनका इस्तेमाल करें. अगर आईडी टोकन को अपने सर्वर पर सेव किया जाता है, तो उन्हें सुरक्षित तरीके से सेव करना ज़रूरी है.
आईडी टोकन को उपयोगी बनाने वाली एक बात यह है कि इन्हें आपके ऐप्लिकेशन के अलग-अलग कॉम्पोनेंट में पास किया जा सकता है. ये कॉम्पोनेंट, आईडी टोकन का इस्तेमाल हल्के-फुल्के पुष्टि करने वाले मैकेनिज़्म के तौर पर कर सकते हैं. इससे ऐप्लिकेशन और उपयोगकर्ता की पुष्टि की जा सकती है. हालांकि, आईडी टोकन में मौजूद जानकारी का इस्तेमाल करने या इस बात की पुष्टि करने के लिए कि उपयोगकर्ता ने पुष्टि कर ली है, आपको इसकी पुष्टि ज़रूर करनी चाहिए.
आईडी टोकन की पुष्टि करने के लिए, कई चरण पूरे करने होते हैं:
- पुष्टि करें कि आईडी टोकन पर, जारी करने वाले ने सही तरीके से हस्ताक्षर किए हों. Google से जारी किए गए टोकन पर हस्ताक्षर किए जाते हैं. इसके लिए, खोज से जुड़े दस्तावेज़ के
jwks_uriमेटाडेटा वैल्यू में दिए गए यूआरआई पर मौजूद किसी एक सर्टिफ़िकेट का इस्तेमाल किया जाता है. - पुष्टि करें कि आईडी टोकन में मौजूद
issदावे की वैल्यू,https://accounts.google.comयाaccounts.google.comके बराबर हो. - पुष्टि करें कि आईडी टोकन में मौजूद
audदावे की वैल्यू, आपके ऐप्लिकेशन के क्लाइंट आईडी के बराबर हो. - पुष्टि करें कि आईडी टोकन की समयसीमा खत्म होने का समय (
expदावा) खत्म नहीं हुआ है. - अगर आपने अनुरोध में hd पैरामीटर की वैल्यू दी है, तो पुष्टि करें कि
आईडी टोकन में
hdदावा मौजूद हो. यह दावा, Google Cloud संगठन से जुड़े किसी ऐसे डोमेन से मेल खाता हो जिसे स्वीकार किया गया हो.
दूसरे से पांचवें चरण में, सिर्फ़ स्ट्रिंग और तारीख की तुलना की जाती है. यह काफ़ी आसान है. इसलिए, हम यहां इसके बारे में ज़्यादा जानकारी नहीं देंगे.
पहला चरण ज़्यादा मुश्किल होता है. इसमें क्रिप्टोग्राफ़िक सिग्नेचर की जांच की जाती है. डीबग करने के लिए, Google के tokeninfo एंडपॉइंट का इस्तेमाल किया जा सकता है. इससे, अपने सर्वर या डिवाइस पर लागू की गई लोकल प्रोसेसिंग की तुलना की जा सकती है. मान लें कि आपके आईडी टोकन की वैल्यू XYZ123 है. इसके बाद, यूआरआई https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123 को डीरेफ़रेंस किया जाएगा. अगर टोकन का हस्ताक्षर मान्य है, तो रिस्पॉन्स में JWT पेलोड, डिकोड किए गए JSON ऑब्जेक्ट के तौर पर दिखेगा.
tokeninfo एंडपॉइंट, डीबग करने के लिए काम का है. हालांकि, प्रोडक्शन के लिए, Google के सार्वजनिक पासकोड को keys एंडपॉइंट से वापस पाएं और पुष्टि की प्रोसेस को स्थानीय तौर पर पूरा करें. आपको 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 अनुरोध ऑब्जेक्ट को छोड़कर.