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

Проект ЦИТадель

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

План. Раздел 1 разводит аутентификацию, авторизацию и идентификацию. Раздел 2 описывает три фактора аутентификации. Раздел 3 посвящён хранению и политике паролей, раздел 4 — многофакторности и passkey. Раздел 5 разбирает сессии и токены, раздел 6 — делегирование доступа через OAuth и вход через OIDC. В разделе 7 рассматриваются модели прав и типичные ошибки авторизации, в разделе 8 — практические задания.

1. Три разных вопроса

За одним словом «вход» часто скрываются три разные операции:

• Идентификация — заявление «я использую эту учётную запись»: логин, адрес электронной почты или иной идентификатор. Само заявление ничего не доказывает.
• Аутентификация — проверка одного или нескольких средств аутентификации, привязанных к записи: пароля, ключа, одноразового кода. Она подтверждает контроль над ними, но не обязательно юридическую личность человека.
• Авторизация — решение, разрешено ли субъекту выполнить указанное действие над указанным ресурсом в данном контексте. Для защищённых операций его принимают на каждом запросе. Некоторые правила применяются и к неаутентифицированному посетителю, например разрешение читать публичный документ.

Опасная уязвимость возникает на границе второго и третьего вопросов: система установила учётную запись, но не проверила право на запрошенный объект. Если замена номера заказа 17 на 18 открывает чужой заказ, механизм входа мог сработать правильно; отсутствует объектная авторизация. Разделы 2–6 посвящены средствам входа и сессии, раздел 7 — правилам доступа.

2. Три фактора

Средства аутентификации обычно относят к трём факторам:

• Знание — то, что субъект знает: пароль или PIN. Знание можно скопировать, выманить и незаметно использовать повторно.
• Владение — то, чем субъект управляет: аппаратный ключ, устройство с криптографическим ключом или генератором кодов. Средство можно украсть или использовать через удалённый доступ, а экспортируемый программный секрет — скопировать, поэтому одного факта его существования недостаточно.
• Неотъемлемое свойство — биометрический признак, например отпечаток или лицо. Биометрия не является секретом и плохо поддаётся замене после утечки. Часто она локально активирует ключ на устройстве: сервер получает криптографическое доказательство, а не изображение отпечатка. Если система собирает биометрические шаблоны централизованно, ей нужны отдельные меры защиты и правовые основания.

Многофакторность требует разных и достаточно независимых факторов. Два пароля остаются одним фактором. Пароль и код с устройства относятся к разным факторам, но их общая процедура восстановления или вредоносная программа на одном телефоне может свести защиту к одной точке отказа. «Контрольные вопросы» тоже проверяют знание, причём ответы на них нередко публичны или угадываются.

3. Пароли: хранить, готовясь к утечке

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

Каждый пароль получает уникальную случайную соль. Она не обязана быть секретной: её задача — не позволить одной заранее вычисленной таблицей проверять множество записей и не раскрывать одинаковые пароли по одинаковым результатам. Соль не мешает атакующему перебирать конкретную запись, поэтому стоимость функции должна быть заметной для перебора, но приемлемой для сервера. Быстрые функции общего назначения, включая SHA-256 без специальной схемы, для этого не подходят. Необходимые алгоритмы и форматы берут из проверенной библиотеки, как объясняет статья «Криптография с полки».

Политика ввода должна помогать выбирать длинные уникальные пароли: разрешать не менее 64 символов, пробелы, вставку и менеджеры паролей; для пароля как единственного фактора разумный современный минимум — 15 символов. Проверяют весь ввод по списку распространённых и скомпрометированных значений, но не требуют произвольной смеси классов символов и не заставляют менять пароль по календарю без признаков компрометации. Ограничение частоты попыток защищает онлайн-вход, а многофакторность уменьшает последствия кражи пароля. Эти меры дополняют, но не заменяют безопасное хранение.

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

4. Второй фактор и passkey

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

СМС-код лучше одного пароля, когда более сильный вариант недоступен, но зависит от телефонной сети, переноса номера и восстановления учётной записи. TOTP-код не передаётся по СМС, однако его можно выманить; общий секрет генератора иногда копируется при переносе или синхронизации. Для критичных действий предпочтительна фишингостойкая аутентификация на основе WebAuthn: аппаратный ключ или passkey.

