इस पेज पर, OAuth 2.0 के साथ इंटिग्रेट करने के सबसे सही तरीकों के बारे में बताया गया है. अपने ऐप्लिकेशन और डेवलपमेंट प्लैटफ़ॉर्म के बारे में खास दिशा-निर्देशों के साथ-साथ, इन सबसे सही तरीकों को भी ध्यान में रखें. अपने ऐप्लिकेशन को प्रोडक्शन के लिए तैयार करने से जुड़ी सलाह और Google की OAuth 2.0 नीतियां देखें.
क्लाइंट के क्रेडेंशियल सुरक्षित तरीके से इस्तेमाल करना
OAuth क्लाइंट के क्रेडेंशियल, आपके ऐप्लिकेशन की पहचान करते हैं. इसलिए, इन्हें सावधानी से हैंडल करना चाहिए. इन क्रेडेंशियल को सिर्फ़ सुरक्षित स्टोरेज में सेव करें. उदाहरण के लिए, Google Cloud Secret Manager जैसे किसी सीक्रेट मैनेजर का इस्तेमाल करना. क्रेडेंशियल को हार्डकोड न करें, उन्हें किसी कोड रिपॉज़िटरी में ले जाएं या उन्हें सार्वजनिक रूप से पब्लिश न करें.
उपयोगकर्ता टोकन को सुरक्षित तरीके से इस्तेमाल करना
उपयोगकर्ता टोकन में रीफ़्रेश टोकन और आपके ऐप्लिकेशन के इस्तेमाल किए जाने वाले ऐक्सेस टोकन, दोनों शामिल होते हैं. इनऐक्टिव टोकन को सुरक्षित तरीके से सेव करें और उन्हें कभी भी सादे टेक्स्ट में न भेजें. अपने प्लैटफ़ॉर्म के हिसाब से सही स्टोरेज सिस्टम का इस्तेमाल करें. जैसे, Android पर Keystore, iOS और macOS पर Keychain Services या 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 का इस्तेमाल करना होगा.
अपने-आप काम करने वाले वर्कफ़्लो के लिए, इसके बजाय सेवा खातों का इस्तेमाल करें.