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