> ## 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.

# OAuth क्लाइंट क्रेडेंशियल्स

> स्कोप-सीमित सर्विस-अकाउंट क्लाइंट प्रोविज़न करें, एक बार दिखाए जाने वाले सीक्रेट को संभालें, और अनिश्चित अनुरोधों की स्थिति से सुरक्षित रूप से पुनर्प्राप्ति करें।

जब आपके बैकएंड इंटीग्रेशन को अल्पकालिक एक्सेस टोकन की आवश्यकता हो या आपकी सुरक्षा नीति इन्हें अनिवार्य करती हो, तब OAuth क्लाइंट क्रेडेंशियल्स का उपयोग करें। प्रत्येक क्लाइंट एक सर्विस अकाउंट और एक ऑर्गनाइज़ेशन से संबद्ध होता है। **OAuth वैकल्पिक है:** ऐसे निजी सर्वर इंटीग्रेशन के लिए, जो किसी कुंजी को सुरक्षित रूप से संग्रहीत और रोटेट कर सकता है, स्कोप-सीमित API कुंजी पर्याप्त है। दोनों विधियों में से चयन करने और सर्विस अकाउंट की भूमिका समझने के लिए [Authentication](/hi/developers/v1/authentication) देखें।

<Note>
  आपके ऑर्गनाइज़ेशन के लिए OAuth एक्सेस सक्षम होना आवश्यक है। आपके सेटअप के दौरान क्षेत्रीय टोकन एंडपॉइंट, इश्यूअर, ऑडियंस और क्लाइंट ऑथेंटिकेशन विधि उपलब्ध कराई जाती है। यदि आपको ये सेटिंग्स चाहिए या आप क्लाइंट प्रबंधन तक नहीं पहुँच पा रहे हैं, तो Living Security Support से संपर्क करें।
</Note>

क्लाइंट क्रेडेंशियल्स ग्रांट आपके सर्विस अकाउंट का प्रतिनिधित्व करता है। यह किसी व्यक्ति को साइन इन नहीं करता और न ही किसी ग्राहक से किसी एप्लिकेशन को अधिकृत करने के लिए कहता है। ब्राउज़र के माध्यम से डेलीगेटेड ऑथराइज़ेशन एक अलग OAuth क्षमता है और इन ऑपरेशन्स द्वारा प्रदान नहीं की जाती।

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

* केवल उन्हीं अनुमतियों के साथ एक [service account](/hi/developers/developer-hub/service-accounts) बनाएँ जिनकी इंटीग्रेशन को आवश्यकता है।
* ऐसे मैनेजमेंट क्रेडेंशियल का उपयोग करें जिसमें `service_account:manage` और वे सभी अनुमतियाँ हों जिन्हें आप नए क्लाइंट को देना चाहते हैं। लक्षित अकाउंट के पास भी वही अनुमतियाँ होनी चाहिए। कोई क्लाइंट किसी भी अकाउंट के अधिकार का विस्तार नहीं कर सकता।
* अपने ऑर्गनाइज़ेशन का [region](/hi/developers/v1/regions) चुनें। API क्रेडेंशियल्स और OAuth एक्सेस टोकन संबंधित क्षेत्रीय API होस्ट से ही संबद्ध होते हैं।
* क्लाइंट सीक्रेट और टोकन को अपने सर्वर-साइड सीक्रेट स्टोरेज में रखें। उन्हें ब्राउज़र कोड, मोबाइल एप्लिकेशन, सोर्स कंट्रोल या अनुरोध लॉग में कभी न रखें।

## क्लाइंट बनाएँ

`POST /v1/oauth_clients` के लिए `service_account_id`, स्पष्ट रूप से निर्दिष्ट `scopes` की एक गैर-रिक्त सूची, और एक `Idempotency-Key` आवश्यक है। वाइल्डकार्ड स्वीकार नहीं किए जाते। एक क्लाइंट अधिकतम 100 स्कोप का समर्थन करता है, जिनकी संयुक्त लंबाई अधिकतम 4,096 वर्ण हो सकती है। प्रत्येक सर्विस अकाउंट में अधिकतम 20 क्लाइंट या अनसुलझे क्रिएशन/क्लीनअप ऑपरेशन हो सकते हैं। रिवोकेशन तुरंत API एक्सेस अस्वीकार कर देता है। कोई क्लाइंट या प्रोवाइडर द्वारा अनिश्चित क्रिएशन तब तक सीमा में गिना जाता रहता है जब तक रिमोट क्लीनअप की पुष्टि नहीं हो जाती। कोई परित्यक्त रिज़र्वेशन, या ऐसा क्रिएट जो प्रोवाइडर का कार्य शुरू होने से पहले विफल सिद्ध हो चुका हो, अपना स्लॉट सुरक्षित रूप से मुक्त कर सकता है। उसकी रीट्राई कुंजी फिर भी मूल प्रयास की ही रहती है; प्रतिस्थापन बनाने का निर्णय लेने से पहले उस रसीद को पुनर्प्राप्त करें।

इस क्रिएशन प्रयास के लिए एक रीट्राई कुंजी चुनें और अनुरोध भेजने से **पहले** उसे सुरक्षित रूप से सहेजें। 1–255 दृश्यमान ASCII वर्णों का उपयोग करें, बिना रिक्त स्थान के। प्रतिक्रिया खो जाने के बाद उसी अकाउंट, स्कोप, मैनेजमेंट प्रिंसिपल, क्षेत्र और API संस्करण के साथ उसी कुंजी का पुनः उपयोग करें। उसी सर्विस अकाउंट के अंतर्गत मैनेजमेंट क्रेडेंशियल को रोटेट करने से नई रीट्राई पहचान नहीं बनती।

Python का `requests` पैकेज इंस्टॉल करें। अपने सामान्य सीक्रेट और कॉन्फ़िगरेशन प्रबंधन के माध्यम से निम्नलिखित एनवायरनमेंट मान लोड करें:

| Variable | Value |
| - | - |
| `LIVING_SECURITY_API_KEY` | मैनेजमेंट API कुंजी |
| `LIVING_SECURITY_REGION` | `us` या `eu` |
| `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | लक्षित सर्विस अकाउंट ID |
| `LIVING_SECURITY_OAUTH_CREATE_KEY` | पहले से सहेजी गई रीट्राई कुंजी |

```python Python theme={null}
import os
import requests

HOSTS = {
    "us": "https://api.us-east-1.livingsecurity.ai/v1",
    "eu": "https://api.eu-west-1.livingsecurity.ai/v1",
}
base = HOSTS[os.environ["LIVING_SECURITY_REGION"]]
response = requests.post(
    f"{base}/oauth_clients",
    auth=("apikey", os.environ["LIVING_SECURITY_API_KEY"]),
    headers={
        "Living-Security-Version": "2026-07-01",
        "Idempotency-Key": os.environ["LIVING_SECURITY_OAUTH_CREATE_KEY"],
    },
    json={
        "service_account_id": os.environ["LIVING_SECURITY_SERVICE_ACCOUNT_ID"],
        "scopes": ["organization:read"],
    },
    timeout=(5, 30),
    allow_redirects=False,
)
try:
    if response.status_code != 201:
        raise RuntimeError(
            f"Client creation needs review: HTTP {response.status_code}; "
            f"request_id={response.headers.get('Request-Id', 'unknown')}"
        )
    client = response.json()
    if client.get("object") != "oauth_client" or not client.get("id"):
        raise RuntimeError("Unexpected client receipt; preserve the retry key")
    if client.get("status") != "active" or not client.get("client_secret"):
        raise RuntimeError(
            f"Client {client['id']} needs recovery; no usable secret was returned"
        )
    # Persist client['id'], client['client_id'], and client['client_secret']
    # directly in your secret manager before using the client. Do not print them.
finally:
    response.close()
