OAuth

OAuth — foydalanuvchi yoki ilovaga boshqa tizimdagi resurslarga cheklangan ruxsat berish uchun ishlatiladigan authorization protokoli. OAuth yordamida foydalanuvchi parolini uchinchi tomon ilovaga bermasdan, ma’lum ruxsatlar asosida access token oladi.

OAuth ko‘pincha “Google orqali kirish”, “GitHub orqali ulanish”, “Facebook bilan login” va tashqi API’lardan foydalanish jarayonlarida uchraydi.

Vazifasi

OAuth foydalanuvchi nomidan boshqa service yoki API’ga xavfsiz ruxsat berish uchun ishlatiladi.

OAuth quyidagi vazifalarni bajaradi:

foydalanuvchi parolini uchinchi tomon ilovaga bermaslik;
tashqi service orqali login qilish;
API resurslariga cheklangan access berish;
access token yaratish;
refresh token orqali sessiyani davom ettirish;
scope orqali ruxsatlarni chegaralash;
third-party integrationlarni boshqarish;
foydalanuvchi roziligi asosida access berish;
service’lar o‘rtasida authorization oqimini tashkil qilish.

Masalan, foydalanuvchi biror ilovaga Google Drive fayllarini o‘qish huquqini berishi mumkin, lekin Google parolini shu ilovaga bermaydi.

OAuth qanday ishlaydi?

OAuth’da foydalanuvchi, ilova va authorization server o‘rtasida ruxsat berish jarayoni bo‘ladi. Ilova foydalanuvchini authorization serverga yo‘naltiradi, foydalanuvchi ruxsat beradi, keyin ilova token oladi.

Oddiy jarayon:

foydalanuvchi ilovada “Google orqali kirish” tugmasini bosadi;
ilova foydalanuvchini Google authorization sahifasiga yo‘naltiradi;
foydalanuvchi login qiladi va ruxsat beradi;
authorization server ilovaga authorization code qaytaradi;
ilova authorization code orqali token so‘raydi;
authorization server access token qaytaradi;
ilova access token orqali API’ga murojaat qiladi.

OAuth parolni ulashmasdan ruxsat berish modeliga asoslanadi.

OAuth 2.0

OAuth 2.0 — OAuth protokolining keng ishlatiladigan zamonaviy versiyasi. U access token, scope, authorization code, refresh token va client ma’lumotlari asosida ishlaydi.

OAuth 2.0 quyidagi joylarda qo‘llanadi:

web login;
mobile login;
third-party API access;
service integration;
SaaS platformalar;
cloud service’lar;
developer API’lar;
OpenID Connect authentication.

OAuth 2.0 authorization protokoli hisoblanadi. Foydalanuvchi kimligini tasdiqlash uchun ko‘pincha OpenID Connect bilan birga ishlatiladi.

Resource owner

Resource owner — himoyalangan resurs egasi. Ko‘pincha bu foydalanuvchining o‘zi bo‘ladi.

Masalan:

Google Drive fayllari egasi;
GitHub repository egasi;
Facebook profil egasi;
cloud storage egasi;
email akkaunt egasi.

Resource owner ilovaga qaysi resurslarga kirish mumkinligini tasdiqlaydi.

Client

Client — foydalanuvchi nomidan resursga kirishni xohlaydigan ilova. Client web ilova, mobile ilova, desktop dastur yoki backend service bo‘lishi mumkin.

Client misollari:

task manager ilovasi;
analytics platformasi;
Telegram bot;
CRM tizimi;
mobile app;
SaaS service;
CI/CD integration.

Client OAuth oqimida authorization serverdan token oladi.

Authorization server

Authorization server — foydalanuvchini tasdiqlaydigan va token beradigan server. OAuth jarayonida client aynan shu server orqali access token oladi.

Authorization server quyidagilarni bajaradi:

foydalanuvchini login qildiradi;
ruxsat so‘rovini ko‘rsatadi;
authorization code beradi;
access token yaratadi;
refresh token berishi mumkin;
token expiration boshqaradi;
scope tekshiradi.

Masalan, Google OAuth tizimida Google authorization server vazifasini bajaradi.

Resource server

Resource server — himoyalangan API yoki resurslarni saqlaydigan server. Client access token orqali shu serverga so‘rov yuboradi.

Resource server quyidagilarni tekshiradi:

access token mavjudmi;
token yaroqlimi;
token muddati tugamaganmi;
scope yetarlimi;
so‘rov bajarishga ruxsat bormi.

