सबसे अच्छे तरीके

क्लाइंट क्रेडेंशियल को सुरक्षित तरीके से मैनेज करना

OAuth क्लाइंट क्रेडेंशियल से आपके ऐप्लिकेशन की पहचान की जाती है. इसलिए, इनका इस्तेमाल सावधानी से किया जाना चाहिए. इन क्रेडेंशियल को सिर्फ़ सुरक्षित स्टोरेज में सेव करें. उदाहरण के लिए, Google Cloud Secret Manager जैसे सीक्रेट मैनेजर का इस्तेमाल करें. क्रेडेंशियल को कोड में डालने के बजाय, उन्हें कोड रिपॉज़िटरी में डालें या सार्वजनिक तौर पर पब्लिश करें.

उपयोगकर्ता टोकन को सुरक्षित तरीके से मैनेज करना

उपयोगकर्ता टोकन में, आपके ऐप्लिकेशन के इस्तेमाल किए गए रिफ़्रेश टोकन और ऐक्सेस टोकन, दोनों शामिल होते हैं. स्टोर किए गए टोकन को सुरक्षित तरीके से सेव करें और उन्हें कभी भी सादे टेक्स्ट में ट्रांसमिट न करें. अपने प्लैटफ़ॉर्म के हिसाब से, सुरक्षित स्टोरेज सिस्टम का इस्तेमाल करें. जैसे, Android पर Keystore, iOS और macOS पर Keychain Services या Windows पर क्रेडेंशियल लॉकर.

ज़रूरत न पड़ने पर, टोकन रद्द करें और उन्हें अपने सिस्टम से हमेशा के लिए मिटाएं.

इसके अलावा, अपने प्लैटफ़ॉर्म के लिए ये सबसे सही तरीके भी आज़माएं:

• कई उपयोगकर्ताओं के लिए टोकन सेव करने वाले सर्वर-साइड ऐप्लिकेशन के लिए, उन्हें इस्तेमाल न होने पर एन्क्रिप्ट करें. साथ ही, पक्का करें कि आपका डेटा स्टोर, इंटरनेट पर सार्वजनिक तौर पर ऐक्सेस न किया जा सके.
• नेटिव डेस्कटॉप ऐप्लिकेशन के लिए, ऑथराइज़ेशन कोड पाने के लिए, कोड एक्सचेंज के लिए पुष्टि करने वाला पासकोड (PKCE) प्रोटोकॉल का इस्तेमाल करने का सुझाव दिया जाता है. इन कोड को ऐक्सेस टोकन से बदला जा सकता है.

रीफ़्रेश टोकन को रद्द करने और उसकी समयसीमा खत्म होने की स्थिति को मैनेज करना

अगर आपके ऐप्लिकेशन ने ऑफ़लाइन ऐक्सेस के लिए रीफ़्रेश टोकन का अनुरोध किया है, तो आपको टोकन के अमान्य होने या उसकी समयसीमा खत्म होने की स्थिति को भी मैनेज करना होगा. टोकन अलग-अलग वजहों से अमान्य हो सकते हैं. उदाहरण के लिए, हो सकता है कि उनकी समयसीमा खत्म हो गई हो या उपयोगकर्ता या ऑटोमेटेड प्रोसेस (कार्रवाइयों को अपने-आप पूरा करने वाला सिस्टम) ने आपके ऐप्लिकेशन का ऐक्सेस रद्द कर दिया हो. इस मामले में, इस बात पर ध्यान दें कि आपका ऐप्लिकेशन कैसे जवाब देगा. इसमें, उपयोगकर्ता के अगले लॉग इन पर उसे सूचना देना या उसका डेटा मिटाना शामिल है. टोकन रद्द होने की सूचना पाने के लिए, सभी खातों की सुरक्षा सेवा के साथ इंटिग्रेट करें.

इंंक्रीमेंटल अनुमति का इस्तेमाल करना

जब आपके ऐप्लिकेशन को किसी फ़ंक्शन की ज़रूरत हो, तो सही OAuth स्कोप का अनुरोध करने के लिए, बढ़ते अनुमति का इस्तेमाल करें.

जब उपयोगकर्ता पहली बार पुष्टि करता है, तब आपको डेटा के ऐक्सेस का अनुरोध नहीं करना चाहिए. ऐसा तब ही करें, जब यह आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए ज़रूरी हो. इसके बजाय, सिर्फ़ उन खास स्कोप के लिए अनुरोध करें जो किसी टास्क के लिए ज़रूरी हैं. साथ ही, सबसे छोटे और सीमित स्कोप चुनने के सिद्धांत का पालन करें.

हमेशा संदर्भ के हिसाब से स्कोप का अनुरोध करें, ताकि उपयोगकर्ता यह समझ सकें कि आपका ऐप्लिकेशन ऐक्सेस का अनुरोध क्यों कर रहा है और डेटा का इस्तेमाल कैसे किया जाएगा.

उदाहरण के लिए, आपका ऐप्लिकेशन इस मॉडल का इस्तेमाल कर सकता है:

1. उपयोगकर्ता आपके ऐप्लिकेशन से पुष्टि करता है
   1. किसी अन्य स्कोप का अनुरोध नहीं किया जाता. ऐप्लिकेशन में बुनियादी सुविधाएं मौजूद होती हैं, ताकि उपयोगकर्ता उन सुविधाओं को एक्सप्लोर और इस्तेमाल कर सकें जिनके लिए किसी अतिरिक्त डेटा या ऐक्सेस की ज़रूरत नहीं होती.
