როგორ მუშაობს JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** არის კომპაქტური, URL-უსაფრთხო, თვითშემცველი token, რომელიც ატარებს claim-ებს მომხმარებლის შესახებ. სერვერი ხელს აწერს მას ერთხელ; შემდეგ მას შეუძლია token-ის **გადამოწმება** ყოველ მოთხოვნაზე მონაცემთა ბაზაში ძებნის გარეშე — სწორედ ეს ხდის JWT-ზე დაფუძნებულ ავთენტიფიკაციას *stateless*-ს.

## სტრუქტურა: სამი base64url ნაწილი

JWT არის `header.payload.signature`, სამი base64url-ით კოდირებული სეგმენტი, წერტილებით შეერთებული:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — ხელმოწერის ალგორითმი, მაგ. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claim**-ები: სტანდარტული, როგორიც არის `sub` (subject/user id), `exp` (ვადა), `iat` (გამოშვების დრო), `iss` (issuer), პლუს ნებისმიერი custom ველი (`role`, `email`).
- **Signature** — გამოთვლილი header-სა და payload-ზე secret-ით ან private key-ით.

> payload **კოდირებულია, არა დაშიფრული**. ნებისმიერს შეუძლია base64-დეკოდირება და წაკითხვა, ამიტომ არასდროს ჩადო პაროლები ან საიდუმლოები JWT-ში.

## როგორ მუშაობს ხელმოწერა და გადამოწმება

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (სიმეტრიული): ერთი და იგივე secret აწერს ხელს და ამოწმებს. მარტივია, მაგრამ ყველა გადამმოწმებელს secret უნდა ჰქონდეს.
- **RS256** (ასიმეტრიული): **private key** აწერს ხელს, **public key** ამოწმებს. auth სერვერი ინახავს private key-ს; სხვა სერვისები ამოწმებენ public key-ით და token-ის მოჭრა არასდროს შეუძლიათ.

ყოველ მოთხოვნაზე სერვერი ხელახლა ითვლის ხელმოწერას მიღებულ header+payload-ზე და ადარებს. თუ ემთხვევა და `exp` მომავალშია, token სანდოა — session store არ სჭირდება.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // ისვრის, თუ შეცვლილია ან ვადაგასულია
  // claims.sub === "123"
} catch (e) {
  // უარყოფა: არასწორი ან ვადაგასული
}
```

## რთული ნაწილი: გაუქმება (revocation)

რადგან გადამოწმება stateless-ია, **ვერ** გააუქმებ token-ს ვადის გასვლამდე უბრალოდ სერვერის მხარეს მისი „წაშლით“. გავრცელებული შემარბილებელი ზომები:

- შეინახე access token-ები **ხანმოკლედ** (5–15 წუთი) და დააწყვილე უფრო ხანგრძლივ **refresh token**-თან.
- აწარმოე გაუქმებული token id-ების (`jti`) პატარა **denylist** გამოსვლისთვის/კომპრომეტირებისთვის — ეს ცოტა state-ს აბრუნებს.
- როტაცია გაუკეთე ხელმოწერის გასაღებებს.

## შენახვის კომპრომისები

| შენახვა | უპირატესობა | ნაკლი |
|---|---|---|
| `httpOnly` cookie | JS ვერ კითხულობს (XSS-ისგან უფრო უსაფრთხო) | სჭირდება CSRF დაცვა |
| `localStorage` | მარტივი, CSRF-ის გარეშე | ღიაა XSS-ისთვის |

## რატომ არის ეს მნიშვნელოვანი

JWT-ები კვებავს stateless ავთენტიფიკაციას API-ების, მიკროსერვისების და SPA-ების გასწვრივ — სერვისს შეუძლია მოთხოვნას ენდოს მხოლოდ ხელმოწერის გადამოწმებით, საერთო session store-ის გარეშე. მაგრამ სწორედ ეს statelessness არის კლასიკური ინტერვიუს ხაფანგი: token-ების გაუქმება ადვილად ვერ ხერხდება, payload იკითხება და `alg`-ის აღრევა ან ვადის შემოწმების არარსებობა რეალური მოწყვლადობებია. ზუსტად იმის ცოდნა, თუ რას იცავს ხელმოწერა და რას არა, აუცილებელია JWT-ების უსაფრთხოდ გამოსაყენებლად.

შენახვა	უპირატესობა	ნაკლი
`httpOnly` cookie	JS ვერ კითხულობს (XSS-ისგან უფრო უსაფრთხო)	სჭირდება CSRF დაცვა
`localStorage`	მარტივი, CSRF-ის გარეშე	ღიაა XSS-ისთვის

სტრუქტურა: სამი base64url ნაწილი

როგორ მუშაობს ხელმოწერა და გადამოწმება

რთული ნაწილი: გაუქმება (revocation)

შენახვის კომპრომისები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები