Стратегії автентифікації

Короткий зміст

У цій лекції розглядається огляд існуючих підходів до автентифікації у веб-застосунках:

• Session-based (Stateful) — автентифікація на основі серверних сесій з використанням cookies, зберігання стану на сервері (Redis, БД)
• Token-based (Stateless) — автентифікація за допомогою JWT токенів, відсутність серверного стану, передача токена у заголовку Authorization
• OAuth 2.0 — делегована авторизація через сторонні провайдери (Google, GitHub, Facebook), потоки авторизації
• Single Sign-On (SSO) — єдиний вхід для корпоративних застосунків через SAML або OpenID Connect

Вивчається порівняльний аналіз кожного підходу з точки зору безпеки, масштабованості та складності реалізації. Розглядаються критерії вибору стратегії залежно від вимог проєкту: розмір системи, необхідність горизонтального масштабування, вимоги до безпеки, підтримка мобільних клієнтів.

Фундаментальна дихотомія: Stateful vs Stateless

Вибір стратегії автентифікації визначається фундаментальним архітектурним рішенням — де система зберігатиме стан сесії користувача (session state). Це рішення впливає на масштабованість, безпеку, складність інфраструктури та можливості горизонтального розширення системи.

Stateful автентифікація (автентифікація зі збереженням стану) означає, що після успішного входу сервер створює запис сесії у своїй пам'яті або у зовнішньому сховищі (Redis, PostgreSQL) і присвоює їй унікальний ідентифікатор — session ID. Цей ідентифікатор передається клієнту у вигляді cookie, і кожен наступний запит від браузера автоматично включає цей cookie. Сервер отримує session ID, шукає відповідну сесію у сховищі і витягує з неї дані користувача — ідентифікатор, ролі, час останньої активності.

Stateless автентифікація (автентифікація без збереження стану) означає, що сервер не зберігає жодної інформації про активні сесії користувачів. Замість цього після успішного входу сервер генерує токен (token) — підписану структуру даних, що містить ідентифікатор користувача, ролі, час видачі та час закінчення терміну дії. Цей токен передається клієнту, який зберігає його локально (у localStorage, sessionStorage або cookie) і відправляє у заголовку Authorization кожного запиту. Сервер перевіряє підпис токена, витягує дані користувача безпосередньо з токена і не звертається до бази даних чи Redis для пошуку сесії.

Діаграма архітектурних підходів

Розглянемо візуальне порівняння двох підходів у момент обробки запиту від автентифікованого користувача:

graph LR
    subgraph "Stateful (Session-Based)"
        A1[Client] -->|Cookie: sessionId=abc123| B1[Server]
        B1 -->|Пошук сесії| C1[(Redis/Database)]
        C1 -->|userId, roles| B1
        B1 -->|200 OK| A1
    end
    
    subgraph "Stateless (Token-Based)"
        A2[Client] -->|Authorization: Bearer JWT| B2[Server]
        B2 -->|Перевірка підпису| B2
        B2 -->|Декодування payload| B2
        B2 -->|200 OK| A2
    end
    
    style A1 fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style A2 fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style B1 fill:#8b5cf6,stroke:#6d28d9,color:#ffffff
    style B2 fill:#8b5cf6,stroke:#6d28d9,color:#ffffff
    style C1 fill:#10b981,stroke:#047857,color:#ffffff

Ключова відмінність: у stateful підході сервер залежить від зовнішнього сховища для отримання даних користувача, тоді як у stateless підході сервер самодостатній — йому достатньо перевірити підпис токена за допомогою свого секретного ключа.

Session-Based автентифікація (Stateful)

Session-based автентифікація є історично першим та інтуїтивно зрозумілим підходом, що виник разом із динамічними веб-застосунками у середині 1990-х років. Цей підхід природно поєднується з механізмом HTTP cookies, вбудованим у всі сучасні браузери.

Життєвий цикл сесії

Розглянемо покрокову послідовність створення, використання та знищення сесії у типовому веб-застосунку:

// Спрощений приклад генерації session ID
import { randomBytes } from 'crypto';

