ओपनआईडी कनेक्ट

Google का OpenID Connect समापन बिंदु OpenID प्रमाणित है।

Google के OAuth 2.0 API का उपयोग प्रमाणीकरण और प्राधिकरण दोनों के लिए किया जा सकता है। यह दस्तावेज़ प्रमाणीकरण के लिए हमारे OAuth 2.0 कार्यान्वयन का वर्णन करता है, जो OpenID Connect विनिर्देश के अनुरूप है, और OpenID प्रमाणित है। Google API को एक्सेस करने के लिए OAuth 2.0 का उपयोग करना में पाया गया दस्तावेज़ भी इस सेवा पर लागू होता है। यदि आप इस प्रोटोकॉल को अंतःक्रियात्मक रूप से एक्सप्लोर करना चाहते हैं, तो हम Google OAuth 2.0 Playground की अनुशंसा करते हैं। स्टैक ओवरफ़्लो पर सहायता प्राप्त करने के लिए, अपने प्रश्नों को 'google-oauth' के साथ टैग करें।

OAuth 2.0 सेट करना

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

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

उपयोगकर्ताओं को प्रमाणित करने और Google के API तक पहुंच प्राप्त करने के लिए आपको क्लाइंट आईडी और क्लाइंट सीक्रेट सहित OAuth 2.0 क्रेडेंशियल की आवश्यकता होती है।

要查看给定OAuth 2.0凭据的客户端ID和客户端密钥，请单击以下文本： 选择凭据 。在打开的窗口中，选择您的项目和所需的凭证，然后单击“ 查看” 。

或者，从API Console的“ 凭据”页面中查看您的客户端ID和客户端密钥：

  1. Go to the Credentials page.
  2. 单击您的凭证名称或铅笔（ ）图标。您的客户ID和密码位于页面顶部。

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

आपके द्वारा API Console में सेट किया गया रीडायरेक्ट URI निर्धारित करता है कि Google आपके प्रमाणीकरण अनुरोधों पर प्रतिक्रियाएँ कहाँ भेजता है।

किसी दिए गए OAuth 2.0 क्रेडेंशियल के लिए रीडायरेक्ट URI को बनाने, देखने या संपादित करने के लिए, निम्नलिखित करें:

  1. Go to the Credentials page.
  2. पृष्ठ के OAuth 2.0 क्लाइंट आईडी अनुभाग में, एक क्रेडेंशियल पर क्लिक करें।
  3. अनुप्रेषित URI को देखें या संपादित करें।

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

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

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

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

अपनी परियोजना की सहमति स्क्रीन को सक्षम करने के लिए:

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

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

सहमति पेज का स्क्रीन शॉट

सेवा तक पहुंचना

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

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

उपयोगकर्ता को प्रमाणित करना

उपयोगकर्ता को प्रमाणित करने में एक आईडी टोकन प्राप्त करना और उसे मान्य करना शामिल है। आईडी टोकन ओपनआईडी कनेक्ट की एक मानकीकृत विशेषता है जिसे इंटरनेट पर पहचान के दावे साझा करने में उपयोग के लिए डिज़ाइन किया गया है।

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

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

सर्वर प्रवाह

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

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

1. एक जालसाजी विरोधी राज्य टोकन बनाएं

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

एक राज्य टोकन के लिए एक अच्छा विकल्प एक उच्च-गुणवत्ता वाले यादृच्छिक-संख्या जनरेटर का उपयोग करके निर्मित 30 या तो वर्णों की एक स्ट्रिंग है। दूसरा एक हैश है जो आपके कुछ सत्र स्थिति चर पर एक कुंजी के साथ हस्ताक्षर करके उत्पन्न होता है जिसे आपके बैक-एंड पर गुप्त रखा जाता है।

निम्नलिखित कोड अद्वितीय सत्र टोकन उत्पन्न करने का प्रदर्शन करता है।

पीएचपी

इस नमूने का उपयोग करने के लिए आपको PHP के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

जावा

इस नमूने का उपयोग करने के लिए आपको जावा के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

अजगर

