Объясните механизм: почему подтверждённая личность клиента не означает, что API должен разрешить ему запрошенное действие?
Аутентификация подтверждает, кто выполняет запрос, а авторизация определяет, разрешено ли этому субъекту конкретное действие над конкретным ресурсом. Успешный вход или проверка токена доказывают личность клиента, но не дают автоматического права читать, изменять или удалять любые данные.
API должно отдельно проверить оба условия: подлинность субъекта и соответствие операции назначенным ему полномочиям. Иначе любой успешно вошедший пользователь сможет получить доступ к чужим ресурсам или выполнить административное действие.
В ранних системах проверка доступа часто была тесно связана с самим фактом входа пользователя. По мере появления многопользовательских приложений, распределённых сервисов и разных категорий клиентов стало необходимо разделить подтверждение личности и принятие решения о доступе.
Такое разделение решает две разные задачи. Аутентификация отвечает на вопрос «кто это?», а авторизация — «что этому субъекту разрешено в данном контексте?». Разделение позволяет менять правила доступа без изменения механизма входа и применять единые политики к пользователям, сервисам и другим субъектам.
Предположим, клиент успешно предъявил действительный токен. В токене может быть указано, что запрос выполняет пользователь, сервис или представитель определённой группы, но этого недостаточно для доступа к любому ресурсу.
Если API ограничится проверкой токена, возникнут типичные риски:
Неверное решение опасно не только утечкой данных. Избыточные права позволяют ошибочному или скомпрометированному клиенту менять состояние системы за пределами его ответственности.
Сначала API проверяет аутентификационные данные: например, подпись и срок действия токена, его издателя, аудиторию и допустимый тип субъекта. Результатом является установленная идентичность, но не окончательное разрешение операции.
Затем выполняется авторизация. Она учитывает субъект, действие, целевой ресурс и контекст запроса. В зависимости от модели проверяться могут роль пользователя (RBAC), атрибуты субъекта и ресурса (ABAC), принадлежность ресурса пользователю, состояние процесса, организационная область или ограничения по времени.
Например, право изменить документ может зависеть не только от роли редактора, но и от того, принадлежит ли документ его подразделению и находится ли он в статусе, допускающем редактирование. Поэтому проверку прав нельзя сводить к наличию одного общего признака вроде «пользователь вошёл в систему».
Решение о доступе должно приниматься на сервере, рядом с защищаемой операцией. Скрытие кнопки в интерфейсе улучшает удобство, но не является защитой: клиент может сформировать запрос самостоятельно.
Важно различать отказ в аутентификации и отказ в авторизации. Если субъект не доказал свою личность или его учётные данные недействительны, запрос не аутентифицирован; если личность подтверждена, но действие запрещено, запрос аутентифицирован, однако доступ к операции не предоставляется.
Выбор модели зависит от системы. RBAC проще объяснять и администрировать, но при большом числе исключений роли разрастаются. ABAC лучше выражает контекстные правила, однако требует качественных атрибутов, централизованного управления политиками и более сложного аудита.
Следует отдельно определить жизненный цикл полномочий: как быстро отзывать доступ, что происходит с уже выданными токенами, как фиксировать решения и как не допустить подмены идентификатора ресурса в запросе. Проверка права должна использовать фактически загруженный ресурс или надёжно сопоставлять его с субъектом, а не доверять идентификаторам, присланным клиентом.
В системе управления договорами пользователь успешно вошёл в приложение и получил действительный токен. При этом один пользователь может редактировать договоры своего подразделения, руководитель — утверждать их, а сервис архивирования — только переводить договоры в архив после завершения срока хранения.
Рассматривались два варианта. Первый — считать наличие действительного токена достаточным условием: он прост, но открывает лишние операции и не учитывает владельца договора. Второй — задать права только ролями: он понятнее, однако плохо описывает ограничение «только документы своего подразделения» и специальные переходы состояний.
Выбран комбинированный подход: роли определяют набор допустимых действий, а серверная политика дополнительно проверяет подразделение, владельца ресурса и текущий статус договора. В результате один и тот же механизм входа используется всеми клиентами, но каждый запрос получает отдельное решение о доступе; попытка изменить чужой договор блокируется даже при наличии действительного токена.
1. Достаточно ли проверить роль, записанную в токене, чтобы принять решение о доступе?
Нет, не всегда. Роль в токене может устареть после увольнения, изменения должности или отзыва полномочий, а сама роль не обязательно учитывает ресурс и контекст операции.
Нужно определить допустимую задержку отзыва прав и способ её контроля: короткоживущие токены, проверка актуальности сессии, централизованная политика или отзыв токена. Кроме роли, серверу может потребоваться проверить принадлежность ресурса, организационную область и текущий статус объекта.
2. Почему проверка владельца ресурса должна выполняться на сервере, даже если клиент уже передал идентификатор пользователя?
Потому что данные клиента недоверенны. Клиент может заменить идентификатор владельца или идентификатор ресурса и попытаться получить доступ к чужому объекту.
Сервер должен сам определить субъект по результату аутентификации и сопоставить его с владельцем фактически найденного ресурса. Проверка должна быть частью защищённой операции, чтобы между проверкой и изменением состояния не возникло возможности использовать другой объект.
3. Всегда ли запрет доступа означает, что нужно скрыть существование ресурса?
Нет. Иногда достаточно сообщить, что действие запрещено, если субъект имеет право знать о существовании ресурса. В других случаях раскрытие самого факта существования объекта создаёт утечку, поэтому для неразрешённого субъекта применяют ответ, не отличающий отсутствие ресурса от отсутствия доступа.
Выбор зависит от модели угроз и бизнес-правил. Например, для закрытых медицинских или кадровых данных важно не позволить по различиям ответов выяснить, существует ли запись; для внутренней системы поддержки может быть полезно явно сообщить о недостатке полномочий.