Masalan, Google Drive API resource server bo‘lishi mumkin.

Access token

Access token — clientga himoyalangan resurslarga kirish uchun beriladigan token. OAuth’da access token API so‘rovlarida ishlatiladi.

Access token quyidagilarni bildiradi:

clientga ruxsat berilgan;
token ma’lum scope’larga ega;
token ma’lum muddat amal qiladi;
token resource server tomonidan tekshiriladi;
token orqali API access beriladi.

Access token odatda Authorization: Bearer <token> headeri orqali yuboriladi.

Refresh token

Refresh token — access token muddati tugaganda yangi access token olish uchun ishlatiladigan token.

Refresh token quyidagi jarayonda ishlaydi:

client access token va refresh token oladi;
access token muddati tugaydi;
client refresh token orqali yangi access token so‘raydi;
authorization server refresh tokenni tekshiradi;
yangi access token qaytaradi.

Refresh token uzoqroq sessiyalar va doimiy integrationlarda ishlatiladi.

Authorization code

Authorization code — foydalanuvchi ruxsat bergandan keyin clientga qaytariladigan vaqtinchalik kod. Client bu kodni access token olish uchun ishlatadi.

Authorization code xususiyatlari:

qisqa muddatli bo‘ladi;
bir marta ishlatiladi;
access tokenning o‘rnini bosmaydi;
token endpointga yuboriladi;
web ilovalar uchun xavfsizroq oqimda ishlatiladi.

Authorization code flow OAuth 2.0’da keng qo‘llanadi.

Scope

Scope — clientga berilgan ruxsat doirasi. Scope orqali client qaysi resurslarga va qanday amallarga kirishi mumkinligi belgilanadi.

Scope misollari:

read:profile;
write:profile;
read:email;
repo;
openid;
calendar.read;
drive.file.

Masalan, ilovaga faqat emailni o‘qish scope’i berilsa, u foydalanuvchi fayllarini o‘qiy olmaydi.

Consent screen — foydalanuvchiga ilova qanday ruxsatlar so‘rayotganini ko‘rsatadigan sahifa.

Consent screen’da quyidagilar bo‘lishi mumkin:

ilova nomi;
so‘ralgan scope’lar;
foydalanuvchi akkaunti;
ruxsat berish tugmasi;
rad etish tugmasi;
maxfiylik siyosati;
ilova egasi haqida ma’lumot.

Foydalanuvchi rozilik bermasa, client token ololmaydi.

Redirect URI

Redirect URI — authorization server foydalanuvchini ruxsatdan keyin qaytaradigan manzil.

Redirect URI quyidagi maqsadlarda ishlatiladi:

authorization codeni clientga qaytarish;
OAuth oqimini davom ettirish;
noto‘g‘ri clientga token berilishini cheklash;
web ilova callback endpointini belgilash.

Masalan:

https://example.com/auth/callback

Authorization server redirect URI’ni oldindan ro‘yxatdan o‘tgan manzillar bilan solishtiradi.

Client ID

Client ID — OAuth tizimida ilovani tanituvchi ochiq identifikator. Client ID maxfiy ma’lumot hisoblanmaydi.

Client ID quyidagilar uchun ishlatiladi:

ilovani aniqlash;
authorization request yuborish;
consent screen’da ilovani ko‘rsatish;
redirect URI bilan bog‘lash;
OAuth oqimini clientga bog‘lash.

Har bir OAuth client odatda alohida client ID’ga ega bo‘ladi.

Client secret

Client secret — confidential client uchun beriladigan maxfiy kalit. Client secret token olish jarayonida clientni tasdiqlash uchun ishlatiladi.

Client secret quyidagi joylarda ishlatiladi:

backend web ilovalar;
server-to-server authorization;
token endpoint;
client authentication;
confidential client oqimlari.

Client secret frontend yoki mobile ilova ichida ochiq saqlanmaydi.

Public client

Public client — maxfiy client secretni xavfsiz saqlay olmaydigan ilova turi.

Public client misollari:

SPA frontend;
mobile app;
desktop app;
browser-based ilova.

Public clientlar ko‘pincha PKCE bilan ishlaydi.

Confidential client

Confidential client — client secretni xavfsiz saqlay oladigan ilova turi.

Confidential client misollari:

backend web app;
server-side application;
internal service;
cloud backend;
enterprise integration.

Bunday clientlar token olishda client secret orqali o‘zini tasdiqlashi mumkin.

