Что такое аутентификация: способы и принципы
Аутентификация подтверждает личность пользователя перед выдачей доступа. Разбираем факторы, способы, протоколы и практики построения надёжного входа.
Аутентификация — процесс подтверждения того, что пользователь, устройство или сервис действительно являются теми, кем себя объявляют.
Это первый рубеж любой системы безопасности. Всё, что выстроено дальше — права, политики, журналирование — теряет смысл, если на вход можно попасть под чужим именем.
Как это устроено
Механика одинакова независимо от способа:
- Заявление личности — пользователь сообщает, кто он: логин, адрес почты, идентификатор.
- Предъявление доказательства — пароль, одноразовый код, подпись устройства, биометрия.
- Проверка — система сверяет доказательство с тем, что ей известно.
- Выдача подтверждения — при успехе создаётся сессия или выпускается токен, действующий ограниченное время.
Дальше вступает авторизация, которая определяет, что этому пользователю позволено. Это уже другой процесс.
Категории факторов
| Категория | Что это | Примеры |
|---|---|---|
| Знание | То, что помнят | Пароль, PIN-код |
| Владение | То, чем обладают | Телефон, аппаратный ключ, приложение-аутентификатор |
| Свойство | То, чем являются | Отпечаток пальца, черты лица |
| Контекст | Обстоятельства входа | Устройство, местоположение, время |
Надёжность даёт не количество проверок, а независимость факторов. Пароль и контрольный вопрос относятся к одной категории, поэтому их сочетание защищает слабо: утечка базы раскрывает оба.
Способы аутентификации
Пароль
Самый распространённый и самый слабый способ. Проблема не в длине и не в сложности, а в природе пароля: он воспроизводим и передаваем. Узнав его, злоумышленник пользуется им откуда угодно, а владелец об этом не знает.
Требования сложности и регулярной смены дают меньше, чем принято считать: они провоцируют предсказуемые схемы и запись паролей на бумаге.
Многофакторная аутентификация
Добавление второго фактора поверх пароля. Утечка пароля перестаёт быть достаточной для входа.
Способы различаются устойчивостью: коды из приложения защищают от утечки базы, но не от фишинга; passkeys защищают и от того, и от другого.
Беспарольный вход
Пароль убирается совсем, вместо него — криптографический ключ на устройстве, разблокируемый биометрией или PIN-кодом. Закрытый ключ не покидает устройство, поэтому красть на стороне сервиса нечего.
Единый вход
Не самостоятельный способ, а схема: аутентификация выполняется один раз у провайдера идентичности, а приложения доверяют результату. Позволяет внедрить надёжный способ проверки один раз для всех систем.
Сертификаты
Применяются для машин и служебных интеграций, где нет человека, способного ввести пароль. Устройство доказывает владение закрытым ключом.
Протоколы
Термины часто смешивают, хотя они относятся к разным задачам:
| Назначение | Протоколы |
|---|---|
| Аутентификация и федерация | OpenID Connect, SAML, Kerberos, FIDO2/WebAuthn |
| Делегирование доступа | OAuth 2.0 |
| Синхронизация учётных записей | SCIM |
| Доступ к каталогу | LDAP |
Частая ошибка — использовать OAuth 2.0 как способ входа. Он отвечает за выдачу прав приложению, но не устанавливает личность пользователя. Для входа предназначен OpenID Connect, который добавляет к OAuth ID-токен.
Практики надёжного входа
Второй фактор обязателен для администраторов. Учётные записи с расширенными правами — главная цель атак.
Предпочитайте способы, устойчивые к фишингу. Passkeys и аппаратные ключи привязаны к адресу сайта, поэтому поддельная страница не сможет их использовать. Коды из приложения такой защиты не дают.
Ограничивайте время жизни сессий. Бессрочная сессия означает бессрочный доступ для того, кто получил устройство.
Обеспечьте отзыв. Возможность немедленно завершить сессию — минимальное средство реагирования на инцидент. Без неё остаётся только менять пароль и надеяться.
Наблюдайте за журналом. Серии неудачных попыток, входы из необычных мест, обращения в нерабочее время — это сигналы, которые видны только при наличии журнала.
Используйте готовые протоколы. Самописная аутентификация почти всегда содержит ошибки, которых нет в проверенных реализациях.
Продумайте аварийный доступ. Административная учётная запись на случай отказа основного механизма должна существовать — и находиться под особым контролем.
Как это устроено в Keydee
- Способы входа: пароль, одноразовые коды TOTP, passkeys.
- Требование второго фактора задаётся политикой компании и действует во всех её приложениях.
- Приложения не хранят паролей — проверка выполняется на стороне Keydee, приложения получают токен.
- Управление сессиями: активные сессии видны, любую можно завершить, доступ прекращается сразу.
- Уведомление приложений о выходе — подключённые приложения закрывают сессию у себя.
- Журнал входов с фиксацией реального IP-адреса пользователя.
Главное
Аутентификация определяет, кто вошёл. Всё остальное в системе безопасности опирается на этот ответ.
Если он получен ненадёжным способом — самая тщательная ролевая модель защищает не того, кого предполагалось.
Покажем платформу на вашем сценарии за 30 минут
Никаких длинных презентаций. Покажем, как KeyDee работает именно для вашего продукта — и ответим на все технические вопросы.
Свяжемся в течение 2 часов · Размещение данных в РФ · ФЗ-152