# API Autentifikatsiya va Avtorizatsiya — Kim ekanligingizni qanday isbotlaysiz? > API ga so'rov yuborganingizda server "sen kim?" deb so'raydi. Siz javob bera olmasangiz — kirish yopiq. ## 🔄 Eslab ko'ring (oldingi darsdan) > Oldingi darsda HTTP so'rov tuzilishini ko'rdik. So'rovning to'rtta qismi nima edi? `Authorization` header qaysi qismga kiradi? Eslab ko'ring, keyin davom eting. ## 🔍 Darsdan oldin bir daqiqa (pre-assessment) > **O'ylab ko'ring:** Binosiga kirishda xodimlar kartochkani o'qitadi. Ba'zilari faqat birinchi qavat eshiklarini ochadi, boshqalari barcha qavatlarni. Bu ikki holat bir-biridan nimasi bilan farq qiladi? > _(Javobingizni eslab qoling — dars oxirida fikringiz o'zgarganini ko'rasiz.)_ ## 🎯 Bu darsdan keyin siz - Autentifikatsiya va avtorizatsiya farqini tushuntirasiz - API Key, Basic Auth, JWT va OAuth usullarini solishtirasiz - JWT tokenning tuzilishini ko'rasiz - OAuth 2.0 jarayonini diagrammada tushuntirasiz - Rate Limiting nima va nima uchun muhim ekanini bilasiz --- ## Autentifikatsiya va Avtorizatsiya — farqi nima? ### 🌍 Hayotiy o'xshatish Metroga kirganingizda karta o'qitasiz — bu sizning kim ekanligingizni tasdiqlaydi (**autentifikatsiya**). Lekin yo'lovchi kartasi sizni faqat metro vagoniga kiritadi, mashinistlar xonasiga emas — bu ruxsatni tekshirish (**avtorizatsiya**). ### 📖 Aniq ta'rif **Autentifikatsiya (authentication)** — "sen kim?" savoliga javob. Foydalanuvchi o'zligini isbotlaydi: parol, token, kalit. **Avtorizatsiya (authorization)** — "nima qilishingga ruxsat?" savoliga javob. Isbotlangandan keyin qaysi resurslarga kirish mumkinligini tekshiradi. ### 🛡️ Xavfsizlik uchun nima uchun muhim? Ko'p tizimlar autentifikatsiyani to'g'ri qiladi, avtorizatsiyani unutadi. Natija: kimdir login qilgan, lekin boshqalarning ma'lumotlarini ko'rishi mumkin. Keyingi darsda ko'radigan BOLA zaifligi aynan shu — "kim?" tekshirilgan, "nimaga ruxsat?" tekshirilmagan. ### 🔎 Ishlangan misol ```text Autentifikatsiya: "Men Otabek — tokenim bu." Avtorizatsiya: "Otabek o'z profilini ko'ra oladi, boshqalarnikini ko'ra olmaydi." ``` ```mermaid flowchart LR U["So'rov keldi"] --> A{"Autentifikatsiya
Sen kimsan?"} A -->|"Token yo'q / noto'g'ri"| E1["401 Unauthorized"] A -->|"Token to'g'ri"| Z{"Avtorizatsiya
Bunga ruxsating bormi?"} Z -->|"Ruxsat yo'q"| E2["403 Forbidden"] Z -->|"Ruxsat bor"| OK["200 OK — ma'lumot beriladi"] style A fill:#1565c0,color:#fff style Z fill:#e65100,color:#fff style OK fill:#2e7d32,color:#fff ``` !!! tip "Asosiy g'oya" Avval **autentifikatsiya** (kim?), keyin **avtorizatsiya** (nimaga ruxsat?). Tartib doim shu. Kim ekaningni bilmasdan, nimaga ruxsating borligini aniqlab bo'lmaydi. --- ## API autentifikatsiya usullari ```mermaid flowchart TD AUTH["API Autentifikatsiya Usullari"] AUTH --> BASIC["Basic Auth
Username:Password"] AUTH --> APIKEY["API Key
Maxsus kalit"] AUTH --> BEARER["Bearer Token - JWT
Imzolangan token"] AUTH --> OAUTH["OAuth 2.0
Uchinchi tomon orqali"] BASIC --> B_L["Oddiy, lekin xavfli"] APIKEY --> A_L["Oddiy integratsiya"] BEARER --> T_L["Zamonaviy standart"] OAUTH --> O_L["Eng xavfsiz, murakkab"] style AUTH fill:#1a237e,color:#fff style BASIC fill:#b71c1c,color:#fff style BEARER fill:#2e7d32,color:#fff ``` --- ## 1. Basic Authentication (Asosiy autentifikatsiya) ### 🌍 Hayotiy o'xshatish Har safar do'konga kirganingizda pasportingizni ko'rsatishingizni tasavvur qiling. Har bir so'rovda parol yuborish ham xuddi shunday — qulay, lekin xavfli. ### 📖 Aniq ta'rif **Basic Auth** — username va parolni **Base64** (ikkilik-matn konvertatsiyasi) da kodlab, har bir so'rovda yuborish. Eng oddiy, lekin eng xavfli usul. ### 🛡️ Xavfsizlik uchun nima uchun muhim? Base64 — bu **shifrlash emas**. Har kim uni decode qilishi mumkin. HTTPS bo'lmasa, tarmoqdagi har kim parolni ko'radi. ### 🔎 Ishlangan misol ```bash title="basic_auth.sh" curl -u "admin:secret123" https://api.misol.com/data # Aslida header sifatida yuboriladi: # Authorization: Basic YWRtaW46c2VjcmV0MTIz # base64("admin:secret123") = YWRtaW46c2VjcmV0MTIz # Bu decode qilish uchun: echo "YWRtaW46c2VjcmV0MTIz" | base64 -d # Natija: admin:secret123 ``` !!! warning "Keng tarqalgan xato: Base64 = himoya emas" Ko'pchilik Base64 ni "shifrlangan" deb o'ylaydi. Aslida bu shunchaki boshqa alifboda yozish — har kim bir buyruq bilan ochadi. Parolni Base64 qilish = parolni boshqacha harf bilan yozish, qulflash emas. **So'z diagrammasi:** ```text Basic Auth: username:parol → base64 → Header Base64 = kodlash (shifrlash EMAS!) Har kim decode qila oladi Faqat HTTPS bilan qisman xavfsiz ``` --- ## 2. API Key ### 🌍 Hayotiy o'xshatish Kutubxona kartochkangiz bor. U sizning ismingizdagi emas — faqat "kartochka egasi" deydi. Kartochkani yo'qotsangiz, topgan odam ham kutubxonaga kira oladi. API Key ham xuddi shunday. ### 📖 Aniq ta'rif **API Key** — ilova uchun berilgan maxsus identifikator (unikal belgilar qatori). Ilova har so'rovda shu kalitni yuboradi. Foydalanuvchi emas — ilovani identifikatsiya qiladi. ### 🛡️ Xavfsizlik uchun nima uchun muhim? API Key GitHub'ga push qilinsa — butun dunyo ko'radi. URL da yuborilsa — web server loglarida saqlanib qoladi. Har doim header da, HTTPS orqali yuborilishi kerak. ### 🔎 Ishlangan misol ```bash title="api_key.sh" # To'g'ri — header orqali curl -H "X-API-Key: sk_live_abc123def456" https://api.misol.com/data # Noto'g'ri — URL orqali (log faylda saqlanib qoladi!) curl "https://api.misol.com/data?api_key=sk_live_abc123def456" ``` !!! danger "API Key va GitHub — etika va xavfsizlik" `.env` faylni `.gitignore` ga qo'shing. Agar API Key GitHub'ga tushib ketsa, darhol uni bekor qiling (revoke) va yangi kalit oling. GitHub Secret Scanning bunday kalitlarni avtomatik topib, egasiga xabar beradi — ya'ni siz topishdan oldin boshqalar topishi mumkin. O'zganing ochiq qolgan kalitidan foydalanish ham O'zR JK 278-modda bo'yicha jinoyat. --- ## 3. Bearer Token va JWT ### 🌍 Hayotiy o'xshatish Kinoteatr kassasidan chipta olasiz. Chipta sizning kim ekanligingizni isbotlamaydi — faqat "shu seansga ruxsat bor" deydi. Muddati tugagach, amal qilmaydi. JWT token ham xuddi shu chipta. ### 📖 Aniq ta'rif **JWT (JSON Web Token — JSON veb tokeni)** — raqamli imzolangan token. Login qilinganda server beradi. Har so'rovda `Authorization: Bearer ` header sifatida yuboriladi. JWT uch qismdan iborat, nuqta bilan ajratilgan: ```text eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Mn0.abc123 ↑ Header ↑ Payload (ma'lumot) ↑ Imzo (algoritm) (user_id, muddat) ``` ### 🛡️ Xavfsizlik uchun nima uchun muhim? JWT ning imzosi o'zgartirilsa, server tekshirib rad etadi. Lekin **Payload ochiq** — base64 decoded qilinsa, ma'lumot ko'rinadi. Maxfiy ma'lumot JWT ga qo'ymaslik kerak. ### 🔎 Ishlangan misol ```bash title="jwt_login.sh" # 1-qadam: Login qilib token olish curl -X POST https://api.misol.com/auth/login \ -H "Content-Type: application/json" \ -d '{"username": "otabek", "password": "sir123"}' # Javob: # { # "access_token": "eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Mn0.abc", # "refresh_token": "eyJhbGciOi...", # "expires_in": 900 ← 15 daqiqa # } # 2-qadam: Token bilan so'rov yuborish curl https://api.misol.com/v1/profil \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." ``` JWT yashash davri — vaqt bo'yicha: ```mermaid sequenceDiagram participant U as "Foydalanuvchi" participant S as "Server" U->>S: "Login (username + parol)" S-->>U: "access_token (15 daq) + refresh_token (7 kun)" U->>S: "So'rov + access_token" S-->>U: "200 OK" Note over U,S: "15 daqiqadan keyin access_token o'ladi" U->>S: "refresh_token bilan yangilash" S-->>U: "Yangi access_token" ``` **So'z diagrammasi — access_token vs refresh_token:** ```text access_token: qisqa muddatli (15 daqiqa) har so'rovda yuboriladi o'g'irlansa — 15 daqiqa xavf refresh_token: uzun muddatli (7 kun) faqat yangi access_token olish uchun xavfsiz joyda saqlanadi Nima uchun ikki token: access_token o'g'irlansa → 15 daqiqada o'lik refresh_token xavfsiz → uni o'g'irlash qiyinroq ``` !!! warning "JWT payload maxfiy emas" JWT ning o'rta qismi (payload) shunchaki Base64 — har kim ochib o'qiy oladi (parol, karta raqami EMAS!). Imzo faqat "o'zgartirilmaganini" kafolatlaydi, "yashirinligini" emas. Maxfiy narsani JWT ichiga solmang. --- ## 4. OAuth 2.0 ### 🌍 Hayotiy o'xshatish Yangi ilovaga "Google bilan kirish" bosdingiz. Ilovaga Google parolingizni bermadingiz — Google o'zi tekshirdi va ilovaga "bu kishi — Otabek" deb tasdiqladi. Ilovaga faqat ism va emailingiz berildi. ### 📖 Aniq ta'rif **OAuth 2.0 (Open Authorization — Ochiq avtorizatsiya)** — uchinchi tomon (Google, GitHub, Telegram) orqali kirish protokoli. Parolingizni ilovaga bermasdan kirasiz. ### 🛡️ Xavfsizlik uchun nima uchun muhim? Ilova buzilsa ham, sizning Google parolingiz xavfsiz — chunki u Google'dan tashqariga chiqmaydi. Ilova faqat ruxsat berilgan ma'lumotlarni (email, ism) ko'radi, to'liq profilni emas. ### 🔎 Ishlangan misol ```mermaid sequenceDiagram participant U as "Foydalanuvchi" participant APP as "HackNow" participant G as "Google" U->>APP: "Google bilan kirish" tugmasi APP->>G: "Redirect: /authorize?client_id=xxx" G->>U: "Google login sahifasi ko'rinadi" U->>G: "Email + parol kiritadi" G->>APP: "Redirect: /callback?code=AUTH_CODE" APP->>G: "POST /token — code + client_secret" G-->>APP: "access_token + id_token" APP-->>U: "Login muvaffaqiyatli!" ``` **So'z diagrammasi:** ```text OAuth 2.0 jarayoni: 1. Siz "Google bilan kir" bosasiz 2. HackNow sizni Google ga yo'naltiradi 3. Google da o'zingiz kirasiz (parolingiz HackNow ga bormaydi) 4. Google HackNow ga: "Bu Otabek, unga ruxsat" deydi 5. HackNow siz kirgansiz deb qabul qiladi ``` !!! danger "client_secret frontend da — hech qachon!" `client_secret` ni JavaScript kodida (frontend) **hech qachon** saqlamang. U faqat backend da bo'ladi. Frontend kodini har kim brauzerda ochib ko'ra oladi — demak u yerga qo'yilgan "secret" allaqachon sir emas. --- ## Rate Limiting (So'rovlar cheklovchi) ### 🌍 Hayotiy o'xshatish Supermarketda bir xaridorga kuniga 100 ta paket shakar sotishadi. Bu cheklov bor sababi: tovar tugamasin, boshqalarga ham yetsin, ulgurji xaridorlar noqonuniy savdo qilmasin. ### 📖 Aniq ta'rif **Rate Limiting (so'rovlar cheklovi)** — API ga muayyan vaqt ichida yuborilishi mumkin bo'lgan so'rovlar sonini cheklash. DDoS, brute-force va spam hujumlaridan asosiy himoya. ### 🛡️ Xavfsizlik uchun nima uchun muhim? Rate limiting yo'q bo'lsa — hujumchi login API ga soniyada minglab parol sinab ko'radi. Bu **brute-force (kuch bilan buzish)** hujumidir. ### 🔎 Ishlangan misol ```http title="rate_limit_headers.http" # API javobida rate limit headerlari: HTTP/1.1 200 OK X-RateLimit-Limit: 100 # 1 daqiqada maksimum 100 so'rov X-RateLimit-Remaining: 45 # Qolgan so'rovlar soni X-RateLimit-Reset: 1712680060 # Cheklov qachon yangilanadi # Cheklov oshganda: HTTP/1.1 429 Too Many Requests Retry-After: 30 # 30 sekunddan keyin qayta urinib ko'ring ``` Nima uchun rate limiting brute-force'ni to'xtatadi — sonlar bilan. 8 belgili faqat kichik harfli parol uchun variantlar soni: $$ 26^{8} \approx 2{,}09 \times 10^{11} \text{ ta kombinatsiya} $$ Agar rate limit daqiqasiga 100 urinishga ruxsat bersa, barcha variantni sinash uchun millionlab yil kerak bo'ladi. Rate limiting'siz, soniyasiga minglab urinish bilan esa bu vaqt keskin qisqaradi. **So'z diagrammasi:** ```text Rate Limiting strategiyalari: Fixed Window: 1 daqiqada 100 so'rov (oddiy) Sliding Window: har 60 sekundlik oyna uchun 100 (aniqroq) Token Bucket: har soniyada 1 token qo'shiladi (burst ruxsat) Himoya darajalari: IP asosida — har IP uchun alohida limit User asosida — har foydalanuvchi uchun alohida Global — barcha so'rovlar uchun umumiy ``` !!! warning "Rate Limiting ni chetlab o'tish urinishlari" Hujumchilar: IP rotation (ko'p IP dan yuborish), Slow brute-force (sekin-sekin), Header manipulation (`X-Forwarded-For` ni o'zgartirish). Yaxshi himoya — uch darajali: IP + User + Global. --- ## ⚠️ Keng tarqalgan xatolar | Noto'g'ri tushuncha | Haqiqat | |---------------------|----------| | "Autentifikatsiya = avtorizatsiya" | Autentifikatsiya: kim? Avtorizatsiya: nima qilishga ruxsat? Ikki alohida tekshiruv | | "Base64 = shifrlash" | Base64 faqat kodlash — har kim decode qiladi. Shifrlash emas | | "JWT ichidagi ma'lumot maxfiy" | JWT payload ochiq — base64 decode qilinsa ko'rinadi. Maxfiy narsa qo'ymang | | "Rate limiting faqat hujumdan himoya" | Rate limiting xato koddan (loop) kelib chiqadigan haddan tashqari yukmani ham pasaytiradi | ## ✅ Tez tekshiruv — bilasizmi? **Savol:** Login API da rate limiting yo'q. Hujumchi "admin" uchun parol tanlashga urindi. Bu qanday hujum va nima xavf?

