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

Google का OpenID कनेक्ट एंडपॉइंट OpenID प्रमाणित है।

Google के OAuth 2.0 API का उपयोग प्रमाणीकरण और प्राधिकरण दोनों के लिए किया जा सकता है। यह दस्तावेज़ प्रमाणीकरण के लिए हमारे OAuth 2.0 कार्यान्वयन का वर्णन करता है, जो OpenID कनेक्ट विनिर्देश के अनुरूप है, और OpenID प्रमाणित है । Google API तक पहुँचने के लिए OAuth 2.0 का उपयोग करते हुए पाया गया दस्तावेज़ भी इस सेवा पर लागू होता है। यदि आप इस प्रोटोकॉल का अंतःक्रियात्मक रूप से अन्वेषण करना चाहते हैं, तो हम Google OAuth 2.0 खेल का मैदान सुझाते हैं। स्टैक ओवरफ्लो पर मदद पाने के लिए, अपने प्रश्नों को '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 तक पहुंच प्राप्त करने के लिए आपको क्लाइंट ID और क्लाइंट रहस्य सहित OAuth 2.0 क्रेडेंशियल्स की आवश्यकता है।

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

या, API Console में क्रेडेंशियल पेज से अपनी क्लाइंट आईडी और क्लाइंट सीक्रेट API Console :

Go to the Credentials page.
अपने क्रेडेंशियल या पेंसिल ( ) आइकन के नाम पर क्लिक करें। आपकी क्लाइंट आईडी और रहस्य पृष्ठ के शीर्ष पर हैं।

एक अनुप्रेषित URI सेट करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सर्वर का प्रवाह

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

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

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

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

एक राज्य टोकन के लिए एक अच्छा विकल्प 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 को एक प्रमाणीकरण अनुरोध भेजें

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

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

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

यहाँ एक पूर्ण OpenID कनेक्ट प्रमाणीकरण URI का उदाहरण है, जिसमें पठनीयता के लिए लाइन ब्रेक और रिक्त स्थान हैं:

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 में बनाए गए सत्र टोकन की पुष्टि की है:

पीएचपी

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

जावा

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

अजगर

# 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`

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

खेत
`code`	प्रारंभिक अनुरोध से वापस किया गया प्राधिकरण कोड।
`client_id`	क्लाइंट ID जिसे आप API Console Credentials page से प्राप्त करते हैं, जैसा कि ओबहुत OAuth 2.0 क्रेडेंशियल्स में वर्णित है।
`client_secret`	क्लाइंट रहस्य जिसे आप API Console Credentials page से प्राप्त करते हैं, जैसा कि ओबहुत 2.0 क्रेडेंशियल्स में वर्णित है।
`redirect_uri`	एक अधिकृत रीडायरेक्ट दिया यूआरआई `client_id` , API Console Credentials page में निर्दिष्ट में वर्णित के रूप में सेट एक रीडायरेक्ट यूआरआई ।
`grant_type`	इस क्षेत्र में `authorization_code` मान होना चाहिए, जैसा कि OAuth 2.0 विनिर्देश में परिभाषित किया गया है ।

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

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

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

इस अनुरोध की एक सफल प्रतिक्रिया में JSON सरणी में निम्नलिखित फ़ील्ड शामिल हैं:

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

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

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

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

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

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