Passkey — учётные данные на основе пары ключей. Проверяющий сервис хранит открытый ключ, а закрытый используется аутентификатором и не передаётся этому сервису. Подпись привязана к идентификатору сайта, поэтому корректно реализованный WebAuthn не выдаёт пригодное доказательство поддельному домену. Утечка базы открытых ключей не позволяет войти вместо пользователя. Однако остаются другие цели атаки: активная сессия, устройство, учётная запись синхронизации и процедура восстановления. Для синхронизируемых passkey нужно отдельно оценить защиту провайдера и восстановление доступа. Биометрия или PIN при этом обычно лишь локально разрешают аутентификатору использовать ключ.

5. Сессии и токены: как система помнит вход

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

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

Самодостаточный токен. Подписанный токен содержит утверждения о субъекте, получателе, сроке и других условиях, поэтому сервис может проверить его локально. Подпись обеспечивает целостность, но обычно не скрывает содержимое. Для выборочного немедленного отзыва вводят список отзыва, интроспекцию или версию сессии; смена ключа отзывает сразу группу токенов. Эти способы возвращают состояние, добавляют сетевой запрос либо расширяют область отзыва. Поэтому токены доступа делают короткоживущими, а долгоживущий механизм обновления защищают отдельно и часто ротируют после использования.

Для браузерной сессии обычно используют cookie с атрибутами Secure, HttpOnly и подходящим SameSite, передаваемую только по TLS. После входа, выхода, смены пароля и других чувствительных событий сервер должен корректно обновлять или завершать сессию. HttpOnly мешает скрипту прочитать cookie, но не мешает вредоносному скрипту выполнять запросы от имени пользователя; SameSite тоже не заменяет полноценную защиту от CSRF. Эти границы подробнее разобраны в статье «Веб-безопасность для разработчика».

6. Делегирование и вход: OAuth и OIDC

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

Токен доступа может содержать сведения о субъекте, но сам факт его выдачи не является для клиента надёжным протоколом входа пользователя. Для федеративной аутентификации служит OpenID Connect (OIDC). Он добавляет ID Token и правила, по которым клиент проверяет подпись, издателя, аудиторию, срок и связь ответа со своим запросом. ID Token предназначен клиенту; токен доступа — API. Использование одного не по назначению другого стирает границы получателя и назначения.

Для нового интерактивного клиента обычно применяют поток кода авторизации с PKCE, точным сопоставлением разрешённых адресов перенаправления и защитой связи запроса с ответом при помощи state и, в OIDC, nonce. Запрашивают минимальные области доступа, токены доступа делают короткоживущими, а токены обновления ротируют или криптографически привязывают к клиенту. Детали протокола и проверки не следует собирать вручную: нужна поддерживаемая библиотека и актуальные рекомендации безопасности.

7. Авторизация: модели прав и где рвётся

Каждый аутентифицированный запрос связывают с действующей сессией, а затем принимают решение об авторизации. Модель по ролям (RBAC) назначает разрешения администраторам, редакторам и читателям. Модель по атрибутам (ABAC) учитывает свойства субъекта, ресурса, действия и контекста. Модель по отношениям (ReBAC) выводит право из связей: владелец документа, участник проекта, член родительской группы. Выбирают наименее сложную модель, которая точно выражает реальные правила; излишняя гибкость затрудняет проверку и аудит.

Независимо от модели действуют три правила:

• Проверять на доверенной стороне. Скрытая кнопка улучшает интерфейс, но не запрещает запрос. Сервер или иной доверенный исполнитель проверяет каждое защищённое действие; клиентские данные о роли не принимаются без проверки.
• Проверять политику для конкретного объекта и действия. Недостаточно установить факт входа или даже общую роль. Нужно учесть организацию, владельца, отношения, состояние объекта и запрошенную операцию. Непредсказуемый идентификатор затрудняет перебор, но не заменяет эту проверку.
• Запрещать по умолчанию. Доступ появляется только из явного разрешения. Новый маршрут, метод или тип объекта без правила остаётся закрытым. Решение полезно принимать единообразно и журналировать так, чтобы отказ можно было расследовать без утечки чувствительных данных.

