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