आपके ऑर्गनाइज़ेशन के लिए OAuth एक्सेस सक्षम होना आवश्यक है। आपके सेटअप के दौरान क्षेत्रीय टोकन एंडपॉइंट, इश्यूअर, ऑडियंस और क्लाइंट ऑथेंटिकेशन विधि उपलब्ध कराई जाती है। यदि आपको ये सेटिंग्स चाहिए या आप क्लाइंट प्रबंधन तक नहीं पहुँच पा रहे हैं, तो Living Security Support से संपर्क करें।
शुरू करने से पहले
- केवल उन्हीं अनुमतियों के साथ एक service account बनाएँ जिनकी इंटीग्रेशन को आवश्यकता है।
- ऐसे मैनेजमेंट क्रेडेंशियल का उपयोग करें जिसमें
service_account:manageऔर वे सभी अनुमतियाँ हों जिन्हें आप नए क्लाइंट को देना चाहते हैं। लक्षित अकाउंट के पास भी वही अनुमतियाँ होनी चाहिए। कोई क्लाइंट किसी भी अकाउंट के अधिकार का विस्तार नहीं कर सकता। - अपने ऑर्गनाइज़ेशन का region चुनें। API क्रेडेंशियल्स और OAuth एक्सेस टोकन संबंधित क्षेत्रीय API होस्ट से ही संबद्ध होते हैं।
- क्लाइंट सीक्रेट और टोकन को अपने सर्वर-साइड सीक्रेट स्टोरेज में रखें। उन्हें ब्राउज़र कोड, मोबाइल एप्लिकेशन, सोर्स कंट्रोल या अनुरोध लॉग में कभी न रखें।
क्लाइंट बनाएँ
POST /v1/oauth_clients के लिए service_account_id, स्पष्ट रूप से निर्दिष्ट scopes की एक गैर-रिक्त सूची, और एक Idempotency-Key आवश्यक है। वाइल्डकार्ड स्वीकार नहीं किए जाते। एक क्लाइंट अधिकतम 100 स्कोप का समर्थन करता है, जिनकी संयुक्त लंबाई अधिकतम 4,096 वर्ण हो सकती है। प्रत्येक सर्विस अकाउंट में अधिकतम 20 क्लाइंट या अनसुलझे क्रिएशन/क्लीनअप ऑपरेशन हो सकते हैं। रिवोकेशन तुरंत API एक्सेस अस्वीकार कर देता है। कोई क्लाइंट या प्रोवाइडर द्वारा अनिश्चित क्रिएशन तब तक सीमा में गिना जाता रहता है जब तक रिमोट क्लीनअप की पुष्टि नहीं हो जाती। कोई परित्यक्त रिज़र्वेशन, या ऐसा क्रिएट जो प्रोवाइडर का कार्य शुरू होने से पहले विफल सिद्ध हो चुका हो, अपना स्लॉट सुरक्षित रूप से मुक्त कर सकता है। उसकी रीट्राई कुंजी फिर भी मूल प्रयास की ही रहती है; प्रतिस्थापन बनाने का निर्णय लेने से पहले उस रसीद को पुनर्प्राप्त करें।
इस क्रिएशन प्रयास के लिए एक रीट्राई कुंजी चुनें और अनुरोध भेजने से पहले उसे सुरक्षित रूप से सहेजें। 1–255 दृश्यमान ASCII वर्णों का उपयोग करें, बिना रिक्त स्थान के। प्रतिक्रिया खो जाने के बाद उसी अकाउंट, स्कोप, मैनेजमेंट प्रिंसिपल, क्षेत्र और API संस्करण के साथ उसी कुंजी का पुनः उपयोग करें। उसी सर्विस अकाउंट के अंतर्गत मैनेजमेंट क्रेडेंशियल को रोटेट करने से नई रीट्राई पहचान नहीं बनती।
Python का requests पैकेज इंस्टॉल करें। अपने सामान्य सीक्रेट और कॉन्फ़िगरेशन प्रबंधन के माध्यम से निम्नलिखित एनवायरनमेंट मान लोड करें:
Python
201 का उपयोग करती हैं और इनमें एक oauth_client रिसोर्स होता है, जिसमें id, service_account_id, client_id, scopes, status, created_at और client_secret शामिल हैं। प्रतिक्रियाओं को Cache-Control: no-store के रूप में चिह्नित किया जाता है।
idप्लेटफ़ॉर्म रिसोर्स की पहचान करता है। इसे पुनर्प्राप्ति और रिवोकेशन के लिए सहेजें।client_idटोकन एक्सचेंज के दौरान क्लाइंट की पहचान करता है। यह प्लेटफ़ॉर्म रिसोर्स ID नहीं है। क्रिएशन लंबित होने पर यहnullहो सकता है।client_secretकेवल उसी अनुरोध को लौटाया जाता है जो क्रिएशन पूरा करता है। प्रत्येक दोहराया गया क्रिएशन अनुरोधnullलौटाता है, जिसमें सफल प्रतिक्रिया खो जाने के बाद किया गया रीट्राई भी शामिल है। पुनर्प्राप्ति (Retrieval) कभी सीक्रेट नहीं लौटाता।
खोई या बाधित प्रतिक्रिया से पुनर्प्राप्ति
रिसोर्स रसीद पुनर्प्राप्त करने के लिए सहेजी गई रीट्राई कुंजी के साथ वही क्रिएशन अनुरोध दोहराएँ। रसीद वर्तमान स्थिति को दर्शाती है, इसलिए रिवोक किया गया क्लाइंट रिवोक ही रहता है। यह ऑपरेशन सामान्य 24-घंटे के कैश्ड-रिस्पॉन्स रीप्ले अनुबंध का उपयोग नहीं करता औरIdempotent-Replayed हेडर नहीं लौटाता।
अनुरोध ID और पुनर्प्राप्ति विवरण के लिए errors देखें। सपोर्ट अनुरोध के साथ क्लाइंट सीक्रेट या एक्सेस टोकन कभी न भेजें।
निरीक्षण और रिवोकेशन
अपने मैनेजमेंट क्रेडेंशियल और प्लेटफ़ॉर्म रिसोर्सid का उपयोग करें:
रिवोकेशन उस क्लाइंट के बाद के सभी API अनुरोधों को अवरुद्ध कर देता है, जिनमें पहले से जारी किए गए टोकन वाले अनुरोध भी शामिल हैं। यह API द्वारा पहले से स्वीकार किए गए कार्य को रद्द नहीं करता। रिमोट क्रेडेंशियल क्लीनअप बाद में पूरा हो सकता है। रिवोकेशन दोहराना सुरक्षित है और इसके लिए रीट्राई कुंजी की आवश्यकता नहीं होती। यदि रिवोक किया जा रहा क्लाइंट स्वयं एक API कॉलर है, तो मैनेजमेंट क्रेडेंशियल का उपयोग जारी रखें।

