WEB_SECURITY // 2026
Authentication
// basic · session · jwt · oauth 2.0 — istifadəçi kimdir və nə üçün ona etibar edirik?
Ağayev Əli · SABAH qrupları ~/web-security/auth
// 01 · giriş 02 / 10

Authentication vs Authorization

İki anlayış tez-tez qarışdırılır. Biri kimliyi yoxlayır, digəri isə icazəni.

// authentication

Sən kimsən?
  • İstifadəçinin kimliyini təsdiqləyir — şifrə, token, sertifikat, biometrik
  • Birinci addım: sistem səni tanıyana qədər heç nə edə bilməzsən
  • Nümunə: login səhifəsində email + şifrə daxil etmək

// authorization

Nə etməyə icazən var?
  • Artıq tanınan istifadəçinin hansı resursa toxuna biləcəyini müəyyən edir
  • Rol və icazələr üzərində qurulur — admin, user, guest
  • Nümunə: istifadəçi yalnız öz profilini redaktə edə bilər, başqasınınkını yox
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 02 · ən sadəsi 03 / 10

Basic Authentication

HTTP standartının bir hissəsi. Hər request-də Authorization header-ində Base64 ilə kodlanmış username:password göndərilir.
HTTP REQUEST 
GET /api/profile HTTP/1.1
Host: example.com
Authorization: Basic YWxpOnBhc3N3b3JkMTIz
# base64("ali:password123")
# diqqət: kodlama ≠ şifrələmə
!
Base64 şifrələmə deyil — hər kəs asanlıqla geri aça bilər
!
HTTPS olmadan təhlükəli — şifrə şəbəkədən oğurlana bilər
!
Hər request-də göndərilir — ifşa olma riski artır
!
Logout mexanizmi yoxdur — brauzer yaddaşda saxlayır
✓
İstifadə yeri: yalnız daxili alətlər, admin panellər, HTTPS arxasında
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 03 · server yaddaşı 04 / 10

Session-based Auth (cookies)

Server login-dən sonra bir session_id yaradır və cookie vasitəsilə brauzerə göndərir. Sonrakı hər request-də cookie avtomatik geri gəlir.
// client
Brauzer
cookie yaddaşı
01POST /login · email+şifrə
Set-Cookie: session_id=a8f…02
03GET /profile · Cookie: session_id=a8f…
200 OK · { user data }04
// server
Backend
sessions tbl
a8f… → user_id:42
+ Stateful — session məlumatı server-də saxlanılır (DB / Redis). Logout asandır: sessionu silmək kifayətdir. − Scale etmək çətindir: bir neçə server arasında session paylaşımı lazımdır.
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 04 · stateless token 05 / 10

JWT — JSON Web Token

Üç hissədən ibarət, nöqtə ilə ayrılmış token. Server onu yaddaşda saxlamır — imza ilə təsdiq edir və məzmununu tokenin özündən oxuyur.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsIm5hbWUiOiJBbGkiLCJpYXQiOjE3MTN9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header
"alg": "HS256",
"typ": "JWT"
Hansı alqoritmlə imzalanıb
Payload · Claims
"sub": "42",
"name": "Ali",
"role": "user",
"exp": 1713999999
İstifadəçi haqqında məlumat — açıq oxunur!
Signature
HMACSHA256(
  base64(header) + "." +
  base64(payload),
  SECRET_KEY
)
Məzmunun dəyişmədiyini təsdiq edir
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 05 · delegation 06 / 10

OAuth 2.0 — Authorization Code Flow

