इस पेज पर, OAuth 2.0 के साथ इंटिग्रेट करने के कुछ सामान्य सबसे सही तरीके बताए गए हैं. अपने ऐप्लिकेशन के टाइप और डेवलपमेंट प्लैटफ़ॉर्म के लिए दिए गए खास दिशा-निर्देशों के अलावा, इन सबसे सही तरीकों को भी अपनाएं. साथ ही, अपने ऐप्लिकेशन को प्रोडक्शन के लिए तैयार करने के बारे में सलाह और Google की OAuth 2.0 नीतियां भी देखें.
क्लाइंट क्रेडेंशियल को सुरक्षित तरीके से मैनेज करना
OAuth क्लाइंट क्रेडेंशियल, आपके ऐप्लिकेशन की पहचान बताते हैं. इसलिए, इन्हें सावधानी से मैनेज करना चाहिए. इन क्रेडेंशियल को सिर्फ़ सुरक्षित स्टोरेज में सेव करें. उदाहरण के लिए, Google Cloud Secret Manager जैसे सीक्रेट मैनेजर का इस्तेमाल करें. क्रेडेंशियल को हार्डकोड न करें, उन्हें कोड रिपॉज़िटरी में सबमिट न करें या सार्वजनिक तौर पर पब्लिश न करें.
उपयोगकर्ता टोकन को सुरक्षित तरीके से मैनेज करना
उपयोगकर्ता टोकन में, आपके ऐप्लिकेशन के इस्तेमाल किए जाने वाले रीफ़्रेश टोकन और ऐक्सेस टोकन, दोनों शामिल होते हैं. टोकन को सुरक्षित तरीके से सेव करें और उन्हें कभी भी सामान्य टेक्स्ट में ट्रांसमिट न करें. अपने प्लैटफ़ॉर्म के लिए, सुरक्षित स्टोरेज सिस्टम का इस्तेमाल करें. जैसे, Android पर कीस्टोर, iOS और macOS पर कीचेन सेवाएं या Windows पर क्रेडेंशियल लॉकर.
टोकन की ज़रूरत न होने पर, उन्हें तुरंत निरस्त करें और अपने सिस्टम से हमेशा के लिए मिटा दें.
इसके अलावा, अपने प्लैटफ़ॉर्म के लिए इन सबसे सही तरीकों को भी अपनाएं:
- सर्वर-साइड ऐप्लिकेशन के लिए, कई उपयोगकर्ताओं के टोकन सेव करने के लिए, उन्हें एन्क्रिप्ट (सुरक्षित) करें. साथ ही, पक्का करें कि आपका डेटास्टोर, इंटरनेट पर सार्वजनिक तौर पर ऐक्सेस न किया जा सके.
- डेस्कटॉप ऐप्लिकेशन के लिए, ऑथराइज़ेशन कोड पाने के लिए, कोड एक्सचेंज के लिए प्रूफ़ की (पीकेसीई) प्रोटोकॉल का इस्तेमाल करने का सुझाव दिया जाता है. इन कोड को ऐक्सेस टोकन के लिए एक्सचेंज किया जा सकता है.
डीपीओपी की मदद से, टोकन को भेजने वाले व्यक्ति तक सीमित करना
टोकन की चोरी और रीप्ले हमलों से अपने ऐप्लिकेशन को बचाने के लिए, डीपीओपी (प्रूफ़-ऑफ़-पोज़ेशन दिखाने की सुविधा) का इस्तेमाल करके, अपने टोकन को भेजने वाले व्यक्ति तक सीमित करें. स्टैंडर्ड बियरर टोकन का इस्तेमाल, उन्हें इंटरसेप्ट करने वाला कोई भी व्यक्ति कर सकता है. वहीं, डीपीओपी टोकन को क्लाइंट की ओर से जनरेट और सेव किए गए यूनीक की पेयर से क्रिप्टोग्राफ़िक तरीके से जोड़ा जाता है.
डीपीओपी का इस्तेमाल करते समय, क्लाइंट टोकन का अनुरोध करते या रीफ़्रेश करते समय, टोकन एंडपॉइंट को एक प्रूफ़ (हस्ताक्षर किया गया JSON वेब टोकन) दिखाता है. इस प्रूफ़ से पता चलता है कि क्लाइंट के पास, टोकन से जुड़ी सार्वजनिक कुंजी के लिए निजी कुंजी है. अगर डीपीओपी से जुड़ा रीफ़्रेश टोकन लीक हो जाता है, तो हमलावर उस निजी कुंजी के बिना उसे रीप्ले नहीं कर सकता.
डीपीओपी, PKCE के साथ मिलकर काम करता है, ताकि पूरी सुरक्षा दी जा सके:
- PKCE, शुरुआती रीडायरेक्शन फ़्लो के दौरान ऑथराइज़ेशन कोड की सुरक्षा करता है.
- DPoP, लंबे समय तक इस्तेमाल किए जा सकने वाले रीफ़्रेश टोकन की सुरक्षा करता है. अगर यह लीक हो जाता है, तो रीप्ले हमलों को रोकता है.
अगर आपका ऐप्लिकेशन:
- पब्लिक क्लाइंट के तौर पर काम करता है (जैसे, सिंगल-पेज ऐप्लिकेशन या इंस्टॉल किया गया ऐप्लिकेशन), तो रीफ़्रेश टोकन के लीक होने की संभावना ज़्यादा होती है.
- बहुत संवेदनशील डेटा या ज़्यादा वैल्यू वाले एपीआई को ऐक्सेस करता है, तो टोकन के लीक होने का असर काफ़ी ज़्यादा होता है.
- सख्त कानूनों या सुरक्षा के ऐसे स्टैंडर्ड के मुताबिक काम करता है जिनके लिए, टोकन को भेजने वाले व्यक्ति तक सीमित करना ज़रूरी है.
डीपीओपी प्रूफ़ बनाने और डीपीओपी से जुड़े टोकन का अनुरोध करने के बारे में ज़्यादा जानने के लिए, डीपीओपी का दस्तावेज़ देखें.
स्टेट पैरामीटर का इस्तेमाल करना
OAuth 2.0 के जवाब को मैनेज करने से पहले, पुष्टि करें कि state Google से मिला
, आपके ऑथराइज़ेशन अनुरोध में भेजे गए state से मेल खाता हो. The
state पैरामीटर, आपके
ऐप्लिकेशन से जनरेट की गई यूनीक वैल्यू होनी चाहिए, जिसका अनुमान न लगाया जा सके.
state पैरामीटर का इस्तेमाल करने से, यह पक्का करने में मदद मिलती है कि अनुरोध, किसी नुकसान पहुंचाने वाले स्क्रिप्ट ने नहीं, बल्कि उपयोगकर्ता ने किया है. साथ ही, इससे किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोधों
(सीएसआरएफ़) वाले हमलों का खतरा कम होता है.
रीफ़्रेश टोकन के निरस्त होने और उसकी समयसीमा खत्म होने की प्रोसेस को मैनेज करना
अगर आपके ऐप्लिकेशन ने ऑफ़लाइन ऐक्सेस के लिए रीफ़्रेश टोकन का अनुरोध किया है, तो आपको उसके अमान्य होने या उसकी समयसीमा खत्म होने की प्रोसेस को भी मैनेज करना होगा. टोकन अमान्य होने की अलग-अलग वजहें हो सकती हैं. जैसे, उसकी समयसीमा खत्म हो गई हो या उपयोगकर्ता या किसी ऑटोमेटेड प्रोसेस ने आपके ऐप्लिकेशन के ऐक्सेस को निरस्त कर दिया हो. ऐसे में, इस बारे में सावधानी से सोचें कि आपके ऐप्लिकेशन को कैसे जवाब देना चाहिए, इसमें, उपयोगकर्ता के अगले साइन-इन पर उसे सूचना देना या उसका डेटा साफ़ करना शामिल है. टोकन के निरस्त होने की सूचना पाने के लिए, सभी खातों की सुरक्षा सेवा के साथ इंटिग्रेट करें.
ज़रूरत के मुताबिक अनुमति मांगने की सुविधा का इस्तेमाल करना
जब उपयोगकर्ता पहली बार पुष्टि करता है, तब आपको डेटा ऐक्सेस करने का अनुरोध नहीं करना चाहिए. ऐसा तब तक न करें, जब तक कि यह आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए ज़रूरी न हो. इसके बजाय, सिर्फ़ उन स्कोप का अनुरोध करें जिनकी किसी टास्क के लिए ज़रूरत है. इसके लिए, सबसे छोटे और सीमित स्कोप चुनने के सिद्धांत का पालन करें.
हमेशा ज़रूरत के मुताबिक स्कोप का अनुरोध करें, ताकि आपके उपयोगकर्ताओं को यह समझने में मदद मिले कि आपका ऐप्लिकेशन ऐक्सेस का अनुरोध क्यों कर रहा है और डेटा का इस्तेमाल कैसे किया जाएगा.
उदाहरण के लिए, आपका ऐप्लिकेशन इस मॉडल को फ़ॉलो कर सकता है:
- उपयोगकर्ता, आपके ऐप्लिकेशन से पुष्टि करता है
- कोई अतिरिक्त स्कोप का अनुरोध नहीं किया जाता. ऐप्लिकेशन, बुनियादी फ़ंक्शन उपलब्ध कराता है, ताकि उपयोगकर्ता उन सुविधाओं को एक्सप्लोर और इस्तेमाल कर सके जिनके लिए किसी अतिरिक्त डेटा या ऐक्सेस की ज़रूरत नहीं होती.
- उपयोगकर्ता ऐसी सुविधा चुनता है जिसके लिए अतिरिक्त डेटा ऐक्सेस करने की ज़रूरत होती है
- आपका ऐप्लिकेशन, इस सुविधा के लिए ज़रूरी खास OAuth स्कोप के लिए ऑथराइज़ेशन अनुरोध करता है. अगर इस सुविधा के लिए एक से ज़्यादा स्कोप की ज़रूरत है, तो एक से ज़्यादा स्कोप के लिए सबसे सही तरीके अपनाएं.
- अगर उपयोगकर्ता अनुरोध को अस्वीकार करता है, तो ऐप्लिकेशन उस सुविधा को बंद कर देता है और उपयोगकर्ता को अतिरिक्त जानकारी देता है ताकि वह फिर से ऐक्सेस का अनुरोध कर सके.
एक से ज़्यादा स्कोप के लिए सहमति को मैनेज करना
एक साथ कई स्कोप का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके अनुरोध किए गए सभी OAuth स्कोप की अनुमति न दे. आपके ऐप्लिकेशन को, काम की सुविधाओं को बंद करके स्कोप के अस्वीकार होने की प्रोसेस को मैनेज करना चाहिए.
अगर आपके ऐप्लिकेशन के बुनियादी फ़ंक्शन के लिए एक से ज़्यादा स्कोप की ज़रूरत है, तो सहमति के लिए अनुरोध करने से पहले, उपयोगकर्ता को इस बारे में बताएं.
उपयोगकर्ता से फिर से सहमति के लिए अनुरोध सिर्फ़ तब करें, जब उसने साफ़ तौर पर यह बताया हो कि वह उस खास सुविधा का इस्तेमाल करना चाहता है जिसके लिए स्कोप की ज़रूरत है. आपके ऐप्लिकेशन को OAuth स्कोप का अनुरोध करने से पहले, उपयोगकर्ता को काम की जानकारी और वजह बतानी चाहिए.
आपको एक साथ अपने ऐप्लिकेशन के अनुरोध किए गए स्कोप की संख्या को कम से कम रखना चाहिए. इसके बजाय, ज़रूरत के मुताबिक अनुमति मांगने की सुविधा का इस्तेमाल करके, सुविधाओं और फ़ंक्शन के हिसाब से स्कोप का अनुरोध करें.
सुरक्षित ब्राउज़र का इस्तेमाल करना
वेब पर, OAuth 2.0 के ऑथराइज़ेशन अनुरोध सिर्फ़ पूरी सुविधाओं वाले वेब ब्राउज़र से किए जाने चाहिए. अन्य प्लैटफ़ॉर्म पर, पक्का करें कि आपने सही OAuth क्लाइंट टाइप चुना हो और अपने प्लैटफ़ॉर्म के हिसाब से OAuth को इंटिग्रेट किया हो. अनुरोध को एंबेड किए गए ब्राउज़िंग एनवायरमेंट के ज़रिए रीडायरेक्ट न करें. इनमें मोबाइल प्लैटफ़ॉर्म पर वेबव्यू शामिल हैं. जैसे, Android पर WebView या iOS पर WKWebView. इसके बजाय, अपने प्लैटफ़ॉर्म के लिए, सुझाए गए OAuth लाइब्रेरी या Google साइन-इन का इस्तेमाल करें.
OAuth क्लाइंट को मैन्युअल तरीके से बनाना और कॉन्फ़िगर करना
गलत इस्तेमाल को रोकने के लिए, OAuth क्लाइंट को प्रोग्राम के ज़रिए न तो बनाया जा सकता है और न ही उनमें बदलाव किया जा सकता है. आपको सेवा की शर्तों को साफ़ तौर पर स्वीकार करने, अपने OAuth क्लाइंट को कॉन्फ़िगर करने, और OAuth की पुष्टि के लिए तैयार होने के लिए, Google Cloud Console का इस्तेमाल करना होगा.
ऑटोमेटेड वर्कफ़्लो के लिए, इसके बजाय सेवा खातों का इस्तेमाल करें.
इस्तेमाल न किए गए OAuth क्लाइंट को हटाना
अपने OAuth 2.0 क्लाइंट की समय-समय पर ऑडिट करें और ऐसे क्लाइंट को पहले से ही मिटा दें जिनकी आपके ऐप्लिकेशन को अब ज़रूरत नहीं है या जो पुराने हो गए हैं. इस्तेमाल न किए गए क्लाइंट को कॉन्फ़िगर करके छोड़ना, सुरक्षा के लिए खतरा पैदा कर सकता है. ऐसा इसलिए, क्योंकि अगर आपके क्लाइंट क्रेडेंशियल से कभी छेड़छाड़ की जाती है, तो क्लाइंट का गलत इस्तेमाल किया जा सकता है.
हमारा सुझाव है कि आप अपने-आप मिटने का इंतज़ार न करें, बल्कि इस्तेमाल न किए गए क्लाइंट को पहले से ही हटा दें. इससे आपके ऐप्लिकेशन के हमले की संभावना कम हो जाती है और सुरक्षा के बेहतर तरीके अपनाए जा सकते हैं.