क्रॉस-क्लाइंट पहचान

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

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

दुनिया के इस व्यू के साथ काम करने वाला, Google का OAuth 2.0 लागू होता है. किसी भी OAuth2.0 पर आधारित सेवा का इस्तेमाल करने के लिए, आपको अपने सॉफ़्टवेयर को Google API Consoleमें सेट अप करना होगा. API Console में संगठन की इकाई एक "प्रोजेक्ट और कोट है; जो कई घटक वाले ऐप्लिकेशन के हिसाब से हो सकता है. हर प्रोजेक्ट के लिए, आप ब्रैंडिंग की जानकारी दे सकते हैं, और आपको यह बताना होगा कि ऐप्लिकेशन किन एपीआई को ऐक्सेस करेगा. मल्टी-कॉम्पोनेंट ऐप्लिकेशन के हर कॉम्पोनेंट की पहचान, क्लाइंट आईडी से होती है. यह एक यूनीक स्ट्रिंग होती है, जो API Consoleमें जनरेट होती है.

क्रॉस-क्लाइंट अनुमति के लक्ष्य

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

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

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

क्रॉस-क्लाइंट ऐक्सेस टोकन

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

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

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