डेवलपर जब सॉफ़्टवेयर बनाते हैं, तो उसमें आम तौर पर ऐसे मॉड्यूल शामिल होते हैं जो वेब सर्वर पर चलते हैं. साथ ही, ऐसे मॉड्यूल भी शामिल होते हैं जो ब्राउज़र में चलते हैं. इसके अलावा, ऐसे मॉड्यूल भी शामिल होते हैं जो Android या iOS मोबाइल ऐप्लिकेशन के तौर पर चलते हैं. आम तौर पर, डेवलपर और उनके सॉफ़्टवेयर का इस्तेमाल करने वाले लोग, इन सभी मॉड्यूल को एक ही ऐप्लिकेशन का हिस्सा मानते हैं.
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 ऐक्सेस टोकन कई तरीकों से पा सकता है. यह इस बात पर निर्भर करता है कि कोड किस प्लैटफ़ॉर्म पर चल रहा है. ज़्यादा जानकारी के लिए, OAuth 2.0 का इस्तेमाल करके, Google API को ऐक्सेस करना लेख पढ़ें. आम तौर पर, ऐक्सेस टोकन देते समय उपयोगकर्ता की सहमति लेना ज़रूरी होता है.
अच्छी बात यह है कि Google का अनुमति देने वाला इन्फ़्रास्ट्रक्चर, किसी प्रोजेक्ट में मौजूद क्लाइंट आईडी के लिए उपयोगकर्ता की अनुमतियों के बारे में जानकारी का इस्तेमाल कर सकता है. इससे यह तय करने में मदद मिलती है कि उसी प्रोजेक्ट में मौजूद अन्य लोगों को अनुमति दी जाए या नहीं.
इसका मतलब यह है कि अगर कोई Android ऐप्लिकेशन किसी स्कोप के लिए ऐक्सेस टोकन का अनुरोध करता है और अनुरोध करने वाले उपयोगकर्ता ने उसी प्रोजेक्ट में मौजूद किसी वेब ऐप्लिकेशन को उस स्कोप के लिए पहले ही अनुमति दे दी है, तो उपयोगकर्ता से अनुमति के लिए दोबारा नहीं पूछा जाएगा. यह दोनों तरह से काम करता है: अगर आपके Android ऐप्लिकेशन में किसी स्कोप का ऐक्सेस दिया गया है, तो उसी प्रोजेक्ट में किसी दूसरे क्लाइंट, जैसे कि वेब ऐप्लिकेशन से फिर से ऐक्सेस नहीं मांगा जाएगा.