QA Road - QA инструменты

Варианты аутентификации: session vs token и что за зверь OAuth В посте про идентификацию/аутентификацию/авторизацию разобрали разницу понятий. Дальше логичный вопрос - как система "запоминает", что пользователь уже вошёл. Есть два принципиально разных подхода. 📌 Session-based Сессия - запись на сервере вида "пользователь 42 залогинен, роль admin". HTTP - протокол без памяти, сессия существует, чтобы это обойти. - Сервер создаёт запись у себя (база, Redis, в памяти процесса) и выдаёт клиенту только её идентификатор, обычно в cookie - При каждом запросе сервер берёт ID из cookie и ищет запись в своём хранилище - Плюс - доступ можно отозвать мгновенно, удалив запись на сервере - Минус - нужно общее хранилище сессий для всех инстансов, что усложняет масштабирование 📌 Token-based - Сервер не хранит состояние - вся информация закодирована в самом токене (JWT), подписанном при выдаче - Проверка - сервер пересчитывает подпись тем же ключом и сравнивает с той, что в токене, без похода в базу - Плюс - легко масштабируется, любой сервис проверяет токен самостоятельно - Минус - токен нельзя отозвать мгновенно без deny-list, пока не истечёт срок - для баланса безопасности и удобства используют короткий access token плюс refresh token с ротацией, разбирали в прошлом посте Session-based обычно выбирают для веба в один домен, token-based - для API, мобильных приложений и микросервисов и ситуаций, где фронтенд и бэкенд живут на разных доменах. 🔴 OAuth 2.0: делегирование доступа, а не аутентификация OAuth - это "разреши приложению X действовать от твоего имени в Y", без передачи пароля третьей стороне. Grant type - сценарий, которым приложение доказывает серверу авторизации право на токен. 📌 Authorization Code - для реальных пользователей Пример - "Войти через Google" на Spotify: пользователь логинится у Google и подтверждает доступ, Google возвращает Spotify authorization code через редирект, Spotify на своём сервере обменивает code плюс client_secret на access token. Та же схема у GitHub, Apple ID, корпоративного SSO. Обязательно применяется с PKCE - клиент передаёт хешированный секрет заранее и раскрывает его только при обмене code на токен, поэтому перехваченный код бесполезен без него. 📌 Client Credentials - без пользователя Для связи между сервисами, где человека физически нет - например, ночной cron-скрипт, синхронизирующий данные между внутренними сервисами. Клиент авторизуется своим ID и secret, токен представляет само приложение. 🌿Ловушки для QA 1. Logout при session-based - запись должна удаляться на сервере, а не только cookie на клиенте 2. Logout при token-based - без deny-list или короткого TTL токен валиден до истечения даже после выхода 3. В OAuth-флоу проверь строгую валидацию redirect_uri - иначе возможна кража code через открытый редирект 4. Client Credentials не должен давать доступ к данным пользователя - токен представляет только приложение 5. При смешении сессий и токенов проверь согласованную инвалидацию при смене пароля или блокировке 6. Authorization code должен быть одноразовым - повтор должен быть отклонён Поставь 🔥, если полезно