इस पेज पर, OAuth 2.0 के साथ इंटिग्रेट करने के सबसे सही तरीके बताए गए हैं. ऐप्लिकेशन और डेवलपमेंट प्लैटफ़ॉर्म के हिसाब से दिशा-निर्देशों के साथ-साथ, इन सबसे सही तरीकों को भी ध्यान में रखें. अपने ऐप्लिकेशन को प्रोडक्शन के लिए तैयार करने से जुड़ी सलाह और Google की OAuth 2.0 नीतियों को भी देखें.
क्लाइंट के क्रेडेंशियल सुरक्षित तरीके से मैनेज करना
OAuth क्लाइंट क्रेडेंशियल आपके ऐप्लिकेशन की पहचान की पहचान करते हैं. इनका इस्तेमाल सावधानी से किया जाना चाहिए. इन क्रेडेंशियल को सिर्फ़ सुरक्षित स्टोरेज में सेव करें. उदाहरण के लिए, Google Cloud के सीक्रेट मैनेजर जैसे किसी सीक्रेट मैनेजर का इस्तेमाल करके. क्रेडेंशियल को हार्डकोड न करें. उन्हें कोड रिपॉज़िटरी (डेटा स्टोर करने की जगह) में भेजें या उन्हें सार्वजनिक तौर पर पब्लिश करें.
उपयोगकर्ता टोकन को सुरक्षित तरीके से इस्तेमाल करें
उपयोगकर्ता टोकन में रीफ़्रेश टोकन और आपके ऐप्लिकेशन के इस्तेमाल किए जाने वाले ऐक्सेस टोकन, दोनों शामिल होते हैं. इस्तेमाल न होने पर टोकन को सुरक्षित रूप से स्टोर करें और उन्हें कभी भी सादे टेक्स्ट में न भेजें. ऐसे सुरक्षित स्टोरेज सिस्टम का इस्तेमाल करें जो आपके प्लैटफ़ॉर्म के हिसाब से सही हो. जैसे, Android पर Keystore, iOS और macOS पर Keychain सेवाएं या Windows पर Credential Locker.
जब टोकन की ज़रूरत न हो, तब टोकन रद्द कर दें और उन्हें अपने सिस्टम से हमेशा के लिए मिटा दें.
इसके अलावा, अपने प्लैटफ़ॉर्म के लिए इन सबसे सही तरीकों को भी ध्यान में रखें:
- कई उपयोगकर्ताओं के लिए टोकन स्टोर करने वाले सर्वर-साइड ऐप्लिकेशन के लिए, उन्हें इनऐक्टिव होने के दौरान एन्क्रिप्ट (सुरक्षित) करें. साथ ही, पक्का करें कि आपका डेटा स्टोर, इंटरनेट पर सार्वजनिक तौर पर ऐक्सेस न किया जा सके.
- हमारा सुझाव है कि नेटिव डेस्कटॉप ऐप्लिकेशन के लिए, कोड एक्सचेंज के लिए प्रूफ़ की (PKCE) प्रोटोकॉल का इस्तेमाल करके, ऐसे ऑथराइज़ेशन कोड हासिल करें जिनका इस्तेमाल ऐक्सेस टोकन के लिए किया जा सकता है.
टोकन रीफ़्रेश करने और उसकी समयसीमा खत्म होने की जानकारी को मैनेज करना
अगर आपके ऐप्लिकेशन ने ऑफ़लाइन ऐक्सेस के लिए रीफ़्रेश टोकन का अनुरोध किया है, तो आपको उनके अमान्य होने या समयसीमा खत्म होने की तारीख को भी मैनेज करना होगा. टोकन, अलग-अलग वजहों से अमान्य हो सकते हैं. उदाहरण के लिए, हो सकता है कि उनकी समयसीमा खत्म हो गई हो या उपयोगकर्ता ने आपके ऐप्लिकेशन के ऐक्सेस को रद्द कर दिया हो या अपने-आप काम करने वाली किसी प्रोसेस ने ऐसा किया हो. ऐसा होने पर, इस बात पर ध्यान दें कि आपके ऐप्लिकेशन को किस तरह जवाब देना चाहिए. इसमें, उपयोगकर्ता को अगले लॉग इन के समय साइन इन करने या उसका डेटा हटाने के लिए कहना चाहिए. टोकन रद्द होने की सूचना पाने के लिए, सभी खातों की सुरक्षा सेवा के साथ इंटिग्रेट करें.
वृद्धिशील प्राधिकरण का उपयोग करें
अगर आपके ऐप्लिकेशन के लिए फ़ंक्शन की ज़रूरत हो, तो सही OAuth दायरों का अनुरोध करने के लिए, इंक्रीमेंटल अनुमति का इस्तेमाल करें.
जब उपयोगकर्ता पहली बार पुष्टि करता है, तब आपको डेटा के ऐक्सेस का अनुरोध तब नहीं करना चाहिए, जब यह आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए ज़रूरी हो. इसके बजाय, सिर्फ़ उन खास दायरों का अनुरोध करें जो किसी काम के लिए ज़रूरी हैं. इसके लिए, सबसे छोटे और सीमित दायरे चुनने के नियम का पालन करें.
हमेशा कॉन्टेक्स्ट के हिसाब से स्कोप का अनुरोध करें, ताकि उपयोगकर्ता यह समझ सकें कि आपका ऐप्लिकेशन ऐक्सेस का अनुरोध क्यों कर रहा है और डेटा का इस्तेमाल कैसे किया जाएगा.
उदाहरण के लिए, आपका ऐप्लिकेशन इस मॉडल का पालन कर सकता है:
- उपयोगकर्ता आपके ऐप्लिकेशन से पुष्टि करता है
- किसी अतिरिक्त दायरे का अनुरोध नहीं किया गया है. इस ऐप्लिकेशन में कुछ बुनियादी सुविधाएं मिलती हैं. इनसे लोगों को उन सुविधाओं को एक्सप्लोर करने और इस्तेमाल करने की सुविधा मिलती है जिनके लिए न तो किसी और डेटा या ऐक्सेस की ज़रूरत होती है.
- उपयोगकर्ता ऐसी सुविधा को चुनता है जिसे अतिरिक्त डेटा का ऐक्सेस चाहिए
- आपका ऐप्लिकेशन, इस सुविधा के लिए ज़रूरी इस OAuth दायरे के लिए अनुमति का अनुरोध करता है. अगर इस सुविधा के लिए एक से ज़्यादा दायरे ज़रूरी हैं, तो नीचे दिए गए सबसे सही तरीके अपनाएं.
- अगर उपयोगकर्ता अनुरोध को अस्वीकार कर देता है, तो ऐप्लिकेशन इस सुविधा को बंद कर देता है. साथ ही, ऐक्सेस के लिए फिर से अनुरोध करने के लिए, उपयोगकर्ता को ज़्यादा जानकारी दी जाती है.
एक से ज़्यादा स्कोप के लिए सहमति मैनेज करना
एक साथ कई स्कोप का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके अनुरोध किए गए सभी OAuth दायरों को अनुमति न दे पाएं. आपके ऐप्लिकेशन को दायरे से जुड़ी दिक्कतों को दूर करने के लिए, काम की सुविधाओं को बंद करना चाहिए.
अगर आपके ऐप्लिकेशन के बुनियादी फ़ंक्शन के लिए एक से ज़्यादा स्कोप ज़रूरी हैं, तो उपयोगकर्ता को सहमति के लिए अनुरोध करने से पहले इस बारे में बताएं.
उपयोगकर्ताओं को फिर से तब ही अनुरोध किया जा सकता है, जब उन्होंने साफ़ तौर पर बताया हो कि वे उस सुविधा का इस्तेमाल करना चाहते हैं जिसके लिए दायरे की ज़रूरत होती है. OAuth स्कोप का अनुरोध करने से पहले, आपके ऐप्लिकेशन को उपयोगकर्ता को सही कॉन्टेक्स्ट और वजह बतानी चाहिए.
आपको एक बार में अपने ऐप्लिकेशन के अनुरोधों की संख्या कम करनी चाहिए. इसके बजाय, सुविधाओं और फ़ंक्शन के मामले में स्कोप का अनुरोध करने के लिए, इंक्रीमेंटल अनुमति का इस्तेमाल करें.
सुरक्षित ब्राउज़र इस्तेमाल करना
वेब पर, OAuth 2.0 के लिए अनुमति देने के अनुरोध सिर्फ़ ऐसे वेब ब्राउज़र से किए जाने चाहिए जिनमें सभी सुविधाएं मौजूद हों. दूसरे प्लैटफ़ॉर्म पर, सही OAuth क्लाइंट टाइप चुनें और अपने प्लैटफ़ॉर्म के हिसाब से OAuth को इंटिग्रेट करें. एम्बेड किए गए ब्राउज़िंग प्लैटफ़ॉर्म के ज़रिए अनुरोध को रीडायरेक्ट न करें. इनमें मोबाइल प्लैटफ़ॉर्म पर वेबव्यू, जैसे कि Android पर वेबव्यू या iOS पर WKWebView शामिल हैं. इसके बजाय, अपने प्लैटफ़ॉर्म के लिए नेटिव OAuth लाइब्रेरी या Google साइन-इन का इस्तेमाल करें.
OAuth क्लाइंट का मैन्युअल बनाना और कॉन्फ़िगरेशन
गलत इस्तेमाल को रोकने के लिए, OAuth क्लाइंट को प्रोग्राम के हिसाब से न तो बनाया जा सकता है और न ही उनमें कोई बदलाव किया जा सकता है. सेवा की शर्तों को साफ़ तौर पर स्वीकार करने, अपने OAuth क्लाइंट को कॉन्फ़िगर करने, और OAuth की पुष्टि करने की तैयारी करने के लिए, आपको Google Developers Console का इस्तेमाल करना होगा.
अपने-आप काम करने वाले वर्कफ़्लो के लिए, इसके बजाय सेवा खातों का इस्तेमाल करें.