function generateSessionId(): string {
  return randomBytes(32).toString('hex'); // 64 символи у hex форматі
}

const sessionId = generateSessionId();
// Приклад: "a3f5c8e2d9b1f4e7a6c3d8e9f2b5a7c4..."

// Структура даних сесії
interface Session {
  sessionId: string;
  userId: string;
  email: string;
  roles: string[];
  createdAt: Date;
  expiresAt: Date;
  lastActivityAt: Date;
  ipAddress: string;
  userAgent: string;
}

await redis.setex(
  `session:${sessionId}`,
  3600, // TTL 1 година
  JSON.stringify({
    userId: user.id,
    email: user.email,
    roles: user.roles,
  })
);

response.cookie('sessionId', sessionId, {
  httpOnly: true,    // Захист від XSS — cookie недоступне через JavaScript
  secure: true,      // Передача лише через HTTPS
  sameSite: 'lax',   // Захист від CSRF атак
  maxAge: 3600000,   // 1 година у мілісекундах
  path: '/',         // Cookie діє для всього сайту
});

GET /api/v1/users/profile HTTP/1.1
Host: example.com
Cookie: sessionId=a3f5c8e2d9b1f4e7a6c3d8e9f2b5a7c4...

await redis.expire(`session:${sessionId}`, 3600); // Продовжити TTL на 1 годину

await redis.del(`session:${sessionId}`);
response.clearCookie('sessionId');

Переваги session-based автентифікації

Недоліки та архітектурні обмеження

Token-Based автентифікація (Stateless)

Token-based автентифікація набула популярності з розвитком Single Page Applications (SPA) та мобільних застосунків, де традиційний механізм cookies виявився обтяжливим. Найпоширенішим форматом токенів є JSON Web Token (JWT) — стандарт RFC 7519, що визначає компактний та самодостатній формат для безпечної передачі claims між сторонами.

Архітектура JWT токенів

JWT токен складається з трьох частин, розділених крапками:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1NTBlODQwMCIsImVtYWlsIjoiaXZhbkBleGFtcGxlLmNvbSIsInJvbGVzIjpbInVzZXIiXSwiaWF0IjoxNjkzNTY0ODAwLCJleHAiOjE2OTM1Njg0MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Структура токена:

1. Header (Заголовок): містить тип токена (JWT) та алгоритм підпису (HS256, RS256, ES256).
2. Payload (Корисне навантаження): містить claims — дані про користувача, ролі, час видачі та закінчення.
3. Signature (Підпис): криптографічний підпис перших двох частин, що гарантує цілісність та автентичність токена.

Кожна частина кодується у Base64URL (модифікація Base64 для безпечного використання у URL).

Життєвий цикл JWT автентифікації

import { sign } from 'jsonwebtoken';

const accessToken = sign(
  {
    sub: user.id,              // Subject — ідентифікатор користувача
    email: user.email,
    roles: user.roles,
    iat: Math.floor(Date.now() / 1000),  // Issued At — час видачі
  },
  process.env.JWT_SECRET,      // Секретний ключ для підпису
  {
    expiresIn: '15m',          // Токен діє 15 хвилин
    algorithm: 'HS256',        // Алгоритм підпису HMAC SHA-256
  }
);

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "tokenType": "Bearer",
  "expiresIn": 900
}

// Збереження токена після логіну
localStorage.setItem('accessToken', response.accessToken);

// Витягування токена для наступних запитів
const token = localStorage.getItem('accessToken');

const response = await fetch('https://api.example.com/users/profile', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json',
  },
});

import { verify } from 'jsonwebtoken';

try {
  const payload = verify(token, process.env.JWT_SECRET, {
    algorithms: ['HS256'],
  });
  
  // Токен дійсний — дані користувача доступні у payload
  const userId = payload.sub;
  const roles = payload.roles;
  
} catch (error) {
  // Токен недійсний, застарів або підроблений
  throw new UnauthorizedException('Invalid token');
}

Переваги token-based автентифікації

Недоліки та ризики безпеки

OAuth 2.0: Делегована авторизація

