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

Два термина, которые постоянно путают, хотя различие между ними простое:

• Аутентификация — установление личности. Отвечает на вопрос «кто вы?».
• Авторизация — определение прав. Отвечает на вопрос «что вам разрешено?».

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

Аутентификация: подтверждение личности

Это первый рубеж. Пользователь заявляет, кто он, и предоставляет доказательство: пароль, одноразовый код, отпечаток пальца, криптографическую подпись устройства.

Система сверяет доказательство с тем, что ей известно, и принимает решение: признать личность или отказать.

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

Способы различаются надёжностью:

Способ	Надёжность	Комментарий
Пароль	Низкая	Воспроизводим, утекает, повторно используется
Пароль + код из приложения	Средняя	Устойчив к утечке базы, уязвим к фишингу
Passkey, аппаратный ключ	Высокая	Привязан к домену, фишинг не работает
Сертификат устройства	Высокая	Для машин и служебных интеграций

Авторизация: определение границ

После того как личность установлена, вступает второй процесс: что этому пользователю позволено.

Решение принимается на основании:

• ролей — что положено человеку в его должности;
• атрибутов — отдел, уровень допуска, тип устройства;
• контекста — время, местоположение, состояние устройства.

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

Сравнение

Критерий	Аутентификация	Авторизация
Вопрос	Кто вы?	Что вам можно?
Когда	В начале сессии	При каждом действии
На чём основана	Учётные данные, факторы	Роли, атрибуты, политики
Что предотвращает	Вход под чужим именем	Выход за пределы полномочий
Где выполняется	У провайдера идентичности	В приложении и у провайдера
Результат	Сессия или токен	Разрешение или отказ

Почему путаница опасна

Смешение понятий приводит к вполне конкретным уязвимостям.

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

Права проверяются на клиенте. Кнопка удаления скрыта в интерфейсе, но сам запрос никто не проверяет. Скрыть элемент — не то же самое, что запретить действие.

Используют OAuth как способ входа. OAuth отвечает за делегирование доступа, а не за установление личности. Приложение узнаёт, что кто-то выдал разрешение, но не может достоверно сказать, кто это. Для входа нужен OIDC, добавляющий ID-токен.

Права выдаются навсегда. Авторизация должна учитывать изменения: сотрудник сменил отдел или уволился — права обязаны измениться, а активные сессии могут потребовать отзыва.

Как это устроено в Keydee

Оба процесса разделены явно.

Аутентификация выполняется на стороне Keydee: пароль, одноразовый код TOTP или passkey — в зависимости от политики компании. Приложения не хранят паролей и не проверяют их сами.

Авторизация опирается на роли внутри организации. Права приезжают в токене, приложение проверяет их при каждом запросе. Дополнительно проверяется принадлежность к организации: токен, выданный для одной компании, не действует в другой.

Изменения применяются немедленно. Смена ролей отражается в новых токенах, а завершение сессии прекращает доступ, не дожидаясь истечения срока действия токена.

Оба процесса журналируются: и входы, и изменения прав фиксируются с указанием реального IP-адреса.

Короткий вывод

Аутентификация без авторизации даёт систему, где вошедший может всё. Авторизация без надёжной аутентификации бессмысленна: права выдаются неизвестно кому.

Работают они только вместе — и проверять нужно оба этапа, а не один.