Developer

Аутентификация и авторизация: в чём разница

↑ 1.3 Аутентификация и безопасность API · → Следующая

Обязательно~5 мин чтенияУровень: junior

Зачем это аналитику и PM

В баге «нет доступа» смешивают две разные поломки: система не узнала человека и система узнала, но запретила действие. Пока это не различено, чинят токен вместо роли или наоборот.

План темы

  • кто вы и что вам можно
  • роли и права
  • 401 и 403

Объяснение

Аутентификация отвечает на вопрос «кто это». Авторизация отвечает на вопрос «что этому субъекту можно». Оба шага нужны почти каждому API, но ломаются по-разному и чинятся разными людьми.

Как проходная и кабинет. На проходной сверяют пропуск: это аутентификация. В кабинете бухгалтерии пропуск уже принят, но чужие ведомости всё равно не выдают: это авторизация. Пропуск не заменяет допуск к шкафу.

Кто вы

Субъект — человек, сервис или ключ интеграции. Система сопоставляет предъявленное (пароль, ключ, токен) с учётной записью. Если предъявить нечего или срок истёк, разговор заканчивается до проверки прав. В требованиях этот шаг называют отдельно: «гость не вошёл» и «сотрудник вошёл» — разные экраны.

Что можно

После узнавания смотрят правила. Роль — именованный набор, например «аналитик» или «администратор заказов». Право — одно действие: прочитать заказ, отменить, выгрузить. У двух людей с одной ролью права обычно совпадают, но конкретный заказ может быть запрещён и роли: это уже правило на ресурс, «только свои клиенты». Как у вас устроены роли, не выдумывают по названию кнопки. Список берёт владелец сервиса.

flowchart TD
    A["Пришёл запрос"] --> B{"Субъект узнан"}
    B -->|"нет"| C["Отказ 401"]
    B -->|"да"| D{"Действие разрешено"}
    D -->|"нет"| E["Отказ 403"]
    D -->|"да"| F["Выполняют операцию"]

Коды 401 и 403

401 значит: не доказали, кто вы, или сессия кончилась. Имеет смысл войти снова или обновить токен. 403 значит: вас узнали, операцию делать нельзя. Повторный вход ту же роль не расширит. Английское имя 401 Unauthorized легко прочитать как «нет прав». В баге пишут число. Часть API прячет чужой ресурс за 404, чтобы не подтверждать, что он есть. Это политика, её надо знать до приёмки, а не считать дефектом справочника.

СитуацияЧто проверялиТипичный код
Нет токена или он просроченАутентификация401
Токен живой, роль не таАвторизация403
Чужой объект скрытПолитика команды403 или 404
Вошли и действие разрешеноОба шага2xx

Примеры

Схема двух отказов на учебном хосте. Это не ответ вашего сервера.

GET /orders/1042 HTTP/1.1
Host: api.example.com

Без заголовка допуска ожидайте отказ «не узнали», часто 401. Тот же путь с маской Authorization: Bearer eyJ... и ролью без права на чужой заказ — уже спор про авторизацию, часто 403.

Нюансы и подводные камни

  • Одна роль на макете не равна матрице прав. В задаче лучше таблица «роль и действие», чем слово «доступ есть».
  • Сервис, который ходит в API сам, тоже субъект. У него свои права, не права человека, который нажал кнопку.
  • Успешный вход не значит, что все методы открыты. Список заказов и выгрузка персональных данных часто разведены.
  • 401 на одном стенде и 200 на другом при том же пользователе — сначала сравните, куда выдан токен.

Практика

Для действий «смотреть свой заказ» и «отменять чужой» напишите, какой отказ получит гость без входа и какой — вошедший аналитик без права отмены.

Ожидаемый результат: у гостя отказ на шаге «кто вы», у аналитика на чужой отмене отказ на шаге «что можно». Коды либо взяты из контракта вашей команды, либо помечены вопросом, а не угаданы.

Вопросы с ответами

Связано с блоком Developer

Связанные темы

Вид графа

Обратные ссылки