“Google ilə daxil ol” düyməsinin arxasındakı protokol. İstifadəçi şifrəsini üçüncü tərəf tətbiqə vermir — yalnız məhdud icazə verir.
// userİstifadəçi
// clientTətbiq
// auth serverGoogle
// resourceGoogle API
  1. 1
    Tətbiq istifadəçini Google-un auth səhifəsinə yönləndirir — client_id, scope, redirect_uri
  2. 2
    İstifadəçi Google-da giriş edir və tətbiqə email · profile icazəsi verir
  3. 3
    Google qısa müddətli authorization code ilə istifadəçini tətbiqə geri yönləndirir
  4. 4
    Tətbiq backend-i bu kod + client_secret ilə Google-dan access_token alır
  5. 5
    Tətbiq access_token ilə Google API-dən istifadəçi məlumatını çəkir — və ona giriş verir
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 06 · şifrələrin saxlanması 07 / 10

Şifrələri heç vaxt açıq saxlamayın

DB-də şifrə yalnız one-way hash olaraq saxlanılır. Hər şifrə üçün fərqli salt əlavə olunur ki, eyni şifrələr fərqli görünsün.
// user input password123
→
bcrypt
// stored in db $2b$12$R9h7.mK2yLqXv8uZ5bW3eF/C1n0oP4iS6tGq
alg · cost · salt · hash
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 07 · təhdidlər 08 / 10

Ümumi Hücumlar

Yaxşı auth dizaynı hücumları nəzərə alaraq qurulur
// xss
Cross-Site Scripting
Hücumçunun JavaScript kodu səhifədə icra olunur və localStorage-dakı tokeni oğurlayır.
→ Input sanitize · CSP header · httpOnly cookie
// csrf
Cross-Site Request Forgery
Başqa sayt istifadəçinin cookie-si ilə sizin API-yə icazəsiz request göndərir.
→ CSRF token · SameSite=Strict cookie
// hijack
Session Hijacking
Şəbəkə sniffing və ya XSS ilə oğurlanmış session_id hücumçuya giriş verir.
→ HTTPS only · Secure + httpOnly cookie · rotate
// brute force
Brute Force
Avtomatik şəkildə milyonlarla şifrə kombinasiyası sınanır — xüsusən zəif şifrələrdə işləyir.
→ Rate limiting · CAPTCHA · account lockout
// replay
Token Replay
Ələ keçirilmiş token başqa yerdə təkrar istifadə edilir — stateless JWT-də xüsusilə təhlükəli.
→ Qısa exp · refresh token · jti blacklist
// phishing
Phishing
Saxta login səhifələri istifadəçidən legitim şəkildə şifrə istəyir — ən yayılmış hücum.
→ MFA · WebAuthn · istifadəçi təhsili
// 08 · tövsiyələr 09 / 10

Best Practices

Auth sistemi qurarkən minimum standartlar — bunlar olmadan heç bir sxem etibarlı deyil.
  1. 01
    Hər şey HTTPS üzərindən. Plain HTTP-də auth yoxdur — token və şifrələr şəbəkədən oxunur.
  2. 02
    Şifrələri bcrypt / argon2 ilə hash edin. Heç vaxt açıq, MD5, və ya SHA-256 ilə saxlamayın.
  3. 03
    Cookies: httpOnly, Secure, SameSite. JavaScript-in cookie-yə çatışını bağlayın.
  4. 04
    Token-lərin exp-i qısa olsun. Uzun access token + qısa refresh token nümunəsini istifadə edin.
  5. 05
    Rate limiting + account lockout. Login endpoint brute-force üçün ən birinci hədəfdir.
  6. 06
    MFA dəstəkləyin. Bir faktor — şifrə — artıq kifayət deyil. TOTP, WebAuthn əlavə edin.
  7. 07
    Öz auth-ınızı yazmayın. Auth0, Keycloak, Firebase Auth, next-auth — test edilmiş həllər var.
  8. 08
    Error mesajları ümumi olsun. “email yoxdur” vs “şifrə səhvdir” — hücumçuya məlumat verir.
WEB_SECURITY · AUTHAĞAYEV ƏLİ
// 09 · oxumalar 10 / 10

Mənbələr & oxumalar

Daha dərin öyrənmək istəyənlər üçün — rəsmi standartlar və tətbiqi təlimatlar.
Təşəkkürlər — suallar?
ağayev əli · sabah qrupları · 2026