Аутентификация и авторизация — в чём разница, и почему 401 это не 403

Смотри, какая штука: сервер различает две ситуации, которые новичку кажутся одной.

Ошибка 401 значит «я не знаю, кто ты». Ошибка 403 — «я знаю, кто ты. И именно поэтому — нельзя». Вторая звучит куда обиднее.

За этими двумя ошибками стоят два разных слова, которые вечно путают: аутентификация и авторизация. Разложим по полочкам — и ты перестанешь путать их навсегда.

Два вопроса вместо одного

Аутентификация отвечает на вопрос «кто ты?». Это проверка личности: пароль, код из письма, вход через Google. Сервер убеждается, что ты — это ты.

Авторизация отвечает на вопрос «что тебе можно?». Это проверка прав: можешь ли ты открыть эту страницу, удалить эту запись, увидеть эти данные.

Лучшая аналогия — аэропорт. Паспортный контроль — аутентификация: сверили лицо с документом, убедились в личности. Но паспорт не пускает тебя в бизнес-зал: туда нужен подходящий билет. Проверка билета — авторизация. Паспорт настоящий, а в бизнес — нельзя. Знакомое чувство 403.

Таблица: в чём разница

| Критерий | Аутентификация | Авторизация | |---|---|---| | Вопрос | Кто ты? | Что тебе можно? | | Когда происходит | Один раз, при входе | При каждом действии | | Чем делается | Пароль, код из письма, OAuth | Роли и правила доступа | | Код ошибки | 401 | 403 | | Пример отказа | «Неверный пароль» | «У тебя нет прав на эту страницу» |

Порядок всегда один: сначала аутентификация, потом авторизация. Нельзя решить, что человеку можно, пока не знаешь, кто он.

Почему это две разные работы

Вот момент, ради которого стоило читать: сделал вход в приложение — сделал только половину работы.

Классическая дырка новичка выглядит так. Вход есть, всё честно: без пароля не пустят. Но страница профиля открывается по адресу /profile/42 — и вошедший пользователь меняет в адресе 42 на 43. Открывается чужой профиль.

Аутентификация тут работает идеально: сервер точно знает, кто перед ним. Просто никто не написал правило «пользователь видит только своё». Это провал авторизации — и такие дыры страшнее слабых паролей: их не видно, пока кто-то не попробует.

Проверяй это в своих проектах первым делом: войди и поменяй чужой id в адресе. Если открылось — у тебя дыра.

Забавная деталь: иногда вместо честного 403 сервер отвечает 404 — «такого не существует». Так делает GitHub с приватными репозиториями: даже подтверждать, что чужой репозиторий есть, — уже утечка. Авторизация может прятать сам факт существования данных.

Кому что настраивать

Развилка простая, и ответ у неё несимметричный.

Аутентификацию не пиши руками. Хранить пароли, слать коды, обновлять сессии — задача с сотней подводных камней, и её давно решили за тебя. Бери готовое: Supabase Auth, Firebase Auth, вход через Google. Под капотом тебе выдадут JWT или cookie-сессию — и это нормально не писать самому.

Авторизацию за тебя не сделает никто. Правила «кто что видит» — это логика твоего продукта: заметка видна только автору, статья — всем, админка — только тебе. Готовая библиотека не знает твоих правил. В базах вроде Supabase для этого есть Row Level Security — правило прямо на таблице: «отдавай строки только их владельцу». Одна строчка политики закрывает ту самую дырку с чужим профилем.

Почему 401 называется Unauthorized, если это про аутентификацию?

Историческая путаница в названии: код придумали раньше, чем термины устоялись. Фактически 401 значит «не аутентифицирован» — сервер не знает, кто ты, и предлагает представиться. Для «знаю, но нельзя» есть 403 Forbidden.

JWT — это аутентификация или авторизация?

Сам по себе — ни то, ни другое: это контейнер. Токен подтверждает, кто ты (аутентификация), и может нести твою роль внутри. Но решать, что этой роли можно, — всё равно работа сервера при каждом запросе.