PKCE — Proof Key for Code Exchange iborasining qisqartmasi bo‘lib, OAuth 2.0 authorization code oqimida code’ni tutib olgan begona tomon undan token olishining oldini oluvchi mexanizm. U dastlab client secretni xavfsiz saqlay olmaydigan mobil va desktop public clientlar uchun yaratilgan, keyinchalik authorization code ishlatadigan boshqa clientlar uchun ham keng qo‘llanadigan himoyaga aylangan. PKCE foydalanuvchini autentifikatsiya qilmaydi; u authorization so‘rovi bilan token almashuvini bir client nusxasiga bog‘laydi.
Code verifier va challenge
Client har bir authorization urinishida kriptografik tasodifiy code_verifier yaratadi. Bu yuqori entropiyali, ruxsat etilgan belgilardan tuzilgan satr bo‘lib, clientda vaqtincha saqlanadi. So‘ng undan code_challenge hisoblanadi. Tavsiya etiladigan S256 usulida jarayon quyidagicha ifodalanadi:
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
Authorization so‘rovida challenge va code_challenge_method=S256 yuboriladi. Authorization server bu qiymatni authorization code bilan bog‘laydi. Redirect orqali code qaytgach, client token endpointga code bilan birga asl verifierni beradi. Server verifierdan challenge’ni qayta hisoblab, avvalgi qiymatga tengligini tekshiradi. Tenglik bo‘lmasa token chiqarilmaydi.
Hujumga qarshi ishlashi
Mobil operatsion tizimda bir nechta dastur bir xil custom URL scheme’ni ro‘yxatdan o‘tkazishi mumkin. Zararli dastur redirectni qabul qilib, authorization code’ni qo‘lga kiritsa ham, verifierni bilmaydi. Challenge’dan verifierni topish SHA-256 va yetarli entropiya sabab amaliy jihatdan bajarib bo‘lmaydi. Code qisqa muddatli va bir martalik bo‘lishi ham zarur.
PKCE redirect URI tekshiruvining o‘rnini bosmaydi. Authorization server so‘rovdagi URI’ni client uchun oldindan ro‘yxatga olingan aniq qiymat bilan solishtiradi. state parametri ham alohida vazifaga ega: u authorization javobini client boshlagan brauzer holati bilan bog‘lash va CSRF xavfini kamaytirish uchun ishlatiladi. OpenID Connect oqimida nonce ID token replayiga qarshi qo‘llanadi.
S256 va plain
Standart plain usulini ham tariflaydi, unda challenge verifierning o‘ziga teng. Bu qiymat authorization so‘rovi kuzatilsa, himoyani yo‘qqa chiqaradi. Zamonaviy implementatsiyalar S256ni qo‘llab, downgrade imkonini bermaydi. Server client yuborgan methodni qat’iy tekshiradi va PKCE talab qilingan oqimda challenge yo‘q bo‘lsa so‘rovni rad etadi.
Verifier log, analitika, browser URL yoki crash reportga tushmasligi kerak. U faqat clientning authorization tranzaksiyasi holatida saqlanadi va almashuv tugagach o‘chiriladi. Bir verifierni bir nechta urinishda qayta ishlatish tranzaksiyalarni ajratish xususiyatini zaiflashtiradi.
Client secret bilan munosabati
Public clientga dastur paketiga joylangan client secret haqiqiy sir hisoblanmaydi, chunki foydalanuvchi uni chiqarib olishi mumkin. PKCE bunday clientni statik secret orqali ishonchli deb ko‘rsatishga urinmaydi. Confidential backend client esa client secret yoki private key bilan autentifikatsiya qilishi va PKCE’ni qo‘shimcha himoya sifatida ishlatishi mumkin. Secret client tashkilotini, PKCE esa ayni authorization urinishini boshlagan nusxani isbotlashga xizmat qiladi.
Serverdagi tranzaksiya holati
Authorization server challenge’ni code bilan birga qisqa muddatli yozuvda saqlaydi. Code bir marta ishlatiladi va muvaffaqiyatsiz verifier sinovlari ham abuse nazoratiga tushadi. Token endpoint xato javobida verifierning qaysi qismi noto‘g‘ri ekanini ochmaydi. Client bir vaqtning o‘zida bir nechta login oynasini boshlasa, har bir state va verifier juftligini alohida saqlaydi; faqat “oxirgi verifier”ni global qiymat qilish javoblarning aralashishiga olib keladi.
Bog‘liq tushunchalar
OAuth 2.0, Authorization code, Code verifier, Code challenge, SHA-256, Redirect URI, State parameter