8. Практикум

Проводите задания на локальном стенде или в системе, которую вам разрешено проверять. Используйте вымышленные пароли, отдельные тестовые учётные записи и данные без ценности; не пытайтесь получить доступ к объектам реальных пользователей.

Задание 1. Сравнить функции хранения. Готовой библиотекой вычислите SHA-256 и Argon2id для вымышленного значения и сравните время одного вычисления. Подберите параметры Argon2id под допустимое время входа на стенде и запишите их вместе с результатом. Объясните, почему параметры нужно хранить и со временем повышать.

Задание 2. Проверить роль соли. Получите результаты для двух одинаковых тестовых паролей сначала с одной солью, затем с двумя независимо созданными солями. Объясните, какие сведения скрывает уникальная соль, почему она может храниться открыто и почему не останавливает перебор отдельной записи.

Задание 3. Сравнить отзыв. В учебном приложении создайте серверную сессию и короткоживущий самодостаточный токен. Реализуйте «выйти со всех устройств» для обоих вариантов: удаление сессий и, например, проверку версии входа либо список отзыва для токена. Сравните задержку, состояние и последствия недоступности хранилища.

Задание 4. Проверить объектную авторизацию. Создайте на стенде две учётные записи и по одному объекту для каждой. Составьте тесты чтения, изменения и удаления чужого объекта через API. Исправьте политику так, чтобы разрешённые действия выполнялись, запрещённые возвращали одинаковый безопасный отказ, а решение было видно в журнале.

Задание 5. Исследовать жизненный цикл cookie. В инструментах разработчика проверьте Secure, HttpOnly, SameSite, область действия и срок cookie учебной сессии. Убедитесь, что идентификатор меняется после входа, перестаёт работать после выхода и истекает по заданным правилам. Отдельно запишите, от каких последствий XSS и CSRF эти атрибуты не защищают.

Задание 6*. Разобрать OIDC-поток. На схеме потока кода авторизации укажите клиента, сервер авторизации, сервер ресурса, браузер, код, ID Token и токен доступа. Для каждого значения запишите отправителя, получателя и обязательные проверки. Покажите на схеме, почему токен доступа нельзя без дополнительного протокола принять как удостоверение входа в клиент.

Итоги

• Идентификация заявляет учётную запись, аутентификация подтверждает контроль над привязанным средством, авторизация проверяет конкретное действие над ресурсом. Это разные решения.
• Многофакторность сочетает достаточно независимые знание, владение или неотъемлемое свойство. Общий слабый канал восстановления может свести несколько факторов к одному.
• Пароли хранят как проверочные значения специализированной медленной функции с уникальной солью. Политика поощряет длину и менеджеры паролей, блокирует известные слабые значения и не навязывает бессмысленную периодическую смену.
• СМС и TOTP уменьшают риск, но поддаются фишингу. WebAuthn и passkey привязывают доказательство к сайту; при этом защита устройства, синхронизации, восстановления и сессии остаётся необходимой.
• Серверную сессию легко отозвать выборочно; локально проверяемый токен требует дополнительного механизма отзыва. Оба являются секретами предъявителя и нуждаются в TLS, ограниченном сроке и безопасном жизненном цикле.
• OAuth делегирует доступ, OIDC добавляет протокол аутентификации. Клиент обязан проверять назначение каждого токена и все параметры ответа.
• Авторизацию выполняют на доверенной стороне для каждого объекта и действия, запрещают доступ по умолчанию и проверяют правила автоматическими тестами.

Литература

1. NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management — требования к паролям, факторам, фишингостойкости и сессиям.
2. OWASP Cheat Sheet Series: Password Storage, Authentication, Session Management и Authorization.
3. W3C, Web Authentication: Level 3 — модель аутентификаторов, учётных данных и проверяющей стороны.
4. IETF RFC 9700, Best Current Practice for OAuth 2.0 Security.
5. OpenID Foundation, OpenID Connect Core 1.0 — протокол аутентификации и проверки ID Token.
6. Связанные статьи проекта: «Модель угроз», «Криптография с полки», «HTTP/2 и HTTP/3», «TLS» и «Веб-безопасность для разработчика».