Авторизация и контроль доступа (RBAC)
Решаем, что аутентифицированному пользователю разрешено делать
- точно сформулировать разницу между аутентификацией и авторизацией;
- моделировать доступ через роли и более детальные разрешения;
- защищать маршруты Express переиспользуемым middleware авторизации;
- обеспечивать владение, чтобы пользователи трогали только свои ресурсы;
- выбирать между доступом на основе сессий/cookie и токенов и понимать их компромиссы.
1. Аутентификация против авторизации
Эти два слова постоянно путают, потому что они стоят рядом в конвейере запроса, но отвечают на разные вопросы:
- Аутентификация (authN) -- кто вы? Пользователь подтверждает свою личность, обычно паролем, и получает сессию или JWT. Предыдущая тема, Аутентификация с JWT, полностью посвящена этому шагу.
- Авторизация (authZ) -- что вам разрешено делать? Зная личность, сервер решает, допустим ли этот запрос.
Полезная модель: аутентификация происходит один раз за сессию (при входе), а авторизация -- при каждом защищённом запросе. Действительный токен -- это билет, доказывающий, кто им владеет; это не пропуск за кулисы в каждую комнату. У каждой двери контролёр всё равно проверяет, даёт ли ваш билет вход именно сюда.
Аналогия. Представьте отель. Стойка регистрации аутентифицирует вас: подтверждает бронь и выдаёт ключ-карту. Эта карта открывает не все двери. Когда вы прикладываете её к номеру 412, замок авторизует вас -- проверяет, разрешено ли именно этой карте пройти именно через эту дверь. Спортзал и бассейн могут открываться для всех; служебный коридор остаётся закрытым. Одна карта, разные решения у каждой двери.
Почему разделение важно. Смешение этих двух понятий порождает классическую уязвимость: маршрут проверяет, что токен действителен, и на этом останавливается, полагая, что действительный пользователь -- это разрешённый пользователь. Это нарушенный контроль доступа -- многие годы номер один в OWASP Top Ten. Проверка личности и проверка разрешения -- это два отдельных барьера, и оба должны быть закрыты.