Skip to main content
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 bo‘limiga qarang.
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.
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 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 regionini 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 scopesning 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:
Python
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. So‘rov ID’lari va tiklash tafsilotlari uchun errors 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: 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.