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