Варианты аутентификации: 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 должен быть одноразовым - повтор должен быть отклонён


Поставь 🔥, если полезно