इस नमूने का उपयोग करने के लिए आपको Python के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Google को प्रमाणीकरण अनुरोध भेजें

अगला चरण उपयुक्त URI पैरामीटर के साथ HTTPS GET अनुरोध बना रहा है। इस प्रक्रिया के सभी चरणों में HTTP के बजाय HTTPS के उपयोग पर ध्यान दें; HTTP कनेक्शन अस्वीकार कर दिए गए हैं। आपको authorization_endpoint मेटाडेटा मान का उपयोग करके डिस्कवरी दस्तावेज़ से आधार यूआरआई प्राप्त करना चाहिए। निम्नलिखित चर्चा मानती है कि आधार यूआरआई https://accounts.google.com/o/oauth2/v2/auth है।

मूल अनुरोध के लिए, निम्नलिखित पैरामीटर निर्दिष्ट करें:

  • client_id , जिसे आप API ConsoleCredentials pageसे प्राप्त करते हैं।
  • response_type , जो मूल प्राधिकरण कोड प्रवाह अनुरोध में code होना चाहिए। ( response_type पर और पढ़ें।)
  • scope , जो मूल अनुरोध में openid email होना चाहिए। ( scope पर और पढ़ें।)
  • redirect_uri आपके सर्वर पर HTTP एंडपॉइंट होना चाहिए जो Google से प्रतिक्रिया प्राप्त करेगा। मान को OAuth 2.0 क्लाइंट के लिए अधिकृत रीडायरेक्ट URI में से किसी एक से सटीक रूप से मेल खाना चाहिए, जिसे आपने API ConsoleCredentials pageplaceholder138 में कॉन्फ़िगर किया है। यदि यह मान किसी अधिकृत URI से मेल नहीं खाता है, तो अनुरोध एक redirect_uri_mismatch त्रुटि के साथ विफल हो जाएगा।
  • state में एंटी-जालसाजी अद्वितीय सत्र टोकन के मूल्य के साथ-साथ उपयोगकर्ता द्वारा आपके आवेदन पर वापस आने पर संदर्भ को पुनर्प्राप्त करने के लिए आवश्यक कोई अन्य जानकारी शामिल होनी चाहिए, उदाहरण के लिए, प्रारंभिक URL। ( state में और पढ़ें।)
  • nonce आपके ऐप द्वारा उत्पन्न एक यादृच्छिक मान है जो मौजूद होने पर रीप्ले सुरक्षा को सक्षम बनाता है।
  • login_hint उपयोगकर्ता का ईमेल पता या sub स्ट्रिंग हो सकता है, जो उपयोगकर्ता की Google आईडी के बराबर है। यदि आप एक login_hint प्रदान नहीं करते हैं और उपयोगकर्ता वर्तमान में लॉग इन है, तो सहमति स्क्रीन में उपयोगकर्ता के ईमेल पते को आपके ऐप पर जारी करने के लिए अनुमोदन का अनुरोध शामिल है। ( login_hint पर और पढ़ें।)
  • Google क्लाउड संगठन से संबद्ध किसी विशेष डोमेन के उपयोगकर्ताओं के लिए OpenID Connect प्रवाह को अनुकूलित करने के लिए hd पैरामीटर का उपयोग करें। ( hd पर और पढ़ें।)

यहां एक संपूर्ण ओपनआईडी कनेक्ट प्रमाणीकरण यूआरआई का उदाहरण दिया गया है, जिसमें लाइन ब्रेक और पठनीयता के लिए रिक्त स्थान हैं:

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

यदि आपका ऐप उनके बारे में किसी भी नई जानकारी का अनुरोध करता है, या यदि आपका ऐप खाता एक्सेस का अनुरोध करता है, तो उपयोगकर्ताओं को सहमति देने की आवश्यकता होती है, जिसे उन्होंने पहले स्वीकृत नहीं किया है।

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

प्रतिक्रिया redirect_uri को भेजी जाती है जिसे आपने अनुरोध में निर्दिष्ट किया है। सभी प्रतिक्रियाएँ क्वेरी स्ट्रिंग में दी जाती हैं, जैसा कि नीचे दिखाया गया है:

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

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