PKCE

PKCE — Proof Key for Code Exchange. PKCE OAuth authorization code flow’ni public clientlar uchun xavfsizroq qilishda ishlatiladi.

PKCE jarayonida:

client code verifier yaratadi;
undan code challenge hosil qiladi;
authorization requestda code challenge yuboriladi;
token olishda code verifier yuboriladi;
authorization server ularni solishtiradi;
mos kelsa token beradi.

PKCE mobile va SPA ilovalarda keng ishlatiladi.

Authorization Code Flow

Authorization Code Flow — OAuth 2.0’dagi eng ko‘p ishlatiladigan oqimlardan biri. Bu oqimda avval authorization code olinadi, keyin u access tokenga almashtiriladi.

Jarayon:

client foydalanuvchini authorization serverga yuboradi;
foydalanuvchi login qiladi;
ruxsat beradi;
authorization server code qaytaradi;
client code orqali token so‘raydi;
access token olinadi.

Bu oqim web ilovalar va PKCE bilan public clientlar uchun ishlatiladi.

Client Credentials Flow

Client Credentials Flow — foydalanuvchisiz, service-to-service authorization uchun ishlatiladigan OAuth oqimi.

Bu oqimda:

client o‘z client ID va secretini yuboradi;
authorization server clientni tekshiradi;
access token qaytaradi;
client shu token bilan API’ga murojaat qiladi.

Client Credentials Flow microservice, backend integration va server-to-server aloqalarda ishlatiladi.

Device Authorization Flow

Device Authorization Flow — klaviatura yoki browser imkoniyati cheklangan qurilmalarda OAuth orqali ruxsat olish usuli.

Bu oqim quyidagi qurilmalarda uchraydi:

smart TV;
CLI tool;
IoT qurilma;
game console;
terminal ilova.

Jarayonda foydalanuvchi boshqa qurilmada kod kiritib, ruxsat beradi.

Implicit Flow

Implicit Flow — eski OAuth oqimlaridan biri bo‘lib, access token to‘g‘ridan-to‘g‘ri browserga qaytarilgan. Zamonaviy tizimlarda uning o‘rniga Authorization Code Flow with PKCE ko‘proq ishlatiladi.

Implicit Flow quyidagi xususiyatlarga ega:

access token frontendga bevosita qaytariladi;
authorization code ishlatilmaydi;
refresh token odatda berilmaydi;
browser-based ilovalarda ishlatilgan.

Bu oqim OAuth tarixida muhim bo‘lgan, lekin zamonaviy xavfsizlik yondashuvlarida kamroq qo‘llanadi.

Resource Owner Password Credentials Flow

Resource Owner Password Credentials Flow — foydalanuvchi username va parolini clientga kiritadigan OAuth oqimi. Bu oqim faqat ishonchli clientlar uchun ishlatilgan.

Bu oqimda:

foydalanuvchi parolini clientga beradi;
client parolni authorization serverga yuboradi;
token olinadi.

Zamonaviy OAuth tizimlarida bu oqim kamroq ishlatiladi, chunki u parolni client orqali o‘tkazadi.

Token endpoint

Token endpoint — authorization code, refresh token yoki client credentials orqali access token olish uchun ishlatiladigan endpoint.

Token endpoint quyidagilarni qabul qilishi mumkin:

authorization code;
client ID;
client secret;
redirect URI;
code verifier;
refresh token;
grant type.

Token endpoint OAuth jarayonining markaziy qismlaridan biridir.

Authorization endpoint

Authorization endpoint — foydalanuvchini login va consent sahifasiga olib boradigan endpoint.

Authorization endpoint orqali:

client ruxsat so‘raydi;
foydalanuvchi login qiladi;
consent screen ko‘rsatiladi;
authorization code qaytariladi;
scope va redirect URI tekshiriladi.

Bu endpoint foydalanuvchi browseri orqali ishlaydi.

Grant type

Grant type — OAuth’da token olish uchun ishlatilayotgan oqim turini bildiradi.

Keng uchraydigan grant typelar:

authorization_code;
client_credentials;
refresh_token;
device_code;
password.

Grant type authorization serverga qaysi OAuth oqimi ishlayotganini bildiradi.

State parameter

State — OAuth request va callback o‘rtasida bog‘lanishni saqlash uchun ishlatiladigan parametr. State CSRFga o‘xshash hujumlarni kamaytirishda muhim rol o‘ynaydi.

