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