OAuth 2.0 — це не стратегія автентифікації у традиційному розумінні, а протокол делегованої авторизації (delegated authorization). Він дозволяє користувачеві надати стороннім застосункам обмежений доступ до своїх ресурсів на іншому сервісі без розкриття паролю. Найпоширеніший приклад — кнопка «Увійти через Google» або «Увійти через GitHub».

Концептуальна модель OAuth 2.0

Уявіть ситуацію: ви хочете дозволити сервісу друку фотографій (третя сторона) отримати доступ до ваших фотографій у хмарному сховищі (власник ресурсу — Google Drive). Традиційний підхід вимагав би, щоб ви повідомили сервісу друку свій пароль від Google. Це створює величезні ризики:

• Сервіс отримує повний доступ до вашого облікового запису, а не лише до фотографій.
• Ви не можете відкликати доступ без зміни паролю (що вплине на всі інші застосунки).
• Сервіс може зберігати ваш пароль у незахищеному вигляді.

OAuth 2.0 вирішує цю проблему через токени доступу з обмеженою областю видимості (scoped access tokens). Замість паролю сервіс друку отримує токен, що дозволяє лише читати фотографії (scope: read:photos), але не змінювати налаштування облікового запису або читати електронну пошту.

Учасники протоколу

OAuth 2.0 визначає чотири ключові ролі:

Потік авторизації Authorization Code (найбезпечніший)

Розглянемо покроковий процес входу користувача через Google у ваш веб-застосунок:

https://accounts.google.com/o/oauth2/v2/auth?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/auth/callback&
  response_type=code&
  scope=openid%20email%20profile&
  state=random_string_for_csrf_protection

Застосунок "YourApp" запитує дозвіл на:
✓ Перегляд вашої електронної пошти
✓ Перегляд основної інформації профілю

https://yourapp.com/auth/callback?
  code=4/0AX4XfWh...authorization_code...&
  state=random_string_for_csrf_protection

const response = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    code: authorizationCode,
    client_id: process.env.GOOGLE_CLIENT_ID,
    client_secret: process.env.GOOGLE_CLIENT_SECRET, // Секрет!
    redirect_uri: 'https://yourapp.com/auth/callback',
    grant_type: 'authorization_code',
  }),
});

const tokens = await response.json();
/*
{
  "access_token": "ya29.a0AfH6...",
  "expires_in": 3600,
  "refresh_token": "1//0gFz...",
  "scope": "openid email profile",
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIs..." // JWT з даними користувача
}
*/

const profileResponse = await fetch('https://www.googleapis.com/oauth2/v2/userinfo', {
  headers: { 'Authorization': `Bearer ${tokens.access_token}` },
});

const profile = await profileResponse.json();
/*
{
  "id": "1234567890",
  "email": "user@example.com",
  "verified_email": true,
  "name": "Іван Петренко",
  "picture": "https://lh3.googleusercontent.com/..."
}
*/

Коли використовувати OAuth 2.0

OAuth 2.0 є оптимальним вибором у наступних сценаріях:

• Інтеграція з соціальними мережами: «Увійти через Google/Facebook/GitHub» для спрощення реєстрації.
• Доступ до сторонніх API: ваш застосунок потребує читати дані користувача з іншого сервісу (Google Drive, Dropbox, Spotify).
• Мікросервісна архітектура: делегування автентифікації центральному Identity Provider замість дублювання логіки у кожному сервісі.
• Mobile та Desktop застосунки: OAuth 2.0 має спеціальні потоки для нативних застосунків (PKCE — Proof Key for Code Exchange).

Single Sign-On (SSO): Єдиний вхід для корпоративних систем

Single Sign-On (SSO) — це архітектурний патерн, що дозволяє користувачеві автентифікуватися один раз у центральній системі і отримати доступ до множини пов'язаних застосунків без повторного введення облікових даних. SSO є стандартом де-facto у корпоративних середовищах, де співробітники працюють з десятками внутрішніх сервісів.

Переваги SSO для організацій

Протоколи SSO: SAML 2.0 vs OpenID Connect