07404 एफ 590

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 पर ऐसा मामला हो सकता है जहां एक वेब एप्लिकेशन और एंड्रॉइड ऐप का एक अलग OAuth 2.0 `client_id` लेकिन उसी Google API प्रोजेक्ट को साझा करें।
`email`		उपयोगकर्ता का ईमेल पता। यह मान इस उपयोगकर्ता के लिए अद्वितीय नहीं हो सकता है और प्राथमिक कुंजी के रूप में उपयोग के लिए उपयुक्त नहीं है। बशर्ते आपके दायरे में `email` स्कोप मान शामिल हो।
`email_verified`		यदि उपयोगकर्ता का ई-मेल पता सत्यापित किया गया है तो यह सच है; अन्यथा झूठ है।
`family_name`		उपयोगकर्ता का उपनाम (s) या अंतिम नाम एक `name` दावा मौजूद होने पर प्रदान किया जा सकता है।
`given_name`		उपयोगकर्ता का दिया गया नाम या पहला नाम। एक `name` दावा मौजूद होने पर प्रदान किया जा सकता है।
`hd`		उपयोगकर्ता का होस्ट किया गया जी सूट डोमेन। बशर्ते उपयोगकर्ता होस्ट किए गए डोमेन से संबंधित हो।
`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 का स्कोप पैरामीटर पास openid email https://www.googleapis.com/auth/profile.agerange.read । उपयोगकर्ता को सहमति स्क्रीन पर उचित रूप से संकेत दिया जाता है। Google से आपको प्राप्त होने वाला एक्सेस टोकन आपको आपके द्वारा अनुरोधित पहुँच के स्कोप से संबंधित सभी API तक पहुँचने और अनुमति प्रदान करने की अनुमति देता है।

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

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

विचार:

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

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

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

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

प्रमाणीकरण URI पैरामीटर

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

पैरामीटर	अपेक्षित	विवरण
`client_id`	(आवश्यक)	क्लाइंट ID स्ट्रिंग जिसे आप API Console Credentials page से प्राप्त करते हैं, जैसा कि ओबट ओट 2.0 क्रेडेंशियल्स में वर्णित है।
`nonce`	(आवश्यक)	आपके एप्लिकेशन द्वारा उत्पन्न एक यादृच्छिक मान जो पुनरावृत्ति सुरक्षा को सक्षम करता है।
`response_type`	(आवश्यक)	यदि मान `code` , तो मूल प्राधिकरण कोड प्रवाह लॉन्च करता है, टोकन प्राप्त करने के लिए टोकन समापन बिंदु के लिए `POST` आवश्यकता होती है। यदि मान `token id_token` या `id_token token` , तो Implicit flow `id_token token` करता है, जिससे URI `#fragment` पहचानकर्ता से टोकन पुनः प्राप्त करने के लिए रीडायरेक्ट URI पर JavaScript के उपयोग की आवश्यकता होती है।
`redirect_uri`	(आवश्यक)	निर्धारित करता है कि प्रतिक्रिया कहां भेजी जाती है। इस पैरामीटर का मान किसी अधिकृत रीडायरेक्ट मान से मेल खाना चाहिए जो आप API Console Credentials page (HTTP या HTTPS स्कीम, केस और ट्रेलिंग '/' सहित, यदि कोई हो) में सेट करें।
`scope`	(आवश्यक)	स्कोप पैरामीटर को `openid` वैल्यू से शुरू करना चाहिए और फिर `profile` वैल्यू, `email` वैल्यू या दोनों को शामिल करना चाहिए। यदि `profile` स्कोप मान मौजूद है, तो आईडी टोकन उपयोगकर्ता के डिफ़ॉल्ट `profile` दावों में शामिल हो सकता है (लेकिन इसकी गारंटी नहीं है)। यदि `email` स्कोप मान मौजूद है, तो ID टोकन में `email` और `email_verified` दावे शामिल हैं। इन OpenID- विशिष्ट स्कोपों के अतिरिक्त, आपके स्कोप तर्क में अन्य स्कोप मान भी शामिल हो सकते हैं। सभी स्कोप वैल्यूज़ को अलग-अलग होना चाहिए। उदाहरण के लिए, यदि आप किसी उपयोगकर्ता के Google ड्राइव पर प्रति-फ़ाइल पहुँच चाहते हैं, तो आपका स्कोप पैरामीटर `openid profile email https://www.googleapis.com/auth/drive.file` हो सकता है। उपलब्ध स्कोप के बारे में जानकारी के लिए, Google API के लिए OAuth 2.0 स्कोप या उस Google API के लिए दस्तावेज़ देखें, जिसका आप उपयोग करना चाहते हैं।
`state`	(वैकल्पिक, लेकिन दृढ़ता से अनुशंसित)	एक अपारदर्शी स्ट्रिंग जो प्रोटोकॉल में गोल-ट्रिप्ड है; यह कहना है, यह मूल प्रवाह में एक URI पैरामीटर के रूप में दिया गया है, और URI `#fragment` पहचानकर्ता में निहित प्रवाह में। `state` अनुरोधों और प्रतिक्रियाओं के सहसंबंध के लिए उपयोगी हो सकता है। चूँकि आपके `redirect_uri` का अनुमान लगाया जा सकता है, `state` मूल्य का उपयोग करने से आपका आश्वासन बढ़ सकता है कि आने वाला कनेक्शन आपके ऐप द्वारा शुरू किए गए प्रमाणीकरण अनुरोध का परिणाम है। यदि आप एक यादृच्छिक स्ट्रिंग उत्पन्न करते हैं या इस `state` चर में कुछ क्लाइंट राज्य (जैसे, एक कुकी) के हैश को एनकोड करते हैं, तो आप अतिरिक्त रूप से सुनिश्चित करने के लिए प्रतिक्रिया को मान्य कर सकते हैं कि अनुरोध और प्रतिक्रिया एक ही ब्राउज़र में उत्पन्न हुई है। यह क्रॉस-साइट अनुरोध जालसाजी जैसे हमलों से सुरक्षा प्रदान करता है।
`access_type`	(वैकल्पिक)	अनुमत मान `offline` और `online` । प्रभाव ऑफ़लाइन पहुँच में प्रलेखित है; यदि पहुँच टोकन का अनुरोध किया जा रहा है, तो ग्राहक को ताज़ा टोकन प्राप्त नहीं होता है जब तक कि `offline` का मान निर्दिष्ट नहीं किया जाता है।
`display`	(वैकल्पिक)	प्रमाणीकरण सर्वर और प्रमाणीकरण उपयोगकर्ता सहमति पृष्ठों को कैसे प्रदर्शित करता है यह निर्दिष्ट करने के लिए ASCII स्ट्रिंग मान। निम्न मान निर्दिष्ट हैं, और Google सर्वर द्वारा स्वीकार किए जाते हैं, लेकिन इसके व्यवहार पर कोई प्रभाव नहीं पड़ता है: `page` , `popup` , `touch` , और `wap` ।
`hd`	(वैकल्पिक)	`hd` (होस्टेड डोमेन) पैरामीटर जी सूट होस्ट किए गए खातों के लिए लॉगिन प्रक्रिया को सुव्यवस्थित करता है। जी सूट उपयोगकर्ता (उदाहरण के लिए, `mycollege.edu` ) के डोमेन को शामिल करके, आप यह संकेत कर सकते हैं कि उस डोमेन पर खातों के लिए खाता चयन UI को अनुकूलित किया जाना चाहिए। आमतौर पर सिर्फ एक डोमेन के बजाय जी सूट खातों के लिए अनुकूलन करने के लिए, तारांकन चिह्न ( `` ): `hd=` मान सेट करें। इस यूआई ऑप्टिमाइज़ेशन पर भरोसा न करें जो आपके ऐप को एक्सेस करने के लिए नियंत्रित कर सकता है, क्योंकि क्लाइंट-साइड अनुरोध संशोधित किए जा सकते हैं। सुनिश्चित करें कि करने के लिए हो सकता है सत्यापित करें कि लौटे आईडी टोकन एक है `hd` दावा मूल्य कि मैचों आप क्या अपेक्षा (जैसे `mycolledge.edu` )। अनुरोध पैरामीटर के विपरीत, आईडी टोकन `hd` दावा Google से सुरक्षा टोकन में निहित है, इसलिए मूल्य पर भरोसा किया जा सकता है।
`include_granted_scopes`	(वैकल्पिक)	यदि यह पैरामीटर `true` मान के साथ प्रदान किया जाता `true` , और प्राधिकरण अनुरोध प्रदान किया जाता है, तो प्राधिकरण इस उपयोगकर्ता को दिए गए किसी भी पिछले प्राधिकरण / अन्य स्कोप के लिए आवेदन संयोजन शामिल करेगा; वृद्धिशील प्राधिकरण देखें। ध्यान दें कि आप इंस्टॉल किए गए ऐप प्रवाह के साथ वृद्धिशील प्राधिकरण नहीं कर सकते।
`login_hint`	(वैकल्पिक)	जब आपका ऐप जानता है कि वह किस उपयोगकर्ता को प्रमाणित करने की कोशिश कर रहा है, तो वह इस पैरामीटर को प्रमाणीकरण सर्वर को संकेत के रूप में प्रदान कर सकता है। इस संकेत को पास करना खाता चयनकर्ता को दबा देता है और या तो साइन-इन फॉर्म पर ईमेल बॉक्स को भर देता है, या उचित सत्र (यदि उपयोगकर्ता कई साइन-इन का उपयोग कर रहा है) का चयन करता है, जो आपके ऐप के होने पर होने वाली समस्याओं से बचने में आपकी मदद कर सकता है। गलत उपयोगकर्ता खाते में लॉग। मान या तो एक ईमेल पता या `sub` स्ट्रिंग हो सकता है, जो उपयोगकर्ता की Google आईडी के बराबर है।
`prompt`	(वैकल्पिक)	स्ट्रिंग मानों की एक स्थान-सीमांकित सूची जो यह निर्दिष्ट करती है कि प्राधिकरण सर्वर उपयोगकर्ता को सौंदर्यीकरण और सहमति के लिए प्रेरित करता है या नहीं। संभावित मूल्य हैं: `none` प्राधिकरण सर्वर कोई प्रमाणीकरण या उपयोगकर्ता सहमति स्क्रीन प्रदर्शित नहीं करता है; यदि उपयोगकर्ता पहले से ही प्रमाणित नहीं है और अनुरोधित स्कोप के लिए पूर्व-कॉन्फ़िगर सहमति नहीं है, तो यह एक त्रुटि लौटाएगा। आप मौजूदा प्रमाणीकरण और / या सहमति की जांच करने के लिए `none` उपयोग `none` कर सकते। `consent` प्राधिकरण सर्वर क्लाइंट को जानकारी वापस करने से पहले उपयोगकर्ता को सहमति के लिए संकेत देता है। `select_account` प्राधिकरण सर्वर उपयोगकर्ता को उपयोगकर्ता खाता चुनने के लिए प्रेरित करता है। यह एक ऐसे उपयोगकर्ता को अनुमति देता है, जिनके पास अधिकृत खातों में एकाधिक सत्रों में से कई खातों का चयन करने के लिए है, जिनके लिए उनके पास वर्तमान सत्र हो सकते हैं। यदि कोई मूल्य निर्दिष्ट नहीं है और उपयोगकर्ता ने पहले से अधिकृत उपयोग नहीं किया है, तो उपयोगकर्ता को एक सहमति स्क्रीन दिखाई जाती है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यहाँ इस तरह के एक दस्तावेज का एक उदाहरण है; फ़ील्ड नाम ओपनआईडी कनेक्ट डिस्कवरी 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 को सरल बना रहे हैं:

OpenID कनेक्ट अनुपालन

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

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

OAuth 2.0 की स्थापना

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

एक अनुप्रेषित URI सेट करें

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

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

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

सर्वर का प्रवाह

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

पीएचपी

जावा

अजगर

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

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

पीएचपी

जावा

अजगर

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

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

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

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

उन्नत विषय

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

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

फिर से सहमति देना

प्रमाणीकरण URI पैरामीटर

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

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

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

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

OpenID कनेक्ट अनुपालन

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