Аутентификация vs авторизация: ключевые отличия

аутентификация проверяет кто вы, авторизация — что вам разрешено делать; это разные слои безопасности

Почему это важно: путаница между AuthN и AuthZ — источник серьёзных уязвимостей. Неправильная модель ведёт к утечкам данных и несанкционированному доступу

Главная идея

AuthN = идентификация (логин+пароль, токен); AuthZ = проверка прав (этот пользователь может редактировать этот ресурс?)

Как это выглядит на практике

Пользователь вводит email+пароль — сервер проверяет credentials (AuthN).
Сервер создаёт сессию или токен — подтверждение идентичности.
Пользователь делает DELETE /posts/42 — сервер проверяет, является ли он автором поста (AuthZ).
403 Forbidden = успешная аутентификация, но нет прав. 401 Unauthorized = не аутентифицирован.

Что происходит под капотом

401 Unauthorized — на самом деле означает 'не аутентифицирован'; название исторически неточное.
403 Forbidden — аутентифицирован, но нет прав. Важно различать для правильной обработки ошибок.
Stateful auth: состояние хранится на сервере (сессия в БД/Redis). Stateless: состояние в токене (JWT).
Middleware pipeline: AuthN middleware → AuthZ middleware → controller action.

Типичные ошибки и заблуждения

Ошибка: авторизованный пользователь может всё. Авторизация — это всегда проверка конкретного действия над конкретным ресурсом.
Ошибка: 401 = нет прав. 401 = не вошёл в систему. 403 = вошёл, но нет доступа.
Ошибка: аутентификация через OAuth = авторизация. OAuth — это делегирование авторизации, но используется для аутентификации (OpenID Connect).
Ошибка: проверка прав только на фронтенде достаточна. Авторизация всегда проверяется на сервере — фронтенд не доверенная среда.

Ключевые выводы

AuthN: кто вы? AuthZ: что вам разрешено?
401 = не аутентифицирован, 403 = нет прав.
Авторизация проверяется на сервере при каждом запросе.
Stateful (сессии) vs Stateless (JWT) — разные компромиссы.

Термины урока

Authentication (AuthN): процесс проверки идентичности пользователя.

Authorization (AuthZ): проверка прав на выполнение действия.

401 Unauthorized: запрос без валидных credentials.

403 Forbidden: аутентифицирован, но действие запрещено.

Middleware: промежуточный обработчик запроса в pipeline сервера.

Связь с работой backend-разработчика

Каждый API-эндпоинт должен явно проходить оба слоя: 1) кто этот пользователь? (AuthN) 2) может ли он делать это действие с этим ресурсом? (AuthZ). Пропуск любого из них — уязвимость.

Мини-разбор реальной ситуации

API позволяет любому аутентифицированному пользователю редактировать профиль по ID: PUT /users/42. Разработчик проверил, что пользователь залогинен (AuthN), но не проверил, что он редактирует свой профиль (AuthZ). Результат — IDOR-уязвимость (Insecure Direct Object Reference), один из топ-10 OWASP.

Что запомнить

AuthN = кто вы, AuthZ = что вам можно.
Всегда проверяй оба слоя на сервере.
401 vs 403: важное семантическое различие для клиентов API.

Итог

Разделение аутентификации и авторизации — фундамент безопасной архитектуры. Проектируйте их как отдельные независимые механизмы.