Access token — dasturga himoyalangan resurs yoki API bilan cheklangan muddat va vakolat doirasida ishlash huquqini beruvchi credential. U foydalanuvchining paroli o‘rnida xizmatga taqdim etiladi, ammo odatda paroldan farqli ravishda muayyan resurs, amal va vaqt bilan chegaralanadi. OAuth 2.0 tizimida token authorization server tomonidan clientga beriladi; resource server esa kelgan tokenning haqiqiyligi hamda so‘ralgan amal uchun yetarli vakolat borligini tekshiradi.
Token olish jarayoni
Foydalanuvchi ishtirok etadigan oqimda client avval authorization serverga yo‘naltiradi. Foydalanuvchi autentifikatsiyadan o‘tib, ruxsatni tasdiqlagach, client authorization code oladi. Code token endpointga yuborilib, access token bilan almashtiriladi. Public clientlarda PKCE code o‘g‘irlanishidan himoya qo‘shadi. Serverlararo integratsiyada esa client credentials oqimi foydalanuvchisiz, xizmatning o‘z vakolatlari asosida token berishi mumkin.
Token olish va undan foydalanish ikki alohida aloqa hisoblanadi. Client token endpointda o‘zini autentifikatsiya qilishi mumkin, keyin API so‘rovida access tokenni yuboradi. Tokenni URL query parametrida joylash jurnal va brauzer tarixiga sizish xavfini oshiradi. HTTP APIlarda odatiy uzatish shakli quyidagicha:
Authorization: Bearer eyJ...
Format va tekshirish
Access token opaque, ya’ni client mazmunini talqin qilmaydigan tasodifiy satr bo‘lishi mumkin. Resource server bunday tokenni markaziy ombor yoki introspection endpoint orqali tekshiradi. JWT shaklidagi self-contained token esa issuer, audience, expiry va scope kabi claimlarni o‘z ichiga oladi hamda raqamli imzo bilan tasdiqlanadi. JWT shifrlangan degani emas: odatiy imzolangan JWT payloadi base64url bilan kodlangan va o‘qilishi mumkin.
Resource server kamida imzo algoritmi, kalit, iss, aud va exp qiymatlarini tekshiradi. Faqat imzo to‘g‘ri chiqishi token ayni API uchun chiqarilganini bildirmaydi; audience tekshiruvi boshqa xizmat uchun berilgan tokenni qabul qilishning oldini oladi. Server algoritmni tokenning o‘zidan nazoratsiz qabul qilmaydi, balki oldindan ruxsat etilgan algoritmlar ro‘yxatini ishlatadi.
Amal muddati va bekor qilish
Access token odatda qisqa muddatli qilinadi. Bu token o‘g‘irlanganda hujumchining foydalanish oynasini cheklaydi. Muddati tugagach client refresh token orqali yangi token olishi yoki qayta autentifikatsiya bajarishi mumkin. Opaque tokenni markaziy holat orqali darhol bekor qilish oson; mustaqil tekshiriladigan JWT esa muddati tugaguncha amal qilishi mumkin. Favqulodda bekor qilish uchun denylist, kalitni almashtirish yoki sessiya versiyasi kabi qo‘shimcha mexanizmlar ishlatiladi.
Xavfsizlik chegarasi
Bearer access tokenni qo‘lga kiritgan tomon odatda alohida kriptografik dalilsiz undan foydalana oladi. Shu sababli token faqat TLS orqali uzatiladi, jurnalga to‘liq yozilmaydi va brauzer yoki mobil qurilmada himoyalangan joyda saqlanadi. Frontenddagi XSS tokenni o‘g‘irlashi yoki uning nomidan so‘rov yuborishi mumkin. Sender-constrained tokenlar mTLS yoki DPoP kabi usul bilan tokenni ma’lum kalit egasiga bog‘lab, oddiy nusxalashning foydasini kamaytiradi.
Scope eng kichik zarur vakolat bilan beriladi. Token foydalanuvchini ham, clientni ham ifodalashi mumkin; shu sababli auditda token qaysi subyekt, qaysi client va qaysi ruxsat asosida chiqarilgani ajratiladi. Token ichiga parol, maxfiy shaxsiy ma’lumot yoki o‘zgarmas uzoq muddatli sir joylanmaydi.
Token exchange yoki service delegation ishlatilganda yangi tokenning audience va vakolati boshlang‘ich tokendan aniq ajratiladi. API qabul qilgan access tokenni nazoratsiz boshqa ichki xizmatga uzatish “confused deputy” xavfini va credentialning tarqalish doirasini oshiradi.
Bog‘liq tushunchalar
OAuth 2.0, Refresh token, Bearer token, Scope, JWT, Authorization server, Resource server