State quyidagilar uchun ishlatiladi:

so‘rovni callback bilan bog‘lash;
foydalanuvchini asl sahifaga qaytarish;
OAuth oqimining yaxlitligini tekshirish;
noto‘g‘ri callbacklarni rad etish.

State qiymati odatda tasodifiy va vaqtinchalik bo‘ladi.

OpenID Connect

OpenID Connect — OAuth 2.0 ustida qurilgan authentication qatlami. OAuth authorization uchun mo‘ljallangan bo‘lsa, OpenID Connect foydalanuvchi kimligini aniqlash uchun ishlatiladi.

OpenID Connect quyidagilarni qo‘shadi:

ID token;
userinfo endpoint;
openid scope;
identity claimlar;
login holatini standartlashtirish.

“Google orqali kirish” kabi login tizimlari ko‘pincha OAuth 2.0 va OpenID Connect birikmasi bilan ishlaydi.

ID token

ID token — OpenID Connect’da foydalanuvchi kimligi haqida ma’lumot beradigan token. ID token odatda JWT formatida bo‘ladi.

ID token ichida quyidagilar bo‘lishi mumkin:

user ID;
email;
ism;
issuer;
audience;
expiration;
authentication vaqti.

ID token API access uchun emas, foydalanuvchi identity’sini tasdiqlash uchun ishlatiladi.

Userinfo endpoint

Userinfo endpoint — OpenID Connect’da foydalanuvchi profili haqida ma’lumot qaytaradigan endpoint.

Userinfo endpoint quyidagilarni qaytarishi mumkin:

user ID;
email;
name;
avatar;
locale;
email verified holati.

Client access token orqali userinfo endpointga murojaat qilishi mumkin.

OAuth o‘zi authentication protokoli emas, lekin OpenID Connect bilan birga login jarayonida ishlatiladi.

foydalanuvchi provider orqali tasdiqlanadi;
client ID token yoki userinfo orqali foydalanuvchi ma’lumotini oladi;
tizim ichida foydalanuvchi akkaunti yaratiladi yoki topiladi;
local session yoki token yaratiladi.

Masalan, foydalanuvchi Google orqali login qilganda, tizim Google’dan email va user ID olib, o‘z ichki akkaunti bilan bog‘laydi.

OAuth va API

OAuth API access boshqaruvida keng ishlatiladi. Client access token orqali resource serverga so‘rov yuboradi.

API OAuth orqali quyidagilarni tekshiradi:

token yaroqlimi;
token muddati tugamaganmi;
scope mosmi;
client ruxsatga egami;
foydalanuvchi resurs egasimi;
issuer va audience to‘g‘rimi.

Masalan, calendar.read scope’iga ega token kalendar voqealarini o‘qishi mumkin, lekin ularni o‘chira olmaydi.

OAuth va JWT

OAuth access tokenlari JWT yoki opaque token bo‘lishi mumkin. JWT token ichida claimlar saqlanadi, opaque token esa server orqali tekshiriladi.

OAuth’da JWT quyidagilar uchun ishlatilishi mumkin:

access token;
ID token;
token claimlari;
scope ma’lumotlari;
issuer va audience;
token validation.

OpenID Connect’da ID token odatda JWT formatida bo‘ladi.

OAuth va scope

Scope OAuth ruxsatlarini chegaralash uchun ishlatiladi. Client har doim ham barcha resurslarga kira olmaydi, faqat berilgan scope doirasida ishlaydi.

Scope orqali quyidagilar boshqariladi:

profil o‘qish;
email o‘qish;
fayl yaratish;
repositoryga kirish;
kalendarni o‘qish;
post joylash;
payment ma’lumotini ko‘rish.

Scope foydalanuvchi consent screen’da ko‘radigan asosiy ruxsatlar ro‘yxatiga kiradi.

OAuth va mobile ilova

Mobile ilovalarda OAuth odatda browser yoki system web view orqali ishlaydi. Ilova foydalanuvchini authorization serverga yuboradi va callback orqali natijani oladi.

Mobile OAuth’da quyidagilar uchraydi:

PKCE;
custom URL scheme;
universal link;
app link;
secure storage;
refresh token;
system browser session.

Mobile ilovalar public client hisoblanadi, chunki client secretni xavfsiz saqlash qiyin.

OAuth va SPA

SPA — Single Page Application, ya’ni browserda ishlaydigan frontend ilova. SPA OAuth’da public client hisoblanadi.