Існують два основні протоколи для реалізації SSO:

SAML 2.0 (Security Assertion Markup Language) — застарілий, але широко використовуваний у корпоративному середовищі XML-базований протокол. Підтримується великими enterprise системами (Microsoft Active Directory, Okta, Ping Identity). Складний у налаштуванні, але перевірений часом.

OpenID Connect (OIDC) — сучасне розширення OAuth 2.0, що використовує JSON та REST API замість XML. Простіший у реалізації, краще підходить для веб-застосунків та мобільних клієнтів. Підтримується Google Workspace, Microsoft Azure AD, Auth0.

Архітектура SSO на основі OIDC

sequenceDiagram
    participant U as User
    participant A1 as App 1
    participant A2 as App 2
    participant IdP as Identity Provider<br/>(Auth0, Okta)
    
    U->>A1: Спроба доступу
    A1->>IdP: Перенаправлення на /authorize
    IdP->>U: Форма входу (login + password)
    U->>IdP: Облікові дані
    IdP->>IdP: Створення SSO сесії
    IdP->>A1: Authorization code
    A1->>IdP: Обмін code на tokens
    IdP->>A1: id_token + access_token
    A1->>U: Доступ надано
    
    Note over U,IdP: Користувач вже автентифікований у IdP
    
    U->>A2: Спроба доступу до іншого застосунку
    A2->>IdP: Перенаправлення на /authorize
    IdP->>IdP: Виявлено активну SSO сесію
    IdP->>A2: Authorization code (без запиту паролю!)
    A2->>IdP: Обмін code на tokens
    IdP->>A2: id_token + access_token
    A2->>U: Доступ надано автоматично
    
    style U fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style IdP fill:#8b5cf6,stroke:#6d28d9,color:#ffffff
    style A1 fill:#10b981,stroke:#047857,color:#ffffff
    style A2 fill:#10b981,stroke:#047857,color:#ffffff

Ключовий момент: Identity Provider зберігає власну SSO сесію (зазвичай у cookie sso_session з терміном дії 8–12 годин). Коли користувач намагається увійти у другий застосунок, IdP виявляє активну сесію та автоматично видає authorization code без повторного запиту паролю.

Порівняльна таблиця стратегій

Для ефективного вибору стратегії автентифікації необхідно розуміти компроміси між безпекою, продуктивністю та складністю реалізації. Розглянемо систематичне порівняння підходів:

Критерії вибору стратегії для вашого проєкту

Вибір стратегії автентифікації залежить від архітектурних вимог, масштабу системи та команди розробників. Розглянемо практичні сценарії:

Сценарій 1: Малий монолітний застосунок (стартап MVP)

Вимоги:

• Команда 2–3 розробники, обмежений бюджет
• Очікувана аудиторія: 1000–10000 користувачів
• Традиційний веб-застосунок (server-side rendering)
• Немає планів на мобільні застосунки у найближчі 6 місяців

Рекомендація: Session-Based автентифікація

Обґрунтування:

• Простота реалізації — express-session або @nestjs/passport-local налаштовуються за 30 хвилин.
• Немає необхідності у складних бібліотеках JWT або конфігурації ключів.
• Для малої аудиторії Redis Cluster не потрібен — достатньо одного екземпляра Redis на виділеному сервері або керованого сервісу (AWS ElastiCache, Azure Redis).
• Природна інтеграція з браузерами через cookies.

// Мінімальна конфігурація у NestJS
import * as session from 'express-session';
import * as RedisStore from 'connect-redis';

app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true,
      secure: true,
      maxAge: 3600000, // 1 година
    },
  })
);

Сценарій 2: Single Page Application з планами на мобільні застосунки

Вимоги:

• React/Vue/Angular frontend, REST API backend
• Плани на iOS/Android застосунки через 3–6 місяців
• Очікувана аудиторія: 50000–500000 користувачів
• Необхідність горизонтального масштабування

Рекомендація: Token-Based (JWT) з Refresh Tokens

Обґрунтування:

