इस गाइड में बताया गया है कि अपने ऐप्लिकेशन और उपयोगकर्ता के क्रेडेंशियल को सुरक्षित कैसे रखा जाए.
OAuth ऐप्लिकेशन की पुष्टि की प्रक्रिया पूरी करना
Google Ads API के लिए OAuth 2.0 के दायरे को प्रतिबंधित दायरे के तौर पर बांटा गया है. इसका मतलब है कि आपको अपने ऐप्लिकेशन को प्रोडक्शन में लाने से पहले, OAuth ऐप्लिकेशन की पुष्टि की प्रक्रिया पूरी करनी होगी. ज़्यादा जानने के लिए, Google Identity से जुड़ा दस्तावेज़, पुष्टि नहीं किए गए ऐप्लिकेशन के बारे में सहायता केंद्र का लेख, और OAuth के लिए सहमति वाली स्क्रीन सेट अप करने से जुड़े दस्तावेज़ देखें.
ऐप्लिकेशन के क्रेडेंशियल सुरक्षित करना
आपको अपने ऐप्लिकेशन के OAuth 2.0 क्लाइंट आईडी और क्लाइंट सीक्रेट को सुरक्षित रखना चाहिए. इन क्रेडेंशियल की मदद से, आपके उपयोगकर्ता और Google आपके ऐप्लिकेशन की पहचान कर पाते हैं. इसलिए, इन्हें सावधानी से मैनेज किया जाना चाहिए. आपको इन ऐप्लिकेशन क्रेडेंशियल को पासवर्ड की तरह ही सुरक्षित रखना चाहिए. इन्हें असुरक्षित तरीकों से शेयर न करें. जैसे, सार्वजनिक फ़ोरम पर पोस्ट करना, ईमेल अटैचमेंट में इन क्रेडेंशियल वाली कॉन्फ़िगरेशन फ़ाइलें भेजना, क्रेडेंशियल को हार्ड कोड करना या उन्हें कोड रिपॉज़िटरी में कमिट करना. हमारा सुझाव है कि जब भी संभव हो, Google Cloud Secret Manager या AWS Secrets Manager जैसे सीक्रेट मैनेजर का इस्तेमाल करें.
अगर आपके OAuth 2.0 क्लाइंट सीक्रेट के साथ छेड़छाड़ की गई है, तो आपके पास उन्हें रीसेट करने का विकल्प है.
सेवा खातों को सुरक्षित करना
अगर सेवा खातों का इस्तेमाल किया जाता है, तो उन्हें इस तरह सुरक्षित करें:
अपने सेवा खाते की कुंजी और JSON फ़ाइल को पासवर्ड की तरह सुरक्षित रखें. जब भी संभव हो, Google Cloud Secret Manager या AWS Secrets Manager जैसे सीक्रेट मैनेजर का इस्तेमाल करके, उन्हें सुरक्षित करें.
अपने सेवा खातों को सुरक्षित रखने और उन्हें मैनेज करने के लिए, Google Cloud के अन्य सबसे सही तरीकों का पालन करें.
उपयोगकर्ता टोकन सुरक्षित करना
अगर आपका ऐप्लिकेशन एक से ज़्यादा उपयोगकर्ताओं को अनुमति देता है, तो आपको उपयोगकर्ताओं के रीफ़्रेश और ऐक्सेस टोकन को सुरक्षित रखने के लिए, अतिरिक्त कदम उठाने चाहिए. टोकन को स्टोरेज में सुरक्षित तरीके से सेव करें और उन्हें कभी भी सामान्य टेक्स्ट में न भेजें. अपने प्लैटफ़ॉर्म के हिसाब से, सुरक्षित स्टोरेज सिस्टम का इस्तेमाल करें.
रिफ़्रेश टोकन को रद्द करना और उसकी समयसीमा खत्म होने की प्रोसेस को मैनेज करना
अगर आपका ऐप्लिकेशन अनुमति देने के लिए, OAuth 2.0 रीफ़्रेश टोकन का अनुरोध करता है, तो आपको इसके अमान्य होने या इसकी समयसीमा खत्म होने की प्रोसेस को भी मैनेज करना होगा. रिफ़्रेश टोकन को कई वजहों से अमान्य किया जा सकता है. ऐसे में, आपके ऐप्लिकेशन को उपयोगकर्ता के अगले लॉगिन सेशन के दौरान, उसे फिर से अनुमति देनी चाहिए या उसके डेटा को सही तरीके से मिटाना चाहिए. क्रॉन जॉब जैसे ऑफ़लाइन जॉब को उन खातों का पता लगाना चाहिए और उन्हें रिकॉर्ड करना चाहिए जिनके रीफ़्रेश टोकन की समयसीमा खत्म हो चुकी है. ऐसा करने से, बार-बार असफल अनुरोध करने से बचा जा सकता है. Google, एपीआई सर्वर की स्थिरता बनाए रखने के लिए, उन ऐप्लिकेशन को थ्रॉटल कर सकता है जो लंबे समय तक ज़्यादा गड़बड़ियां जनरेट करते हैं.
एक से ज़्यादा स्कोप के लिए सहमति मैनेज करना
अगर आपका ऐप्लिकेशन, OAuth 2.0 के कई दायरों के लिए अनुमति का अनुरोध करता है, तो हो सकता है कि उपयोगकर्ता आपके अनुरोध किए गए सभी OAuth दायरों को अनुमति न दे. आपके ऐप्लिकेशन को स्कोप की अनुमति न मिलने पर, उससे जुड़ी सुविधाओं को बंद कर देना चाहिए. उपयोगकर्ता को फिर से प्रॉम्प्ट सिर्फ़ तब दिखाया जा सकता है, जब उसने साफ़ तौर पर यह बताया हो कि उसे उस खास सुविधा का इस्तेमाल करना है जिसके लिए स्कोप की ज़रूरत है. ऐसे मामलों में, OAuth के सही दायरों का अनुरोध करने के लिए, इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करें.
अगर आपके ऐप्लिकेशन की बुनियादी सुविधाओं के लिए कई स्कोप की ज़रूरत है, तो सहमति मांगने से पहले उपयोगकर्ता को इस ज़रूरी शर्त के बारे में बताएं.