निम्न कोड चरण 1 में आपके द्वारा बनाए गए सत्र टोकन की पुष्टि करता है:

पीएचपी

इस नमूने का उपयोग करने के लिए आपको PHP के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

// 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);
}

जावा

इस नमूने का उपयोग करने के लिए आपको जावा के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

// 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 के लिए Google API क्लाइंट लाइब्रेरी डाउनलोड करनी होगी।

# 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 पैरामीटर, एक बार का प्राधिकरण कोड शामिल होता है जिसे आपका सर्वर एक्सेस टोकन और आईडी टोकन के लिए एक्सचेंज कर सकता है। आपका सर्वर HTTPS POST अनुरोध भेजकर यह एक्सचेंज करता है। POST अनुरोध टोकन एंडपॉइंट पर भेजा जाता है, जिसे आपको token_endpoint मेटाडेटा मान का उपयोग करके डिस्कवरी दस्तावेज़ से पुनर्प्राप्त करना चाहिए। निम्नलिखित चर्चा मानती है कि समापन बिंदु https://oauth2.googleapis.com/token है। अनुरोध में POST बॉडी में निम्नलिखित पैरामीटर शामिल होने चाहिए:

खेत
code प्रारंभिक अनुरोध से लौटाया गया प्राधिकरण कोड .
client_id क्लाइंट आईडी जिसे आप API ConsoleCredentials pageसे प्राप्त करते हैं, जैसा कि OAuth 2.0 क्रेडेंशियल प्राप्त करें में वर्णित है।
client_secret क्लाइंट सीक्रेट जिसे आप API ConsoleCredentials pageसे प्राप्त करते हैं, जैसा कि OAuth 2.0 क्रेडेंशियल प्राप्त करें में वर्णित है।
redirect_uri दिए गए client_id के लिए एक अधिकृत रीडायरेक्ट URI API ConsoleCredentials pageplaceholder144 में निर्दिष्ट है, जैसा कि रीडायरेक्ट URI सेट करें में वर्णित है।
grant_type OAuth 2.0 विनिर्देश में परिभाषित के अनुसार , इस फ़ील्ड में authorization_code का मान होना चाहिए।

वास्तविक अनुरोध निम्न उदाहरण की तरह दिख सकता है:

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. आईडी टोकन से उपयोगकर्ता की जानकारी प्राप्त करें

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

चूंकि अधिकांश एपीआई लाइब्रेरी बेस 64url-एन्कोडेड मानों को डीकोड करने और जेएसओएन को पार्स करने के काम के साथ सत्यापन को जोड़ती हैं, इसलिए जब भी आप आईडी टोकन में दावों तक पहुंचते हैं तो आप टोकन को मान्य करना समाप्त कर देंगे।

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

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

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

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

