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

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

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

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

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

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

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

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

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

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

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

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

जब आपके ऐप्लिकेशन को किसी फ़ंक्शन की ज़रूरत हो, तब सही 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 क्लाइंट को छह महीने तक इस्तेमाल न करने पर, अपने-आप मिटा दिया जाता है.

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