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

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

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

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

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

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

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

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

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

DPoP की मदद से, टोकन को भेजने वाले के लिए सीमित करना

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

डीपीओपी का इस्तेमाल करते समय, क्लाइंट टोकन का अनुरोध करते समय या उसे रीफ़्रेश टोकन करते समय, टोकन एंडपॉइंट को एक सबूत (साइन किया गया JSON वेब टोकन) दिखाता है. इस सबूत से पता चलता है कि क्लाइंट के पास वह निजी पासकोड है जो टोकन से जुड़े सार्वजनिक पासकोड से मेल खाता है. अगर डीपीओपी से जुड़ा रीफ़्रेश टोकन लीक हो जाता है, तो हमलावर उस निजी पासकोड के बिना टोकन का इस्तेमाल नहीं कर सकता.

ध्यान दें: Google का OAuth 2.0, रीफ़्रेश टोकन के लिए डीपीओपी बाइंडिंग के साथ काम करता है. Google API को ऐक्सेस करते समय, जारी किए गए ऐक्सेस टोकन स्टैंडर्ड बियरर टोकन ही रहते हैं.

DPoP, PKCE के साथ मिलकर काम करता है, ताकि पूरी सुरक्षा मिल सके:

• PKCE, शुरुआती रीडायरेक्शन फ़्लो के दौरान ऑथराइज़ेशन कोड को सुरक्षित रखता है.
• DPoP, लंबे समय तक इस्तेमाल किए जाने वाले रीफ़्रेश टोकन को सुरक्षित रखता है. इससे, टोकन के साथ छेड़छाड़ होने पर, रीप्ले अटैक को रोका जा सकता है.

अगर आपका ऐप्लिकेशन इनमें से कोई काम करता है, तो हमारा सुझाव है कि आप डीपीओपी का इस्तेमाल करें:

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

डीपीओपी के सबूत बनाने और डीपीओपी से जुड़े टोकन का अनुरोध करने के बारे में ज़्यादा जानने के लिए, डीपीओपी को अपनाने से जुड़ी गाइड देखें.

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

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 Cloud Console का इस्तेमाल करके, सेवा की शर्तों को साफ़ तौर पर स्वीकार करना होगा. साथ ही, अपने OAuth क्लाइंट को कॉन्फ़िगर करना होगा और OAuth की पुष्टि के लिए तैयारी करनी होगी.

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

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

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

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

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