दावा प्रदान की विवरण
aud हमेशा वे दर्शक जिनके लिए यह आईडी टोकन अभिप्रेत है। यह आपके आवेदन के OAuth 2.0 क्लाइंट आईडी में से एक होना चाहिए।
exp हमेशा समाप्ति समय जिसके बाद या उसके बाद आईडी टोकन स्वीकार नहीं किया जाना चाहिए। यूनिक्स समय (पूर्णांक सेकंड) में प्रतिनिधित्व।
iat हमेशा जिस समय आईडी टोकन जारी किया गया था। यूनिक्स समय (पूर्णांक सेकंड) में प्रतिनिधित्व।
iss हमेशा प्रतिक्रिया के जारीकर्ता के लिए जारीकर्ता पहचानकर्ता। Google आईडी टोकन के लिए हमेशा https://accounts.google.com या accounts.google.com ।
sub हमेशा उपयोगकर्ता के लिए एक पहचानकर्ता, सभी Google खातों में अद्वितीय और कभी भी पुन: उपयोग नहीं किया गया। एक Google खाते में अलग-अलग समय पर कई ईमेल पते हो सकते हैं, लेकिन sub मान कभी नहीं बदला जाता है। उपयोगकर्ता के लिए अद्वितीय-पहचानकर्ता कुंजी के रूप में अपने एप्लिकेशन के भीतर sub का उपयोग करें। 255 केस-संवेदी ASCII वर्णों की अधिकतम लंबाई।
at_hash एक्सेस टोकन हैश। सत्यापन प्रदान करता है कि एक्सेस टोकन पहचान टोकन से जुड़ा हुआ है। यदि सर्वर प्रवाह में एक access_token मान के साथ आईडी टोकन जारी किया जाता है, तो यह दावा हमेशा शामिल होता है। क्रॉस-साइट अनुरोध जालसाजी हमलों से बचाने के लिए इस दावे का उपयोग वैकल्पिक तंत्र के रूप में किया जा सकता है, लेकिन यदि आप चरण 1 और चरण 3 का पालन करते हैं तो एक्सेस टोकन को सत्यापित करना आवश्यक नहीं है।
azp अधिकृत प्रस्तुतकर्ता का client_id . यह दावा केवल तभी आवश्यक है जब आईडी टोकन का अनुरोध करने वाला पक्ष आईडी टोकन के दर्शकों के समान न हो। हाइब्रिड ऐप्स के लिए Google में ऐसा हो सकता है, जहां एक वेब एप्लिकेशन और Android ऐप का OAuth 2.0 client_id भिन्न होता है, लेकिन एक ही Google API प्रोजेक्ट साझा करते हैं।
email उपयोगकर्ता का ईमेल पता। यह मान इस उपयोगकर्ता के लिए अद्वितीय नहीं हो सकता है और प्राथमिक कुंजी के रूप में उपयोग के लिए उपयुक्त नहीं है। बशर्ते कि आपके दायरे में email दायरा मूल्य शामिल हो।
email_verified सही है अगर उपयोगकर्ता का ई-मेल पता सत्यापित किया गया है; अन्यथा झूठा।
family_name उपयोगकर्ता का उपनाम या उपनाम। name का दावा मौजूद होने पर प्रदान किया जा सकता है।
given_name उपयोगकर्ता का दिया गया नाम (नाम) या पहला नाम (नाम)। name का दावा मौजूद होने पर प्रदान किया जा सकता है।
hd उपयोगकर्ता के Google क्लाउड संगठन से संबद्ध डोमेन. बशर्ते कि उपयोगकर्ता किसी Google क्लाउड संगठन से संबंधित हो।
locale उपयोगकर्ता का स्थान, BCP 47 भाषा टैग द्वारा दर्शाया गया है। name का दावा मौजूद होने पर प्रदान किया जा सकता है।
name उपयोगकर्ता का पूरा नाम, प्रदर्शित करने योग्य रूप में। प्रदान किया जा सकता है जब:
  • अनुरोध के दायरे में स्ट्रिंग "प्रोफ़ाइल" शामिल है
  • आईडी टोकन टोकन रीफ्रेश से वापस किया जाता है

जब name के दावे मौजूद हों, तो आप उनका उपयोग अपने ऐप के उपयोगकर्ता रिकॉर्ड अपडेट करने के लिए कर सकते हैं। ध्यान दें कि यह दावा कभी भी मौजूद रहने की गारंटी नहीं है।

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

जब picture दावे मौजूद हों, तो आप उनका उपयोग अपने ऐप के उपयोगकर्ता रिकॉर्ड अपडेट करने के लिए कर सकते हैं। ध्यान दें कि यह दावा कभी भी मौजूद रहने की गारंटी नहीं है।

profile उपयोगकर्ता के प्रोफ़ाइल पृष्ठ का URL. प्रदान किया जा सकता है जब:
  • अनुरोध के दायरे में स्ट्रिंग "प्रोफ़ाइल" शामिल है
  • आईडी टोकन टोकन रीफ्रेश से वापस किया जाता है

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

6. उपयोगकर्ता को प्रमाणित करें

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

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

उन्नत विषय

