> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> अपने integration के लिए API key या OAuth client credentials चुनें, और समझें कि प्रत्येक विकल्प service account का उपयोग कैसे करता है।

**Public API का उपयोग करने के लिए OAuth की आवश्यकता नहीं है।** निजी, server-side
integration के लिए scoped API key से शुरुआत करें और
[quickstart](/hi/developers/v1/quickstart) का अनुसरण करें। OAuth client credentials तब चुनें जब
आपकी सुरक्षा नीति के लिए अल्पकालिक access tokens आवश्यक हों या आपका integration
platform पहले से उस flow को सपोर्ट करता हो।

दोनों विकल्प एक service account का उपयोग करते हैं। Service account integration की
पहचान है, कोई तीसरी authentication पद्धति नहीं।

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

| आइटम | उद्देश्य | आपका integration क्या भेजता है |
| - | - | - |
| **Service account** | workload को नाम देता है और उसकी permission की ऊपरी सीमा निर्धारित करता है। | इसकी ID खाते की पहचान करती है; यह किसी request को authenticate नहीं करती। |
| **API key** | चुने गए permission सेट और समाप्ति तिथि के साथ सीधे उसी service account के रूप में authenticate करती है। | HTTP Basic authentication या `Authorization: Bearer <api_key_secret>` का उपयोग करके key secret। |
| **OAuth client** | उस service account के लिए scoped access tokens प्राप्त करने हेतु token service के सामने authenticate करता है। | `Authorization: Bearer <access_token>` का उपयोग करके एक access token। |

प्रत्येक integration के लिए एक [service account](/hi/developers/developer-hub/service-accounts) बनाएँ।
उस खाते के लिए 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](/hi/developers/v1/quickstart) से शुरुआत करें, फिर
निर्माण और rotation के लिए [API keys](/hi/developers/developer-hub/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](/hi/developers/v1/oauth) देखें।

## 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](/hi/developers/v1/regions) का उपयोग करें।
authentication पद्धति बदलने से resource URL, API version या किसी operation के लिए आवश्यक
permissions नहीं बदलते।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.