Javobni ko'rish

Brute-force (kuch bilan buzish) hujumi. Rate limiting bo'lmasa, hujumchi soniyada minglab parol sinab ko'radi. 8 belgili kichik harf parol uchun taxminan 200 milliard kombinatsiya bor — tezkor server bilan bir necha soatda ochilishi mumkin.

## 🧪 O'zingiz sinab ko'ring JWT tokenning Payload qismini decode qiling. Bu xavfsiz — faqat o'qish: 1. `https://jwt.io` saytini oching. 2. Chap tarafga ixtiyoriy JWT token joylashtiring (misol uchun: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjo0Miwicm9sZSI6InN0dWRlbnQiLCJleHAiOjE3MDAwMDAwMDB9.abc123`) 3. O'ng tarafda Payload qismi ochiladi — `user_id`, `role`, `exp` kabi maydonlar ko'rinadi. 4. Xulosa: JWT ichidagi ma'lumot maxfiy emas! ## ⚖️ Etika eslatmasi Bu darsda OAuth, JWT, rate limiting — bularni tushunish himoyachilar uchun zarur. Birovning API tokenini o'g'irlash yoki login API ga brute-force qilish — O'zR JK 278-modda bo'yicha jinoyat. Amaliyot faqat ruxsat berilgan muhitda. ## ✅ Eng muhimi (xulosa) - **Autentifikatsiya** — kim ekanligini isbotlash. **Avtorizatsiya** — nima qilishga ruxsat borligini tekshirish. - **Basic Auth** — oddiy, xavfli, zamonaviy API larda tavsiya etilmaydi. - **JWT** — access_token (qisqa) + refresh_token (uzun). Payload ochiq — maxfiy narsa qo'ymang. - **OAuth 2.0** — "Google bilan kirish". Parol ilovaga bormaydi. - **Rate Limiting** — brute-force dan asosiy himoya. Yo'q bo'lsa — zaiflik. ## ➡️ Keyingi qadam **Keyingi dars:** OWASP API Security Top 10 — eng xavfli API zaifliklarni ko'ramiz. **Hayotda qo'llang (transfer):** Ishlatiladigan ilovangizda "Google bilan kirish" tugmasi bormi? Endi uning ortida nima borishini bilasiz. **1 soatdan keyin eslab ko'ring:** Autentifikatsiya, avtorizatsiya, JWT, rate limiting — 4 ta atamani izohsiz tushuntirib bera olasizmi?

REST API va JSON

REST API va JSON — Zamonaviy web aloqa