निम्नलिखित अनुभाग Google OAuth 2.0 API का अधिक विस्तार से वर्णन करते हैं। यह जानकारी प्रमाणीकरण और प्राधिकरण के आसपास उन्नत आवश्यकताओं वाले डेवलपर्स के लिए अभिप्रेत है।

अन्य Google API तक पहुंच

प्रमाणीकरण के लिए OAuth 2.0 का उपयोग करने के लाभों में से एक यह है कि आपके एप्लिकेशन को उपयोगकर्ता की ओर से अन्य Google API का उपयोग करने की अनुमति मिल सकती है (जैसे YouTube, Google ड्राइव, कैलेंडर, या संपर्क) उसी समय जब आप उपयोगकर्ता को प्रमाणित करते हैं। ऐसा करने के लिए, Google को आपके द्वारा भेजे जाने वाले प्रमाणीकरण अनुरोध में अन्य क्षेत्रों को शामिल करें जिनकी आपको आवश्यकता है। उदाहरण के लिए, उपयोगकर्ता के आयु समूह को अपने प्रमाणीकरण अनुरोध में जोड़ने के लिए, openid email https://www.googleapis.com/auth/profile.agerange.read । उपयोगकर्ता को सहमति स्क्रीन पर उचित रूप से संकेत दिया जाता है। Google से आपको वापस प्राप्त होने वाला एक्सेस टोकन आपको उन सभी API तक पहुंचने की अनुमति देता है जो आपके द्वारा अनुरोधित और प्रदान किए गए एक्सेस के दायरे से संबंधित हैं।

टोकन ताज़ा करें

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

विचार:

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

अधिक जानकारी के लिए, एक्सेस टोकन रीफ़्रेश करना (ऑफ़लाइन एक्सेस) देखें ।

आप अपने प्रमाणीकरण अनुरोध में consent के लिए prompt पैरामीटर सेट करके उपयोगकर्ता को अपने ऐप को फिर से अधिकृत करने का संकेत दे सकते हैं। जब prompt=consent शामिल होती है, तो हर बार जब आपका ऐप एक्सेस के दायरे के प्राधिकरण का अनुरोध करता है, तो सहमति स्क्रीन प्रदर्शित होती है, भले ही सभी स्कोप पहले आपके Google एपीआई प्रोजेक्ट को दिए गए हों। इस कारण से, आवश्यक होने पर ही prompt=consent शामिल करें।

prompt पैरामीटर के बारे में अधिक जानकारी के लिए, प्रमाणीकरण URI पैरामीटर तालिका में prompt देखें।

प्रमाणीकरण यूआरआई पैरामीटर

निम्न तालिका Google के OAuth 2.0 प्रमाणीकरण API द्वारा स्वीकृत मापदंडों का अधिक संपूर्ण विवरण देती है।

पैरामीटर आवश्यक विवरण
client_id (आवश्यक) क्लाइंट आईडी स्ट्रिंग जिसे आप API ConsoleCredentials pageसे प्राप्त करते हैं, जैसा कि OAuth 2.0 क्रेडेंशियल प्राप्त करें में वर्णित है।
nonce (आवश्यक) आपके ऐप द्वारा जेनरेट किया गया एक यादृच्छिक मान जो रीप्ले सुरक्षा को सक्षम बनाता है।
response_type (आवश्यक) यदि मान code है, तो टोकन प्राप्त करने के लिए टोकन एंडपॉइंट पर POST की आवश्यकता के लिए एक मूल प्राधिकरण कोड प्रवाह लॉन्च करता है। यदि मान token id_token या id_token token है, तो एक अंतर्निहित प्रवाह लॉन्च करता है, जिसे URI #fragment पहचानकर्ता से टोकन पुनर्प्राप्त करने के लिए रीडायरेक्ट URI पर जावास्क्रिप्ट के उपयोग की आवश्यकता होती है।
redirect_uri (आवश्यक) निर्धारित करता है कि प्रतिक्रिया कहाँ भेजी जाती है। इस पैरामीटर का मान आपके द्वारा API ConsoleCredentials page (HTTP या HTTPS स्कीम, केस और अनुगामी '/', यदि कोई हो, सहित) में सेट किए गए अधिकृत रीडायरेक्ट मानों में से एक से सटीक रूप से मेल खाना चाहिए।
scope (आवश्यक)

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

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

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

इन ओपनआईडी-विशिष्ट स्कोपों ​​के अतिरिक्त, आपके स्कोप तर्क में अन्य स्कोप मान भी शामिल हो सकते हैं। सभी स्कोप मान स्पेस से अलग होने चाहिए। उदाहरण के लिए, यदि आप किसी उपयोगकर्ता की Google डिस्क पर प्रति फ़ाइल पहुंच चाहते हैं, तो आपका दायरा पैरामीटर openid profile email https://www.googleapis.com/auth/drive.file हो सकता है।

उपलब्ध कार्यक्षेत्रों के बारे में जानकारी के लिए, Google API के लिए OAuth 2.0 स्कोप या Google API के लिए दस्तावेज़ीकरण देखें जिसका आप उपयोग करना चाहते हैं।

state (वैकल्पिक, लेकिन दृढ़ता से अनुशंसित)

एक अपारदर्शी स्ट्रिंग जो प्रोटोकॉल में राउंड-ट्रिप की जाती है; दूसरे शब्दों में, यह मूल प्रवाह में यूआरआई पैरामीटर के रूप में और लागू प्रवाह में यूआरआई #fragment पहचानकर्ता के रूप में लौटाया जाता है।

state अनुरोधों और प्रतिक्रियाओं को सहसंबंधित करने के लिए उपयोगी हो सकता है। चूंकि आपके redirect_uri का अनुमान लगाया जा सकता है, इसलिए state मूल्य का उपयोग करने से आपका आश्वासन बढ़ सकता है कि आने वाला कनेक्शन आपके ऐप द्वारा शुरू किए गए प्रमाणीकरण अनुरोध का परिणाम है। यदि आप एक यादृच्छिक स्ट्रिंग उत्पन्न करते हैं या इस state चर में कुछ क्लाइंट स्थिति (उदाहरण के लिए, एक कुकी) के हैश को एन्कोड करते हैं, तो आप अतिरिक्त रूप से यह सुनिश्चित करने के लिए प्रतिक्रिया को सत्यापित कर सकते हैं कि अनुरोध और प्रतिक्रिया एक ही ब्राउज़र में उत्पन्न हुई है। यह क्रॉस-साइट अनुरोध जालसाजी जैसे हमलों से सुरक्षा प्रदान करता है।

access_type (वैकल्पिक) अनुमत मान offline और online हैं। प्रभाव ऑफ़लाइन पहुँच में प्रलेखित है; यदि एक्सेस टोकन का अनुरोध किया जा रहा है, तो क्लाइंट को तब तक रीफ्रेश टोकन प्राप्त नहीं होता जब तक कि offline का मान निर्दिष्ट न हो।
display (वैकल्पिक) यह निर्दिष्ट करने के लिए एक ASCII स्ट्रिंग मान है कि प्राधिकरण सर्वर प्रमाणीकरण और सहमति उपयोगकर्ता इंटरफ़ेस पृष्ठों को कैसे प्रदर्शित करता है। निम्नलिखित मान निर्दिष्ट हैं, और Google सर्वर द्वारा स्वीकार किए जाते हैं, लेकिन इसके व्यवहार पर कोई प्रभाव नहीं पड़ता है: page , popup , touch , और wap .
hd (वैकल्पिक)

Google क्लाउड संगठन के स्वामित्व वाले खातों के लिए लॉगिन प्रक्रिया को सुव्यवस्थित करें। Google क्लाउड संगठन डोमेन (उदाहरण के लिए, mycollege.edu ) को शामिल करके, आप यह संकेत दे सकते हैं कि खाता चयन UI उस डोमेन के खातों के लिए अनुकूलित किया जाना चाहिए। आम तौर पर केवल एक Google क्लाउड संगठन डोमेन के बजाय Google क्लाउड संगठन खातों के लिए अनुकूलित करने के लिए, तारांकन ( * ) का मान सेट करें: hd=* ।

