QA Interview Hub · База знань · Тести
API
Авторизація
JWT і тестування токенів
JWT складається з трьох частин через крапку: header (алгоритм і тип), payload (claims — дані користувача, ролі, час видачі і закінчення) та signature. Кожна частина закодована в Base64URL, тобто payload може прочитати будь-хто — він не зашифрований. Підпис гарантує, що токен не змінювали, і його перевіряє сервер секретним або публічним ключем.
Ключові claims: exp — час закінчення дії, iat — час видачі, sub — ідентифікатор користувача. Токен передається в заголовку Authorization: Bearer <token>. Зазвичай є короткоживучий access token і довший refresh token для отримання нового.
Тести: прострочений токен має повертати 401 — для цього беру старий токен або тестове середовище з коротким часом дії. Підроблений токен: змінюю роль у payload без перепідпису — сервер має відхилити через невалідний підпис. Також перевіряю алгоритм none, токен іншого середовища, порожній і обрізаний токен, а також інвалідацію токена після логауту та зміни пароля.
Типи авторизації в Postman
Авторизацію задають один раз на рівні колекції, а в запитах ставлять Inherit auth from parent. Публічним ендпоінтам, наприклад логіну, — No Auth.
| Тип | Як виглядає в запиті |
|---|
| Bearer Token | Authorization: Bearer <token> — найчастіше, токен зазвичай JWT |
| Basic Auth | Authorization: Basic base64(login:password) — це кодування, а не шифрування |
| API Key | Заголовок (x-api-key: ...) або query-параметр |
| OAuth 2.0 | Postman сам проходить флоу і отримує access token |
| Cookie | Сесійна cookie після логіну; керування через вкладку Cookies |
Важливий нюанс про Basic: base64 декодується за секунду, тому без HTTPS логін і пароль фактично передаються відкритим текстом. API Key у query-параметрі теж ризикований, бо URL потрапляє в логи серверів і проксі.
На співбесіді: Найчастіше це Bearer-токен, зазвичай JWT, який я задаю на рівні колекції, а запити наслідують авторизацію. Знаю також Basic, API Key, OAuth 2.0 і cookie-сесії, і пам'ятаю, що Basic — це кодування, а не шифрування.
Токен автоматично і що перевірити
Токен автоматично. У post-response скрипті запиту POST /auth/login зберегти токен у змінну, а в колекції вказати Bearer {{token}}:
pm.test('Login 200', () => pm.response.to.have.status(200));
const { accessToken } = pm.response.json();
pm.environment.set('token', accessToken);
Тепер достатньо один раз виконати логін, і всі запити колекції підхоплять свіжий токен. Для Runner і Newman логін ставлять першим запитом у колекції або отримують токен через pm.sendRequest у pre-request скрипті колекції.
Що перевірити:
- Без токена — 401.
- Зіпсований і прострочений токен — 401.
- Токен після logout — 401.
- Токен іншого користувача до чужого ресурсу — 403 або 404, але ніколи дані.
Останнє — IDOR, один з найнебезпечніших багів у фінтеху. Щоб його перевірити, мені потрібні два тестові користувачі: я створюю ресурс під першим, а потім звертаюся до нього з токеном другого. Якщо в відповіді чужий рахунок чи переказ — це критичний дефект.
На співбесіді: Я зберігаю токен після логіну через pm.environment.set і використовую {{token}} на рівні колекції. Потім перевіряю 401 без токена, з простроченим, зіпсованим і після logout, а також IDOR — доступ до чужого ресурсу з токеном іншого користувача.