2. उपयोगकर्ता ऐसी सुविधा चुनता है जिसके लिए ज़्यादा डेटा का ऐक्सेस चाहिए
   1. आपका ऐप्लिकेशन, इस सुविधा के लिए ज़रूरी OAuth स्कोप के लिए अनुमति का अनुरोध करता है. अगर इस सुविधा के लिए एक से ज़्यादा स्कोप की ज़रूरत है, तो नीचे दिए गए सबसे सही तरीके अपनाएं.
   2. अगर उपयोगकर्ता अनुरोध अस्वीकार करता है, तो ऐप्लिकेशन इस सुविधा को बंद कर देता है. साथ ही, उपयोगकर्ता को ऐक्सेस का अनुरोध फिर से करने के लिए, ज़्यादा जानकारी देता है.

एक से ज़्यादा स्कोप के लिए सहमति मैनेज करना

एक साथ कई स्कोप का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके अनुरोध किए गए सभी OAuth स्कोप न दें. आपके ऐप्लिकेशन को ज़रूरी फ़ंक्शन बंद करके, स्कोप अस्वीकार किए जाने की समस्या को मैनेज करना चाहिए.

अगर आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए कई स्कोप की ज़रूरत है, तो सहमति का अनुरोध करने से पहले उपयोगकर्ता को इसकी जानकारी दें.

उपयोगकर्ता को फिर से सिर्फ़ तब अनुमति मांगी जा सकती है, जब वह साफ़ तौर पर बता दे कि उसे उस सुविधा का इस्तेमाल करना है जिसके लिए अनुमति की ज़रूरत है. OAuth स्कोप का अनुरोध करने से पहले, आपके ऐप्लिकेशन को उपयोगकर्ता को काम का कॉन्टेक्स्ट और वजह बतानी चाहिए.

आपको एक बार में, अपने ऐप्लिकेशन के अनुरोधों के दायरों की संख्या कम से कम रखनी चाहिए. इसके बजाय, बढ़ती हुई अनुमति का इस्तेमाल करें, ताकि सुविधाओं और फ़ंक्शन के संदर्भ में, अनुमतियों के दायरे का अनुरोध किया जा सके.

सुरक्षित ब्राउज़र का इस्तेमाल करना

वेब पर, OAuth 2.0 से अनुमति पाने के अनुरोध सिर्फ़ उन वेब ब्राउज़र से किए जाने चाहिए जिनमें सभी सुविधाएं मौजूद हों. अन्य प्लैटफ़ॉर्म पर, सही OAuth क्लाइंट टाइप चुनना न भूलें. साथ ही, अपने प्लैटफ़ॉर्म के हिसाब से OAuth को इंटिग्रेट करें. अनुरोध को एम्बेड किए गए ब्राउज़िंग एनवायरमेंट के ज़रिए रीडायरेक्ट न करें. इनमें मोबाइल प्लैटफ़ॉर्म पर वेबव्यू भी शामिल हैं, जैसे कि Android पर वेबव्यू या iOS पर WKWebView. इसके बजाय, अपने प्लैटफ़ॉर्म के लिए नेटिव OAuth लाइब्रेरी या Google साइन-इन का इस्तेमाल करें.

OAuth क्लाइंट को मैन्युअल तरीके से बनाना और कॉन्फ़िगर करना

गलत इस्तेमाल को रोकने के लिए, OAuth क्लाइंट को प्रोग्राम के हिसाब से नहीं बनाया जा सकता या उनमें बदलाव नहीं किया जा सकता. आपको सेवा की शर्तों को साफ़ तौर पर स्वीकार करने, अपने OAuth क्लाइंट को कॉन्फ़िगर करने, और OAuth की पुष्टि के लिए तैयार होने के लिए, Google Developers Console का इस्तेमाल करना होगा.

ऑटोमेटेड वर्कफ़्लो के लिए, इसके बजाय सेवा खातों का इस्तेमाल करें.

इस्तेमाल नहीं किए जा रहे OAuth क्लाइंट हटाना

अपने OAuth 2.0 क्लाइंट का नियमित तौर पर ऑडिट करें और उन क्लाइंट को मिटाएं जिनकी अब आपके ऐप्लिकेशन को ज़रूरत नहीं है या जो अब काम नहीं करते. इस्तेमाल न किए गए क्लाइंट को कॉन्फ़िगर करके छोड़ने से, सुरक्षा से जुड़ा संभावित खतरा हो सकता है. ऐसा इसलिए, क्योंकि अगर आपके क्लाइंट क्रेडेंशियल का कभी भी गलत इस्तेमाल किया जाता है, तो क्लाइंट का गलत इस्तेमाल किया जा सकता है.

इस्तेमाल नहीं किए जा रहे क्लाइंट से जुड़े जोखिमों को कम करने के लिए, ऐसे OAuth 2.0 क्लाइंट अपने-आप मिटा दिए जाते हैं जो छह महीने से इस्तेमाल नहीं किए गए हैं.

हमारा सुझाव है कि आप अपने-आप मिटने का इंतज़ार न करें, बल्कि इस्तेमाल न किए जा रहे क्लाइंट को पहले ही हटा दें. इससे आपके ऐप्लिकेशन पर हमले की संभावना कम हो जाती है और यह पक्का होता है कि ऐप्लिकेशन की सुरक्षा अच्छी है.