๐Ÿ”
Xavfsizlik

OAuth 2.0 autentifikatsiya: authorization code flow, PKCE va refresh token

20.08.2034
โ† Barcha maqolalar

OAuth 2.0 nima va nima uchun kerak

OAuth 2.0 autentifikatsiya emas, balki avtorizatsiya protokoli. U foydalanuvchidan parol so'ramasdan boshqa xizmatga uning nomidan amal qilish huquqini beradi. Misol uchun, foydalanuvchi Sayt.uz ga Google hisobi orqali kirsa, Sayt.uz uning Google parolini bilmaydi, faqat Google bergan access token orqali email va profil ma'lumotlarini oladi.

Protokolda to'rt asosiy ishtirokchi bor: resource owner (foydalanuvchi), client (ilova), authorization server (Google) va resource server (Google API). Bu ajratish xavfsizlikni ta'minlaydi: ilova hech qachon foydalanuvchi parolini ko'rmaydi, va foydalanuvchi istalgan vaqtda ruxsatni bekor qilishi mumkin.

Authorization code flow

Eng xavfsiz va standart flow โ€” authorization code flow. Foydalanuvchi Google sahifasiga yo'naltiriladi va u yerda login qiladi. Google maxsus authorization code chiqaradi va foydalanuvchini ilovaga qaytaradi. Ilova bu code ni server tarafida client_secret bilan birga Google ga yuboradi va evaziga access token oladi.

Bu flow ning afzalligi shundaki, access token brauzer orqali o'tmaydi, faqat backend serverlari orasida almashtiriladi. Bu XSS va token leak hujumlaridan himoya qiladi. Sayt.uz da barcha social login ko'rsatkichlari ushbu flow asosida ishlaydi.

PKCE โ€” public client uchun himoya

Mobile va SPA ilovalar client_secret ni xavfsiz saqlay olmaydi, chunki ular foydalanuvchi qurilmasida ishlaydi. Bu muammoni hal qilish uchun PKCE (Proof Key for Code Exchange) standartidir. Ilova tasodifiy code_verifier yaratadi, uning SHA256 hashi (code_challenge) ni authorization request bilan yuboradi.

Token almashish paytida ilova asl code_verifier ni qayta yuboradi. Google uni hashlaydi va boshlang'ich code_challenge bilan solishtiradi. Agar mos kelsa, token beriladi. Hujumchi authorization code ni o'g'irlasa ham, code_verifier siz uni ishlata olmaydi.

Refresh token va session davomiyligi

Access token qisqa muddatli (1 soat), refresh token uzoq muddatli (30-90 kun). Foydalanuvchi har 1 soatda qayta login qilmasligi uchun ilova refresh token orqali avtomatik yangi access token oladi. Refresh token faqat backend da saqlanishi va hech qachon brauzerga ochiq berilmasligi kerak.

Sayt.uz amaliyotida refresh token rotation joriy qilingan: har refresh paytida eski refresh token bekor qilinib, yangisi beriladi. Agar bekor qilingan token qayta ishlatilsa, bu o'g'rilik belgisi va barcha foydalanuvchi sessiyalari majburiy yopiladi hamda email orqali ogohlantirish yuboriladi.

Google va Facebook integratsiyasi

Har bir provider o'zining authorization endpoint, token endpoint va userinfo endpoint ga ega. Google da bu accounts.google.com va www.googleapis.com, Facebook da esa graph.facebook.com. Scope parametrlari ham farqlanadi: Google da openid profile email standart, Facebook da public_profile email.

Sayt.uz da provider'lar uchun yagona interface yaratilgan: har bir provider o'zining adapter sinfini yozadi va bir xil getAuthUrl, getAccessToken, getUserInfo metodlarini bajaradi. Bu yangi provider qo'shishni osonlashtiradi va asosiy login logikasi o'zgarmaydi.

Sayt.uz amaliyot

Sayt.uz da OAuth integratsiyasi shunday: barcha provider'lar uchun authorization code flow, public client lar uchun PKCE majburiy, state parametri CSRF dan himoya, nonce parametri replay attack dan himoya. Access token Redis cache da 1 soat, refresh token shifrlangan holda PostgreSQL da. Har bir login va token refresh audit log ga yoziladi.

O'xshash maqolalar

๐Ÿ” Parol menejerlar โ€” Bitwarden, 1Password, LastPass va KeePass tanlovi ๐Ÿฏ Honeypot โ€” formada yashirin maydon, botlarni ushlaydi va spamni to'xtatadi ๐Ÿ“„ /.well-known/security.txt โ€” xavfsizlik bo'yicha bog'lanish standart ๐Ÿ“‹ GDPR moslik โ€” Yevropa ma'lumotlarini himoya qilish majburiyatlari
๐ŸŒ Til
๐Ÿ‡บ๐Ÿ‡ฟ O'zbek โœ“ ๐Ÿ‡บ๐Ÿ‡ฟ ะŽะทะฑะตะบ ๐Ÿ‡ท๐Ÿ‡บ ะ ัƒััะบะธะน ๐Ÿ‡ฌ๐Ÿ‡ง English