SPA OAuth’da quyidagilar uchraydi:

Authorization Code Flow with PKCE;
access token;
refresh token rotation;
CORS;
redirect URI;
browser storage;
silent refresh;
cookie-based authentication.

SPA’da token saqlash va XSS/CSRF xavfsizlik modeli muhim hisoblanadi.

OAuth va backend

Backend OAuth oqimida confidential client sifatida ishlashi mumkin. Backend client secretni saqlaydi va token endpoint bilan server tomonda aloqa qiladi.

Backend OAuth’da:

authorization code qabul qilinadi;
client secret bilan token olinadi;
userinfo endpointdan ma’lumot olinadi;
local session yaratiladi;
refresh token serverda saqlanishi mumkin;
foydalanuvchi ichki akkaunt bilan bog‘lanadi.

Server-side OAuth login web ilovalarda keng ishlatiladi.

OAuth va third-party integration

OAuth tashqi service’lar bilan integration qilishda ko‘p ishlatiladi.

Integration misollari:

Google Calendar bilan ulanish;
GitHub repository access;
Slack bot integratsiyasi;
Facebook sahifaga post joylash;
Dropbox fayl o‘qish;
Microsoft 365 bilan ulanish;
payment provider bilan authorization.

Bunday integrationlarda foydalanuvchi ma’lum scope’larga ruxsat beradi.

OAuth xavfsizligi

OAuth xavfsizligi token, redirect URI, scope, client secret va callback jarayonlariga bog‘liq.

OAuth xavfsizligida quyidagilar muhim:

redirect URI’ni qat’iy tekshirish;
PKCE ishlatish;
state parametrini tekshirish;
client secretni maxfiy saqlash;
minimal scope so‘rash;
access token muddatini cheklash;
refresh tokenni himoyalash;
HTTPS ishlatish;
tokenlarni logga chiqarmaslik.

OAuth noto‘g‘ri sozlansa, ruxsatsiz access yoki token leak xavfi paydo bo‘lishi mumkin.

Token leak

OAuth token leak — access token yoki refresh tokenning ruxsatsiz tomon qo‘liga tushib qolishi.

Token leak quyidagi joylarda yuzaga kelishi mumkin:

URL fragment yoki query;
server loglari;
browser storage;
public repository;
noto‘g‘ri redirect URI;
XSS;
zararli extension;
CI/CD secret xatosi.

Token leak bo‘lsa, token scope’i doirasida resurslarga kirish mumkin bo‘lishi mumkin.

Redirect URI attack

Redirect URI attack noto‘g‘ri sozlangan redirect manzillar orqali authorization code yoki tokenni boshqa joyga yuborishga urinishdir.

Bu muammo quyidagilar bilan bog‘liq:

wildcard redirect URI;
noto‘g‘ri domain tekshiruvi;
open redirect;
callback URL manipulyatsiyasi;
client sozlamasidagi xatolik.

Redirect URI OAuth xavfsizligining asosiy qismlaridan biridir.

OAuth va authorization

OAuth asosan authorization uchun ishlatiladi. U clientga foydalanuvchi resurslariga cheklangan ruxsat beradi.

Authorization jarayonida OAuth quyidagilarni boshqaradi:

kim ruxsat berdi;
qaysi client ruxsat oldi;
qaysi scope’lar berildi;
token qancha muddat amal qiladi;
resource server tokenni qanday tekshiradi.

OAuth “ilovaga qaysi resurslarga kirish mumkin?” savoliga javob beradi.

Dasturlashdagi o‘rni

OAuth zamonaviy web, mobile, API va cloud tizimlarda tashqi authorization va third-party integrationlar uchun ishlatiladigan muhim protokoldir. U foydalanuvchi parolini ulashmasdan, token va scope asosida resurslarga ruxsat berish imkonini yaratadi.

OAuth quyidagi loyihalarda uchraydi:

Google orqali login;
GitHub orqali login;
mobile ilovalar;
SPA frontendlar;
SaaS platformalar;
tashqi API integrationlar;
cloud service’lar;
developer platformalar;
bot va automation tizimlari;
enterprise SSO tizimlari.

OAuth foydalanuvchi, client, authorization server va resource server o‘rtasida cheklangan ruxsat berish jarayonini standartlashtiradi.

Bog‘liq tushunchalar

Authentication, Authorization, Token, JWT, Access token, Refresh token, OpenID Connect, Scope, API, Client ID, Client secret, PKCE