> ## 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 client credentials

> Cheklangan ruxsatlarga ega xizmat hisobi klientini yarating, bir martalik maxfiy kalitlar bilan ishlang va noaniq so‘rovlardan xavfsiz tiklaning.

Backend integratsiyangizga qisqa muddatli kirish tokenlari kerak bo‘lsa yoki xavfsizlik siyosatingiz ularni talab qilsa, OAuth client credentials usulidan foydalaning. Har bir klient bitta xizmat hisobiga va bitta tashkilotga tegishli bo‘ladi. **OAuth majburiy emas:** kalitni xavfsiz saqlay oladigan va almashtirib turadigan xususiy server integratsiyasi uchun cheklangan ruxsatlarga ega API kaliti yetarli. Ikki usuldan birini tanlash va xizmat hisoblari bu yerda qanday o‘rin tutishini tushunish uchun [Authentication](/uz/developers/v1/authentication) bo‘limiga qarang.

<Note>
  Tashkilotingiz uchun OAuth kirishi yoqilgan bo‘lishi kerak. Sozlash jarayonida mintaqaviy token endpoint, issuer, audience va klientni autentifikatsiya qilish usuli taqdim etiladi. Agar bu sozlamalar sizga kerak bo‘lsa yoki klientlarni boshqarish bo‘limiga kira olmasangiz, Living Security qo‘llab-quvvatlash xizmatiga murojaat qiling.
</Note>

Client credentials grant sizning xizmat hisobingizni ifodalaydi. U shaxsni tizimga kiritmaydi va mijozdan ilovaga ruxsat berishni so‘ramaydi. Brauzer orqali delegatsiyalangan avtorizatsiya alohida OAuth imkoniyati hisoblanadi va ushbu operatsiyalar orqali taqdim etilmaydi.

## Before you start

* Integratsiyaga faqat kerakli ruxsatlarni beradigan [service account](/uz/developers/developer-hub/service-accounts) yarating.
* `service_account:manage` hamda yangi klientga bermoqchi bo‘lgan har bir ruxsatga ega boshqaruv credential'idan foydalaning. Maqsadli hisob ham shu ruxsatlarga ega bo‘lishi kerak. Klient ikkala hisobning vakolatlarini kengaytira olmaydi.
* Tashkilotingizning [region](/uz/developers/v1/regions)ini tanlang. API credential'lari va OAuth kirish tokenlari mos keladigan mintaqaviy API hostiga tegishli bo‘ladi.
* Klient maxfiy kaliti va tokenlarni server tomonidagi maxfiy ma’lumotlar omborida saqlang. Ularni hech qachon brauzer kodiga, mobil ilovalarga, manba kodi boshqaruv tizimiga yoki so‘rovlar jurnaliga kiritmang.

## Create a client

`POST /v1/oauth_clients` uchun `service_account_id`, aniq ko‘rsatilgan `scopes`ning bo‘sh bo‘lmagan ro‘yxati va `Idempotency-Key` talab qilinadi. Wildcard'lar qabul qilinmaydi. Klient 100 tagacha scope'ni qo‘llab-quvvatlaydi, ularning umumiy uzunligi ko‘pi bilan 4 096 belgi bo‘lishi mumkin. Har bir xizmat hisobida ko‘pi bilan 20 ta klient yoki yakunlanmagan yaratish/tozalash operatsiyalari bo‘lishi mumkin. Bekor qilish (revocation) API kirishini darhol rad etadi. Klient yoki provayder tomonidagi noaniq yaratish operatsiyasi masofaviy tozalash tasdiqlanmaguncha limitga hisoblanishda davom etadi. Tashlab ketilgan rezervatsiya yoki provayder ishi boshlanishidan oldin muvaffaqiyatsiz tugagani isbotlangan yaratish operatsiyasi o‘z o‘rnini xavfsiz bo‘shatishi mumkin. Uning retry kaliti baribir dastlabki urinishga tegishli bo‘lib qoladi; almashtiruvchi klient yaratish haqida qaror qabul qilishdan oldin o‘sha receipt'ni tiklang.

Ushbu yaratish urinishi uchun bitta retry kalitini tanlang va uni so‘rovni yuborishdan **oldin** saqlab qo‘ying. 1–255 ta ko‘rinadigan ASCII belgilaridan foydalaning, bo‘shliqlarsiz. Javob yo‘qolgan taqdirda uni bir xil hisob, scope'lar, boshqaruv principal'i, mintaqa va API versiyasi bilan qayta ishlating. Boshqaruv credential'ini o‘sha xizmat hisobi doirasida almashtirish yangi retry identifikatorini yaratmaydi.

Python'ning `requests` paketini o‘rnating. Quyidagi muhit qiymatlarini odatdagi maxfiy ma’lumotlar va konfiguratsiya boshqaruvingiz orqali yuklang:

| Variable | Value |
| - | - |
| `LIVING_SECURITY_API_KEY` | Boshqaruv API kaliti |
| `LIVING_SECURITY_REGION` | `us` yoki `eu` |
| `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | Maqsadli xizmat hisobi ID'si |
| `LIVING_SECURITY_OAUTH_CREATE_KEY` | Avval saqlab qo‘yilgan retry kaliti |

```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()
```

Namuna bitta so‘rov yuboradi va natijani xotirada saqlaydi. Uni ishlab chiqarishda ishga tushirishdan oldin belgilangan joyga maxfiy ma’lumotlar menejeringizning yozish operatsiyasini qo‘shing. Namuna noaniq natijadan keyin jimgina boshqa klient yaratish o‘rniga ataylab qaror qabul qilishni talab qiladi. Tarmoq istisnolari ham quyidagi tiklash bosqichlarini talab qiladi.

Yaratish va receipt javoblari `201` dan foydalanadi va `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` hamda `client_secret` maydonlariga ega `oauth_client` resursini o‘z ichiga oladi. Javoblar `Cache-Control: no-store` bilan belgilanadi.

* **`id`** platforma resursini aniqlaydi. Uni olish va bekor qilish uchun saqlab qo‘ying.
* **`client_id`** token almashinuvi vaqtida klientni aniqlaydi. U platforma resursi ID'si emas. Yaratish kutilayotgan paytda u `null` bo‘lishi mumkin.
* **`client_secret`** faqat yaratishni yakunlagan so‘rovga qaytariladi. Har bir takroriy yaratish so‘rovi, jumladan muvaffaqiyatli javob yo‘qolgandan keyingi qayta urinish ham, `null` qaytaradi. Olish (retrieval) hech qachon maxfiy kalitni qaytarmaydi.

## Recover a lost or interrupted response

Resurs receipt'ini tiklash uchun saqlangan retry kaliti bilan o‘sha yaratish so‘rovini takrorlang. Receipt joriy holatni aks ettiradi, shuning uchun bekor qilingan klient bekor qilinganicha qoladi. Bu operatsiya umumiy 24 soatlik keshlangan javobni qayta taqdim etish shartnomasidan foydalanmaydi va `Idempotent-Replayed` sarlavhasini qaytarmaydi.

| Result | Next action |
| - | - |
| `active`, maxfiy kalit mavjud | Maxfiy kalitni xavfsiz saqlang va onboarding'ni davom ettiring. |
| `active`, maxfiy kalit yo‘q | Maxfiy kalitni tiklab bo‘lmaydi. Ushbu klientni bekor qiling, bekor qilinganini tasdiqlang, so‘ng yangi retry kaliti yordamida almashtiruvchi klient yarating. |
| `pending` | Yaratish tasdiqlanmagan. Bir xil retry kalitini saqlang. Holatni tekshirish uchun resursni oling; noaniqlikni chetlab o‘tish uchun dublikatlar yaratmang. |
| `revoked`, `disabled` yoki `expired` | Ushbu klientdan foydalanmang. Almashtiruvchi klientni yaratishdan oldin kutilgan hisob konfiguratsiyasini tasdiqlang. |
| `409 idempotency_key_reuse` | Mavjud kalit ostida so‘rov o‘zgargan. Alohida yaratish kerakligi haqida qaror qabul qilishdan oldin dastlabki operatsiyani tiklang. |
| `409 invalid_request` | Maqsadli hisobning holati va grant'larini tekshiring. Agar uning klient limiti to‘lgan bo‘lsa, qayta urinishdan oldin tozalashni yakunlang; retry kalitini o‘zgartirish sig‘imni bo‘shatmaydi. |
| `429` | `Retry-After` ga rioya qiling; bir xil kalit va so‘rovni saqlang. |
| `500`, `503` yoki tarmoq timeout'i | Natija noma’lum bo‘lishi mumkin. Kalit va kiritilgan ma’lumotlarni saqlang; boshqa klient yaratishdan oldin receipt'ni tiklang. |
| `401` yoki `403` | Qayta urinishdan oldin credential, ruxsat yoki entitlement kirishini hal qiling. |
| `404` | OAuth yoqilganligini, mintaqaviy hostni va resurs egaligini tasdiqlang. |

So‘rov ID'lari va tiklash tafsilotlari uchun [errors](/uz/developers/v1/errors/overview) bo‘limiga qarang. Qo‘llab-quvvatlash xizmatiga yuboriladigan so‘rov bilan hech qachon klient maxfiy kalitini yoki kirish tokenini yubormang.

## Inspect and revoke

Boshqaruv credential'ingiz va platforma resursi `id` dan foydalaning:

| Operation | Request | Success |
| - | - | - |
| Joriy holatni tekshirish | `GET /v1/oauth_clients/{id}` | `200`, maxfiy kalitsiz klient resursi |
| Kirishni bekor qilish | `DELETE /v1/oauth_clients/{id}` | `200`, maxfiy kalitsiz bekor qilingan klient resursi |

Bekor qilish klientning keyingi API so‘rovlarini, jumladan allaqachon berilgan tokenlar bilan yuborilgan so‘rovlarni ham bloklaydi. U API tomonidan allaqachon qabul qilingan ishni bekor qilmaydi. Masofaviy credential tozalash keyinroq yakunlanishi mumkin. Bekor qilishni takrorlash xavfsiz va retry kalitini talab qilmaydi. Agar bekor qilinayotgan klientning o‘zi API chaqiruvchisi bo‘lsa, boshqaruv credential'idan foydalanishda davom eting.

## Rotate without losing access

Kerakli scope chegarasiga ega ikkinchi klient yarating. Uning maxfiy kalitini saqlang, mintaqaviy token endpoint'ingiz orqali token oling va integratsiya u bilan ishlashini tekshiring. Integratsiyani almashtiruvchi klientga o‘tkazing, so‘ng eski resursni bekor qiling. Noto‘g‘ri joriy etishdan tiklanish uchun mustaqil boshqaruv credential'ini saqlab qo‘ying.

Kirish tokenlari klient scope'lari va xizmat hisobining joriy ruxsatlaridan ko‘proq vakolat bera olmaydi. Hisob ruxsatlarini olib tashlash yoki klientni bekor qilish tokenning qolgan amal qilish muddatidan ustun turadi. Keshlangan tokenni avtorizatsiya hali ham amal qilishining isboti deb hisoblamang. Muddati tugashidan oldin klientni qayta autentifikatsiya qilish orqali yangi kirish tokenini oling; bu grant refresh token'lardan foydalanmaydi.


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