• JWT токени працюють однаково у веб-браузерах та мобільних застосунках.
• Stateless архітектура дозволяє запускати десятки серверів без синхронізації стану.
• Короткоживучі access tokens (15 хвилин) + довгоживучі refresh tokens (7 днів) забезпечують баланс між безпекою та зручністю.
• Refresh tokens зберігаються у HttpOnly cookies або у захищеному сховищі мобільного застосунку (Keychain на iOS, Keystore на Android).

// Генерація пари токенів
const accessToken = sign({ sub: user.id, roles: user.roles }, JWT_SECRET, {
  expiresIn: '15m',
});

const refreshToken = sign({ sub: user.id }, REFRESH_SECRET, {
  expiresIn: '7d',
});

// Збереження refresh token у БД для можливості відкликання
await db.refreshTokens.create({
  token: hashSync(refreshToken, 10), // Зберігаємо хеш, не сам токен!
  userId: user.id,
  expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
});

Сценарій 3: Інтеграція з Google/Facebook для швидкої реєстрації

Вимоги:

• Зменшення тертя при реєстрації (conversion rate)
• Користувачі не хочуть запам'ятовувати ще один пароль
• Потрібен доступ до профілю Google/Facebook для персоналізації

Рекомендація: OAuth 2.0 + OIDC через Passport.js

Обґрунтування:

• Бібліотека Passport.js надає готові стратегії для десятків провайдерів (Google, Facebook, GitHub, Twitter).
• Користувач реєструється за 2 кліки без введення email/пароля.
• Ваш застосунок не зберігає паролі — це зменшує відповідальність за витоки даних.

// Налаштування Google OAuth у NestJS
import { PassportStrategy } from '@nestjs/passport';
import { Strategy, VerifyCallback } from 'passport-google-oauth20';

@Injectable()
export class GoogleStrategy extends PassportStrategy(Strategy, 'google') {
  constructor() {
    super({
      clientID: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
      callbackURL: 'https://yourapp.com/auth/google/callback',
      scope: ['email', 'profile'],
    });
  }

  async validate(
    accessToken: string,
    refreshToken: string,
    profile: any,
    done: VerifyCallback
  ): Promise<any> {
    const { id, emails, displayName, photos } = profile;
    
    // Знайти або створити користувача у вашій БД
    const user = await this.usersService.findOrCreateGoogleUser({
      googleId: id,
      email: emails[0].value,
      name: displayName,
      picture: photos[0].value,
    });
    
    done(null, user);
  }
}

Сценарій 4: Корпоративна система з десятками внутрішніх сервісів

Вимоги:

• 5000+ співробітників
• 20+ внутрішніх застосунків (CRM, ERP, HR, документообіг)
• Централізоване управління доступом
• Інтеграція з Active Directory або LDAP

Рекомендація: Single Sign-On через Okta, Auth0 або Azure AD

Обґрунтування:

• Співробітник входить один раз вранці через корпоративний логін.
• Адміністратори керують доступом централізовано — звільнення співробітника миттєво блокує доступ до всіх систем.
• Готові інтеграції з популярними enterprise системами (Salesforce, Jira, Confluence, Slack).
• Підтримка багатофакторної автентифікації (SMS, TOTP, push-нотифікації).

Інтерактивні запитання для самоперевірки

Ключові висновки

Рекомендовані ресурси для поглибленого вивчення

• RFC 6749 — OAuth 2.0 Authorization Framework: офіційна специфікація протоколу OAuth 2.0, що визначає потоки авторизації, ролі учасників та формати токенів.
• OpenID Connect Core 1.0: специфікація OIDC, що розширює OAuth 2.0 стандартизованою автентифікацією та id_token.
• OWASP Session Management Cheat Sheet: найкращі практики безпечної реалізації серверних сесій, налаштування cookies та захист від атак.
• JWT.io: інтерактивний інструмент для декодування, перевірки та створення JWT токенів з підтримкою різних алгоритмів підпису.
• Passport.js Documentation: бібліотека для Node.js з готовими стратегіями автентифікації (Local, JWT, Google, Facebook, GitHub тощо).