आपके ऐप को कौन एक्सेस कर सकता है, इसे नियंत्रित करने के लिए इस UI ऑप्टिमाइज़ेशन पर भरोसा न करें, क्योंकि क्लाइंट-साइड अनुरोधों को संशोधित किया जा सकता है। यह सत्यापित करना सुनिश्चित करें कि लौटाए गए आईडी टोकन में एक hd दावा मूल्य है जो आपकी अपेक्षा से मेल खाता है (उदाहरण के लिए mycolledge.edu )। अनुरोध पैरामीटर के विपरीत, आईडी टोकन hd दावा Google से सुरक्षा टोकन में निहित है, इसलिए मूल्य पर भरोसा किया जा सकता है।

include_granted_scopes (वैकल्पिक) यदि यह पैरामीटर मान true के साथ प्रदान किया गया है, और प्राधिकरण अनुरोध दिया गया है, तो प्राधिकरण में अन्य क्षेत्रों के लिए इस उपयोगकर्ता/एप्लिकेशन संयोजन को दिया गया कोई भी पिछला प्राधिकरण शामिल होगा; वृद्धिशील प्राधिकरण देखें।

ध्यान दें कि आप इंस्टॉल किए गए ऐप प्रवाह के साथ वृद्धिशील प्राधिकरण नहीं कर सकते।

login_hint (वैकल्पिक) जब आपका ऐप जानता है कि वह किस उपयोगकर्ता को प्रमाणित करने का प्रयास कर रहा है, तो यह इस पैरामीटर को प्रमाणीकरण सर्वर के संकेत के रूप में प्रदान कर सकता है। इस संकेत को पास करने से खाता चयनकर्ता दब जाता है और या तो साइन-इन फ़ॉर्म पर ईमेल बॉक्स को पहले से भर देता है, या उचित सत्र का चयन करता है (यदि उपयोगकर्ता एकाधिक साइन-इन का उपयोग कर रहा है), जो आपको होने वाली समस्याओं से बचने में मदद कर सकता है यदि आपका ऐप गलत उपयोगकर्ता खाते में लॉग। मान या तो ईमेल पता या sub स्ट्रिंग हो सकता है, जो उपयोगकर्ता की Google आईडी के बराबर होता है।
prompt (वैकल्पिक) स्ट्रिंग मानों की एक स्पेस-सीमांकित सूची जो निर्दिष्ट करती है कि प्राधिकरण सर्वर उपयोगकर्ता को पुन: प्रमाणीकरण और सहमति के लिए संकेत देता है या नहीं। संभावित मान हैं:
  • none

    प्राधिकरण सर्वर कोई प्रमाणीकरण या उपयोगकर्ता सहमति स्क्रीन प्रदर्शित नहीं करता है; यदि उपयोगकर्ता पहले से प्रमाणित नहीं है और अनुरोधित दायरे के लिए पूर्व-कॉन्फ़िगर सहमति नहीं है तो यह एक त्रुटि लौटाएगा। आप मौजूदा प्रमाणीकरण और/या सहमति की जांच के लिए none का उपयोग कर सकते हैं।

  • consent

    प्राधिकरण सर्वर क्लाइंट को जानकारी वापस करने से पहले उपयोगकर्ता को सहमति के लिए संकेत देता है।

  • select_account

    प्राधिकरण सर्वर उपयोगकर्ता को उपयोगकर्ता खाते का चयन करने के लिए प्रेरित करता है। यह एक ऐसे उपयोगकर्ता को अनुमति देता है जिसके पास प्राधिकरण सर्वर पर एकाधिक खाते हैं, वे उन एकाधिक खातों में से चयन कर सकते हैं जिनके लिए उनके पास वर्तमान सत्र हो सकते हैं।

यदि कोई मान निर्दिष्ट नहीं है और उपयोगकर्ता ने पहले एक्सेस अधिकृत नहीं किया है, तो उपयोगकर्ता को एक सहमति स्क्रीन दिखाई जाती है।

एक आईडी टोकन मान्य करना

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

निम्नलिखित सामान्य स्थितियां हैं जहां आप अपने सर्वर पर आईडी टोकन भेज सकते हैं:

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

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

एक चीज जो आईडी टोकन को उपयोगी बनाती है, वह यह है कि आप उन्हें अपने ऐप के विभिन्न घटकों के आसपास पास कर सकते हैं। ये घटक ऐप और उपयोगकर्ता को प्रमाणित करने वाले हल्के प्रमाणीकरण तंत्र के रूप में एक आईडी टोकन का उपयोग कर सकते हैं। लेकिन इससे पहले कि आप आईडी टोकन में जानकारी का उपयोग कर सकें या उपयोगकर्ता द्वारा प्रमाणित किए गए दावे के रूप में उस पर भरोसा कर सकें, आपको इसे सत्यापित करना होगा।

एक आईडी टोकन के सत्यापन के लिए कई चरणों की आवश्यकता होती है:

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

चरण 2 से 5 में केवल स्ट्रिंग और तारीख की तुलना शामिल है जो काफी सीधी हैं, इसलिए हम उन्हें यहां विस्तार से नहीं बताएंगे।

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

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

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

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

उपयोगकर्ता के बारे में अतिरिक्त प्रोफ़ाइल जानकारी प्राप्त करने के लिए, आप एक्सेस टोकन (जो आपके एप्लिकेशन को प्रमाणीकरण प्रवाह के दौरान प्राप्त होता है) और ओपनआईडी कनेक्ट मानक का उपयोग कर सकते हैं:

  1. OpenID- अनुरूप होने के लिए, आपको अपने प्रमाणीकरण अनुरोध में openid profile स्कोप मान शामिल करना होगा।

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

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

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

OpenID Connect प्रोटोकॉल को उपयोगकर्ताओं को प्रमाणित करने के लिए, और टोकन, उपयोगकर्ता जानकारी और सार्वजनिक कुंजी सहित संसाधनों का अनुरोध करने के लिए कई समापन बिंदुओं के उपयोग की आवश्यकता होती है।

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

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

Google की OpenID Connect सेवाओं का उपयोग करने के लिए, आपको अपने ऐप्लिकेशन में Discovery-दस्तावेज़ URI ( https://accounts.google.com/.well-known/openid-configuration ) को हार्ड-कोड करना चाहिए। आपका एप्लिकेशन दस्तावेज़ प्राप्त करता है, प्रतिक्रिया में कैशिंग नियम लागू करता है, फिर आवश्यकतानुसार एंडपॉइंट यूआरआई पुनर्प्राप्त करता है। उदाहरण के लिए, किसी उपयोगकर्ता को प्रमाणित करने के लिए, आपका कोड authorization_endpoint मेटाडेटा मान ( https://accounts.google.com/o/oauth2/v2/auth नीचे दिए गए उदाहरण में) को प्रमाणीकरण अनुरोधों के लिए आधार URI के रूप में पुनः प्राप्त करेगा, जिन्हें भेजा जाता है गूगल।

ऐसे दस्तावेज़ का एक उदाहरण यहां दिया गया है; फ़ील्ड नाम वे हैं जो 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"
  ]
}

आप डिस्कवरी दस्तावेज़ से मानों को कैश करके HTTP राउंड-ट्रिप से बचने में सक्षम हो सकते हैं। मानक HTTP कैशिंग हेडर का उपयोग किया जाता है और उनका सम्मान किया जाना चाहिए।

ग्राहक पुस्तकालय

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

ओपनआईडी कनेक्ट अनुपालन

Google की OAuth 2.0 प्रमाणीकरण प्रणाली OpenID Connect कोर विनिर्देशन की आवश्यक सुविधाओं का समर्थन करती है। ओपनआईडी कनेक्ट के साथ काम करने के लिए डिज़ाइन किया गया कोई भी क्लाइंट इस सेवा के साथ इंटरऑपरेट करना चाहिए ( ओपनआईडी अनुरोध ऑब्जेक्ट के अपवाद के साथ)।