Skip to main content
Public API का उपयोग करने के लिए OAuth की आवश्यकता नहीं है। निजी, server-side integration के लिए scoped API key से शुरुआत करें और quickstart का अनुसरण करें। OAuth client credentials तब चुनें जब आपकी सुरक्षा नीति के लिए अल्पकालिक access tokens आवश्यक हों या आपका integration platform पहले से उस flow को सपोर्ट करता हो। दोनों विकल्प एक service account का उपयोग करते हैं। Service account integration की पहचान है, कोई तीसरी authentication पद्धति नहीं।

​
ये घटक एक साथ कैसे काम करते हैं

प्रत्येक integration के लिए एक service account बनाएँ। उस खाते के लिए API key या OAuth client चुनें; प्रत्येक API request पर आपको दोनों पद्धतियों की आवश्यकता नहीं होती। कोई भी credential खाते की वर्तमान permissions से अधिक नहीं हो सकता। Quickstart में Basic authentication का उपयोग किया गया है। API keys के लिए Bearer header भी सपोर्टेड है; उस header का उपयोग करने का अर्थ यह नहीं है कि आपको OAuth client की आवश्यकता है।

​
सीधे-सादे integration के लिए API key चुनें

अपने निर्धारित jobs, रिपोर्टिंग scripts, data pipelines या अन्य backend services के लिए API key का उपयोग करें, जब आपके secret manager में संग्रहीत secret आपकी सुरक्षा आवश्यकताओं के अनुरूप हो।
  • प्रमाणित requests सीधे करें; किसी token exchange की आवश्यकता नहीं है।
  • केवल वही permissions चुनें जिनकी workload को आवश्यकता है और समाप्ति तिथि निर्धारित करें।
  • key को उसकी overlap window के अनुसार rotate करें, या उजागर होने पर उसे तुरंत revoke करें।
API-key integration के लिए OAuth client की आवश्यकता नहीं होती। quickstart से शुरुआत करें, फिर निर्माण और rotation के लिए API keys देखें।

​
अल्पकालिक access tokens के लिए OAuth चुनें

किसी confidential backend service के लिए OAuth client credentials का उपयोग करें, जब आपके संगठन को समाप्त होने वाले access tokens की आवश्यकता हो या कोई integration tool client_credentials grant की अपेक्षा करता हो।
  1. service account के लिए एक scoped OAuth client बनाएँ।
  2. सेटअप के दौरान प्रदान की गई client authentication पद्धति का उपयोग करके client को अपने क्षेत्रीय token endpoint पर authenticate करें।
  3. प्राप्त access token को अपनी API requests के साथ भेजें। वर्तमान token की समाप्ति से पहले नया token प्राप्त करें।
OAuth आपके integration में token प्राप्त करने और समाप्ति को संभालने की प्रक्रिया जोड़ता है। Client secret के लिए फिर भी सुरक्षित संग्रहण और rotation आवश्यक है; अल्पकालिक tokens इस ज़िम्मेदारी को समाप्त नहीं करते। Client credentials refresh tokens का उपयोग नहीं करता: नया access token प्राप्त करने के लिए client को दोबारा authenticate करें। आपके संगठन के लिए OAuth access सक्षम होना आवश्यक है। यदि यह सक्षम नहीं है, तो API key का उपयोग करें या अपनी आवश्यकताओं के संबंध में Living Security Support से संपर्क करें। client निर्माण, एक बार दिखाए जाने वाले secrets, revocation और recovery के लिए OAuth client credentials देखें।

​
Credentials को अपने backend पर रखें

Service-account API keys और OAuth client secrets को server-side secret storage में रखा जाना चाहिए। उन्हें browser code, mobile apps, source control या logs में न रखें। Service-account credential workload के रूप में कार्य करता है; यह किसी व्यक्ति को sign in नहीं कराता और न ही ग्राहक-सहमति flow प्रदान करता है। दोनों में से किसी भी पद्धति के साथ अपने संगठन के लिए regional API host का उपयोग करें। authentication पद्धति बदलने से resource URL, API version या किसी operation के लिए आवश्यक permissions नहीं बदलते।