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

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

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

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

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

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

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

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

स्टेट पैरामीटर का इस्तेमाल करना

OAuth 2.0 रिस्पॉन्स को मैनेज करने से पहले, पुष्टि करें कि Google से मिला state, अनुमति के अनुरोध में भेजे गए state से मेल खाता हो. state पैरामीटर, आपके ऐप्लिकेशन से जनरेट की गई एक यूनीक वैल्यू होनी चाहिए. साथ ही, यह ऐसी वैल्यू होनी चाहिए जिसका अनुमान न लगाया जा सके.

state पैरामीटर का इस्तेमाल करने से यह पक्का करने में मदद मिलती है कि अनुरोध उपयोगकर्ता कर रहा है, न कि कोई नुकसान पहुंचाने वाली स्क्रिप्ट. इससे क्रॉस-साइट रिक्वेस्ट फ़ोर्जरी (सीएसआरएफ़) अटैक का जोखिम कम होता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जिन OAuth क्लाइंट का इस्तेमाल नहीं किया गया है उन्हें हटाएं

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

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

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