Bearer token — uni taqdim etgan tomonning shaxsini qo‘shimcha kriptografik dalilsiz vakolatli deb qabul qiladigan token turi. “Bearer” so‘zi “ko‘tarib yuruvchi” ma’nosida: haqiqiy qiymat kimning qo‘lida bo‘lsa, odatda shu tomon token vakolatidan foydalana oladi. OAuth 2.0 APIlarida access tokenlar ko‘pincha bearer shaklida uzatiladi. Bu atama tokenning JWT yoki opaque formatda ekanini emas, undan foydalanish usulini bildiradi.
HTTP orqali uzatish
RFC 6750 bo‘yicha asosiy usul Authorization sarlavhasidir:
GET /api/profile HTTP/1.1
Host: example.uz
Authorization: Bearer mF_9.B5f-4.1JqM
Resource server sarlavhadagi sxemani va tokenni ajratadi, keyin lokal imzo tekshiruvi yoki authorization server introspectioni orqali yaroqliligini aniqlaydi. Token form body orqali ham berilishi mumkin, lekin bu faqat tegishli content type va cheklangan sharoitlarda qo‘llanadi. URL query parametridagi token brauzer tarixi, proxy jurnali, analitika va Referer orqali sizishi mumkinligi sababli odatiy usul hisoblanmaydi.
Token bilan yuborilgan har bir so‘rov TLS orqali himoyalanadi. TLS faqat uzatish kanalini himoya qiladi; token endpointda, client xotirasida yoki jurnal tizimida oshkor bo‘lsa, hujumchi uni boshqa qurilmadan ishlatishi mumkin. Shu bois token qiymati diagnostika xabarlaridan maskalanadi, crash reportga kiritilmaydi va umumiy clipboardda saqlanmaydi.
Server javoblari
Token yo‘q, noto‘g‘ri yoki muddati tugagan bo‘lsa, server odatda 401 Unauthorized javobi va WWW-Authenticate: Bearer sarlavhasini qaytaradi. Haqiqiy token mavjud, lekin so‘ralgan resurs uchun scope yetarli bo‘lmasa 403 Forbidden ishlatilishi mumkin. Javobdagi xato tafsiloti clientga tuzatish uchun zarur axborotni beradi, ammo token, ichki kalit yoki tekshiruv arxitekturasini oshkor qilmaydi.
Tokenning haqiqiyligi foydalanuvchi hisobining ayni holatidan alohida bo‘lishi mumkin. Mustaqil tekshiriladigan uzoq JWT hisob bloklangandan keyin ham muddati tugaguncha matematik jihatdan yaroqli qoladi. Resource server risk darajasiga qarab qisqa expiry, markaziy sessiya holati, token introspectioni yoki revocation ro‘yxatini qo‘llaydi.
Replay xavfi
Bearer token nusxasini qayta yuborish replay hujumi uchun yetarli bo‘lishi mumkin. Tokenning qisqa amal muddati zarar oynasini kamaytiradi, lekin replayni bevosita to‘xtatmaydi. Audience va scope cheklovi o‘g‘irlangan tokenning boshqa API yoki ortiqcha amal uchun ishlatilishiga yo‘l qo‘ymaydi. Tasodifiy token qiymati yetarli entropiyaga ega bo‘lib, brute-force orqali topilmasligi kerak.
Sender-constrained token bearer modeliga muqobil himoya qo‘shadi. Mutual TLS tokenni client sertifikatiga, DPoP esa so‘rov uchun yaratilgan imzoni clientning ochiq kalitiga bog‘laydi. Tokenni o‘g‘irlagan tomon tegishli private keyga ega bo‘lmasa, uni ishlata olmaydi. Bunday mexanizm kalit hayot sikli va proxylar bilan moslikni ham boshqarishni talab etadi.
Saqlash muhiti
Server-side web ilovada token backend sessiyasida saqlanib, brauzerga faqat himoyalangan sessiya cookie’si berilishi mumkin. Single-page applicationda token JavaScript muhitiga tushsa, XSS asosiy tahdidga aylanadi. localStorage qiymati sahifadagi zararli script uchun o‘qilishi mumkin; HttpOnly cookie o‘qilmaydi, ammo CSRF va cookie siyosatini boshqarish talab etiladi. Tanlov ilova arxitekturasi va tahdid modeliga bog‘liq.
Proxy va API gateway Authorization sarlavhasini backendga uzatish siyosatini aniq belgilaydi. Token kerak bo‘lmagan xizmatga credentialni forwarding qilish uning exposure doirasini kengaytiradi. Gateway log redaction qoidasini header nomiga qo‘llaydi, backend esa gateway tekshirgan degan taxmin bilan o‘z audience va scope nazoratini tashlab qo‘ymaydi.
Bog‘liq tushunchalar
Access token, OAuth 2.0, Authorization header, JWT, Token replay, DPoP, Mutual TLS