Skip to main content
जब आपके बैकएंड इंटीग्रेशन को अल्पकालिक एक्सेस टोकन की आवश्यकता हो या आपकी सुरक्षा नीति इन्हें अनिवार्य करती हो, तब OAuth क्लाइंट क्रेडेंशियल्स का उपयोग करें। प्रत्येक क्लाइंट एक सर्विस अकाउंट और एक ऑर्गनाइज़ेशन से संबद्ध होता है। OAuth वैकल्पिक है: ऐसे निजी सर्वर इंटीग्रेशन के लिए, जो किसी कुंजी को सुरक्षित रूप से संग्रहीत और रोटेट कर सकता है, स्कोप-सीमित API कुंजी पर्याप्त है। दोनों विधियों में से चयन करने और सर्विस अकाउंट की भूमिका समझने के लिए Authentication देखें।
आपके ऑर्गनाइज़ेशन के लिए OAuth एक्सेस सक्षम होना आवश्यक है। आपके सेटअप के दौरान क्षेत्रीय टोकन एंडपॉइंट, इश्यूअर, ऑडियंस और क्लाइंट ऑथेंटिकेशन विधि उपलब्ध कराई जाती है। यदि आपको ये सेटिंग्स चाहिए या आप क्लाइंट प्रबंधन तक नहीं पहुँच पा रहे हैं, तो Living Security Support से संपर्क करें।
क्लाइंट क्रेडेंशियल्स ग्रांट आपके सर्विस अकाउंट का प्रतिनिधित्व करता है। यह किसी व्यक्ति को साइन इन नहीं करता और न ही किसी ग्राहक से किसी एप्लिकेशन को अधिकृत करने के लिए कहता है। ब्राउज़र के माध्यम से डेलीगेटेड ऑथराइज़ेशन एक अलग OAuth क्षमता है और इन ऑपरेशन्स द्वारा प्रदान नहीं की जाती।

शुरू करने से पहले

  • केवल उन्हीं अनुमतियों के साथ एक 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 कॉलर है, तो मैनेजमेंट क्रेडेंशियल का उपयोग जारी रखें।

एक्सेस खोए बिना रोटेशन

आवश्यक स्कोप सीमा के साथ दूसरा क्लाइंट बनाएँ। उसका सीक्रेट सहेजें, अपने क्षेत्रीय टोकन एंडपॉइंट का उपयोग करके टोकन प्राप्त करें, और सत्यापित करें कि इंटीग्रेशन उसके साथ काम करता है। इंटीग्रेशन को प्रतिस्थापन क्लाइंट पर स्विच करें, फिर पुराने रिसोर्स को रिवोक करें। खराब रोलआउट से उबरने के लिए एक स्वतंत्र मैनेजमेंट क्रेडेंशियल सुरक्षित रखें। एक्सेस टोकन क्लाइंट के स्कोप और सर्विस अकाउंट की वर्तमान अनुमतियों से अधिक अधिकार नहीं दे सकते। अकाउंट की अनुमतियाँ हटाना या क्लाइंट को रिवोक करना टोकन की शेष वैधता अवधि पर प्राथमिकता रखता है। कैश्ड टोकन को इस बात का प्रमाण न मानें कि ऑथराइज़ेशन अब भी वैध है। समाप्ति से पहले क्लाइंट को पुनः ऑथेंटिकेट करके नया एक्सेस टोकन प्राप्त करें; यह ग्रांट रिफ़्रेश टोकन का उपयोग नहीं करता।