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

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

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

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

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

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

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

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

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

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

ज़्यादा अनुमति मांगने की सुविधा का इस्तेमाल करना

ज़्यादा अनुमति मांगने की सुविधा का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए ज़रूरी OAuth स्कोप का अनुरोध करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस्तेमाल न किए गए OAuth क्लाइंट को हटाना

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

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

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