С какими видами авторизации WEB есть опыт

Мой опыт с видами авторизации в WEB‑приложениях

За более чем 10 лет работы в QA я сталкивался с широким спектром механизмов веб-авторизации и аутентификации. Их корректная работа — критически важный аспект безопасности и пользовательского опыта, поэтому их тестирование всегда было в фокусе моей работы. Я разделю свой опыт на ключевые категории.

1. Авторизация на основе сессий (Session‑Based)

Это классический подход, где состояние аутентификации пользователя хранится на сервере.

• Механизм: Пользователь вводит логин/пароль, сервер создает уникальный идентификатор сессии (Session ID), который передается клиенту (чаще в куках (Cookies)). Все последующие запросы клиента содержат этот ID для проверки.
• Мой опыт тестирования:

    *   Проверка создания, валидации и уничтожения сессии (логин, логаут, timeout).
    *   Тестирование безопасности: попытки перехвата или подбора **Session ID**, проверка кук на флаги `HttpOnly`, `Secure`, `SameSite`.
    *   Анализ поведения при одновременных сессиях с одного аккаунта.
    *   Проверка корректности хранения сессий на сервере (in‑memory, Redis, БД).

// Пример проверки куки сессии в автоматизированном тесте (Playwright)
const sessionCookie = await context.cookies();
const targetCookie = sessionCookie.find(c => c.name === 'SESSION_ID');
// Проверяем важные атрибуты
expect(targetCookie.httpOnly).toBe(true);
expect(targetCookie.secure).toBe(true);

2. Токен‑ориентированная авторизация

Современный подход, часто используемый в SPA (Single Page Applications) и мобильных бэкендах.

• JSON Web Tokens (JWT): Наиболее распространенный стандарт. Сервер выдает подписанный токен после успешного входа. Клиент хранит его (часто в localStorage или в памяти) и отправляет в заголовке Authorization: Bearer <token>.

    *   **Опыт тестирования:**
        *   Проверка структуры JWT (header, payload, signature) через декодеры (например, на [jwt.io](https://jwt.io)).
        *   Валидация срока жизни токена (`exp` claim), механизмов **refresh token**.
        *   Тестирование на уязвимости: использование просроченных или модифицированных токенов, проверка алгоритма подписи.
        *   Анализ рисков хранения в `localStorage` (уязвимость к XSS).

# Пример отправки запроса с JWT в автотесте (Python, requests)
import requests
headers = {'Authorization': 'Bearer eyJhbGciOiJIUzI1NiIs...'}
response = requests.get('https://api.example.com/protected', headers=headers)
# Проверяем, что доступ разрешен
assert response.status_code == 200

• OAuth 2.0 / OpenID Connect: Используется для делегированного доступа и социального входа (через Google, GitHub, Facebook и т.д.).

    *   **Опыт тестирования:**
        *   Тестирование различных **grant types**: Authorization Code (для веб-приложений), Implicit (устаревший), Client Credentials (для M2M), Resource Owner Password Credentials (не рекомендуется).
        *   Работа с **редиректами (callback URLs)**, проверка параметров `state` (защита от CSRF) и `code`.
        *   Тестирование сценариев отказа пользователя предоставить права, отзыва доступа (`/revoke`).
        *   Проверка корректного получения и использования **id_token** в рамках OpenID Connect.

3. HTTP Basic и Digest‑авторизация

Простые встроенные протоколы, реже используемые в современных пользовательских веб-приложениях, но встречающиеся в API или админ-панелях.

• HTTP Basic: Логин и пароль кодируются в Base64 и передаются в заголовке Authorization: Basic <credentials>. ОЧЕНЬ НЕБЕЗОПАСНО без HTTPS.

    *   **Опыт:** Тестирование на передачу по незащищенному каналу, проверка кодирования/декодирования.

• HTTP Digest: Более безопасная альтернатива, использующая хеши (MD5). Опыт тестирования включал проверку корректности nonce и ответов на challenge.

4. Авторизация на основе API‑ключей

Часто используется для доступа к публичным API или для сервис‑сервисного взаимодействия.

• Механизм: Уникальный ключ передается в заголовке запроса (например, X-API-Key) или как параметр URL (менее безопасно).
• Опыт тестирования:

    *   Проверка генерации, ротации и отзыва ключей.
    *   Тестирование ограничений по квотам и частоте запросов (**rate limiting**), привязанных к ключу.
    *   Валидация доступа на уровне разных **scopes** или прав, связанных с ключом.

5. Многофакторная аутентификация (MFA / 2FA)

Дополнительный слой безопасности, часто комбинируемый с любым из вышеперечисленных методов.

• Опыт тестирования:

    *   Сценарии с **TOTP** (Time‑based One‑time Password, например, через Google Authenticator): активация, резервные коды, восстановление доступа.
    *   Тестирование отправки кодов по **SMS** или **email** (проверка задержек, повторной отправки, валидности кода).
    *   Тестирование **аппаратных ключей** безопасности (WebAuthn/FIDO2) – пока что на уровне интеграционного тестирования с эмуляцией.
    *   Проверка сценариев "заблокированной учетной записи" после N неудачных попыток ввода кода.

Ключевые аспекты моего подхода к тестированию авторизации:

1. Безопасность: Всегда выхожу за рамки "счастливого пути". Использую инструменты (Burp Suite, OWASP ZAP) для анализа трафика, проверки на IDOR, CSRF, инъекции в токены.
2. Интеграционное тестирование: Глубоко тестирую точки интеграции с OAuth-провайдерами (эмуляция различных ответов от Google/Facebook API).
3. Автоматизация: Пишу автотесты для регрессионной проверки критических сценариев логина/логаута, истечения токенов, используя как UI, так и API‑уровень.
4. Документация и спецификация: Внимательно изучаю OpenAPI Spec (Swagger) или аналоги для понимания ожидаемых заголовков, кодов ответов (401 Unauthorized, 403 Forbidden) и схемы ошибок.

Таким образом, мой опыт охватывает как устаревшие, так и современные протоколы, с постоянным акцентом на безопасность, надежность и удобство для конечного пользователя. Понимание внутренних механизмов каждого вида авторизации позволяет мне проектировать эффективные, целостные и разрушающие тесты.