```

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

क्रिएशन और रसीद की प्रतिक्रियाएँ `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` हेडर नहीं लौटाता।

| परिणाम | अगली कार्रवाई |
| - | - |
| `active`, सीक्रेट उपस्थित | सीक्रेट को सुरक्षित रूप से सहेजें और ऑनबोर्डिंग जारी रखें। |
| `active`, सीक्रेट अनुपस्थित | सीक्रेट पुनर्प्राप्त नहीं किया जा सकता। इस क्लाइंट को रिवोक करें, रिवोकेशन की पुष्टि करें, फिर नई रीट्राई कुंजी का उपयोग करके प्रतिस्थापन बनाएँ। |
| `pending` | क्रिएशन की पुष्टि नहीं हुई है। वही रीट्राई कुंजी रखें। स्थिति जाँचने के लिए रिसोर्स पुनर्प्राप्त करें; अनिश्चितता को दरकिनार करने के लिए डुप्लिकेट न बनाएँ। |
| `revoked`, `disabled` या `expired` | इस क्लाइंट का उपयोग न करें। प्रतिस्थापन प्रोविज़न करने से पहले अभीष्ट अकाउंट कॉन्फ़िगरेशन की पुष्टि करें। |
| `409 idempotency_key_reuse` | किसी मौजूदा कुंजी के अंतर्गत अनुरोध बदल गया। अलग क्रिएशन आवश्यक है या नहीं, यह तय करने से पहले मूल ऑपरेशन पुनर्प्राप्त करें। |
| `409 invalid_request` | लक्षित अकाउंट की स्थिति और ग्रांट्स जाँचें। यदि उसकी क्लाइंट सीमा पूरी हो गई थी, तो पुनः प्रयास से पहले क्लीनअप पूरा करें; रीट्राई कुंजी बदलने से क्षमता मुक्त नहीं होती। |
| `429` | `Retry-After` का पालन करें; वही कुंजी और अनुरोध बनाए रखें। |
| `500`, `503` या नेटवर्क टाइमआउट | परिणाम अज्ञात हो सकता है। कुंजी और इनपुट सुरक्षित रखें; दूसरा क्लाइंट बनाने से पहले रसीद पुनर्प्राप्त करें। |
| `401` या `403` | पुनः प्रयास से पहले क्रेडेंशियल, अनुमति या एंटाइटलमेंट एक्सेस की समस्या को हल करें। |
| `404` | OAuth सक्षम होने, क्षेत्रीय होस्ट और रिसोर्स स्वामित्व की पुष्टि करें। |

अनुरोध ID और पुनर्प्राप्ति विवरण के लिए [errors](/hi/developers/v1/errors/overview) देखें। सपोर्ट अनुरोध के साथ क्लाइंट सीक्रेट या एक्सेस टोकन कभी न भेजें।

## निरीक्षण और रिवोकेशन

अपने मैनेजमेंट क्रेडेंशियल और प्लेटफ़ॉर्म रिसोर्स `id` का उपयोग करें:

| ऑपरेशन | अनुरोध | सफलता |
| - | - | - |
| वर्तमान स्थिति का निरीक्षण | `GET /v1/oauth_clients/{id}` | `200`, सीक्रेट रहित क्लाइंट रिसोर्स |
| एक्सेस रिवोक करें | `DELETE /v1/oauth_clients/{id}` | `200`, सीक्रेट रहित रिवोक किया गया क्लाइंट रिसोर्स |

रिवोकेशन उस क्लाइंट के बाद के सभी API अनुरोधों को अवरुद्ध कर देता है, जिनमें पहले से जारी किए गए टोकन वाले अनुरोध भी शामिल हैं। यह API द्वारा पहले से स्वीकार किए गए कार्य को रद्द नहीं करता। रिमोट क्रेडेंशियल क्लीनअप बाद में पूरा हो सकता है। रिवोकेशन दोहराना सुरक्षित है और इसके लिए रीट्राई कुंजी की आवश्यकता नहीं होती। यदि रिवोक किया जा रहा क्लाइंट स्वयं एक API कॉलर है, तो मैनेजमेंट क्रेडेंशियल का उपयोग जारी रखें।

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

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

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


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