Авторизация и аутентификация

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Инженеру

Авторизация и аутентификация

Play ITЗагрузка интерактивного демо…

Это одна из самых важных тем в прикладной безопасности: именно здесь решается, кто попадает в систему и какие действия может выполнять.

Для удобства чтения материал собран в практической последовательности:

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

В современных информационных системах управление доступом — неотъемлемый элемент архитектуры. Независимо от того, разрабатывается ли веб-приложение, мобильное приложение, корпоративная ERP-система или облачный микросервис, важно строго определять, кто пытается получить доступ к системе (аутентификация) и что ему разрешено делать (авторизация). Эти два процесса, хотя и тесно связаны, решают принципиально разные задачи и реализуются различными подходами, механизмами и протоколами.

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

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

Аутентификация — "Кто ты?"

Аутентификация — это первый и обязательный этап контроля доступа, в ходе которого система устанавливает и подтверждает подлинность субъекта, инициирующего взаимодействие. В отличие от простого распознавания (identification), где субъект лишь заявляет о своей принадлежности (например, вводит логин), аутентификация требует предоставления доказательств, которые могут быть независимо проверены и верифицированы доверяющей стороной. Без этого этапа любые последующие проверки — в том числе авторизация, аудит или учёт действий — теряют основание — невозможно определить, кому разрешено или запрещено действие, если неясно, кто его совершает.

С технической точки зрения, аутентификация — это контролируемый процесс, включающий:

сбор заявляемых данных (идентификатора);
запрос и приём доказательств подлинности (факторов);
их верификацию в соответствии с установленной политикой;
выдачу подтверждения (например, в виде сессионного идентификатора или токена), которое может использоваться в последующих взаимодействиях.

Центральным элементом этого процесса является концепция фактора подлинности — независимого класса доказательств, основанных на одном из трёх фундаментальных принципов:

знание (что-то, что субъект знает — пароль, секретный вопрос);
владение (что-то, что субъект имеет — аппаратный ключ, временный код, устройство с доверенным окружением);
существование (что-то, что субъект есть — биометрический шаблон, поведенческий паттерн).

Ни один из этих факторов в отдельности не является абсолютно надёжным — знания могут быть угаданы или украдены, владение — скомпрометировано или утеряно, биометрия — подделана или скопирована. Поэтому в системах с повышенными требованиями к безопасности применяется многофакторная аутентификация (MFA) — принцип, при котором принятие решения о подлинности требует предъявления доказательств из минимум двух разных классов. Такой подход не устраняет уязвимости отдельных факторов, но создаёт асинхронный барьер: для компрометации всей цепи злоумышленнику необходимо одновременно преодолеть несколько независимых защитных слоёв, что резко повышает стоимость и сложность атаки.

Реализация аутентификации варьируется в зависимости от требований к безопасности, удобству использования, инфраструктурной зрелости и регуляторных ограничений. На одном полюсе — простые, но уязвимые схемы, такие как парольная или базовая HTTP-аутентификация, пригодные лишь для низкорисковых или изолированных сред; на другом — криптографически строгие протоколы вроде FIDO2/WebAuthn или сертификатная аутентификация по X.509, обеспечивающие высокий уровень доверия за счёт аппаратной привязки и отсутствия передачи секретов по сети.

Современные системы всё чаще отказываются от "самописной" аутентификации в пользу стандартизованных протоколов и готовых решений, поскольку даже незначительные ошибки в реализации (некорректное хэширование, отсутствие rate limiting, утечка сессионного идентификатора) могут привести к полному компрометированию учётных записей. При этом важно понимать: выбор протокола (OAuth 2.0, OpenID Connect, SAML) или платформы (Keycloak, Auth0, Entra ID) — это архитектурное решение, определяющее, как будет построена идентификационная основа всей системы — от интерфейса входа до интеграции с внешними сервисами и аудита событий безопасности.

Аутентификация — это процесс подтверждения личности пользователя или субъекта, пытающегося получить доступ к системе. Этот этап всегда предшествует авторизации и отвечает на вопрос: "Кто ты?".

В основе аутентификации лежит проверка одного или нескольких факторов подлинности:

Что-то, что вы знаете (например, пароль, PIN-код);
Что-то, что у вас есть (например, аппаратный токен, смартфон с приложением Google Authenticator);
Что-то, что вы являетесь (биометрические данные — отпечаток пальца, лицо, голос).

Сочетание двух и более факторов называется многофакторной аутентификацией (MFA). Она значительно повышает уровень безопасности, поскольку компрометация одного фактора (например, утечка пароля) не приводит к полному доступу злоумышленника.

Виды аутентификации

Парольная аутентификация
Наиболее распространённый, но наименее защищённый метод. Основан на проверке пары логин/пароль. Без дополнительных мер (хэширование с солью, ограничение попыток, MFA) уязвима к брутфорсу, фишингу и утечкам баз данных.
Базовая аутентификация (Basic Authentication)
Реализуется передачей логина и пароля в заголовке HTTP-запроса в закодированном виде (Base64). Не рекомендуется в чистом виде без шифрования TLS, так как данные легко декодируются. Используется в тестовых средах или внутренних API с ограничениями трафика.
Биометрическая аутентификация
Основана на уникальных физиологических или поведенческих характеристиках. Требует надёжного хранения шаблонов и защиты от подмены (например, фото вместо лица). Применяется в мобильных устройствах, системах физического доступа.
Сертификатная аутентификация
Использует X.509-сертификаты для подтверждения подлинности клиента. Применяется в корпоративных и высоконадёжных системах, где требуется строгая идентификация без участия пользователя.
Токен-ориентированная аутентификация
Использует криптографически подписанные токены (например, JWT) для передачи идентификатора пользователя и его атрибутов. Подробно рассматривается в разделе о JWT.
Протокольная аутентификация
Включает такие стандарты, как:
- OAuth 2.0: в первую очередь предназначен для делегирования доступа, но часто используется и для аутентификации (через OpenID Connect).
- OpenID Connect (OIDC): надстройка над OAuth 2.0, специально созданная для аутентификации. Позволяет использовать внешние провайдеры (Google, Microsoft и др.).
- SAML (Security Assertion Markup Language): XML-стандарт для единого входа (SSO), широко применяемый в корпоративных средах.
- Kerberos / NTLM: протоколы, используемые в Windows-доменах для аутентификации в закрытых сетях.

Готовые решения

Для сокращения времени разработки и повышения уровня безопасности рекомендуется использовать проверенные платформы:

Auth0 — облачный Identity-as-a-Service (IDaaS) с поддержкой множества протоколов.
Firebase Authentication — простая интеграция для веб- и мобильных приложений с поддержкой социальных провайдеров.
Keycloak — open-source решение с поддержкой OAuth 2.0, OIDC, SAML, ролевой модели и расширенной настройки.
Azure Active Directory (Entra ID) — корпоративное решение Microsoft, интегрируемое с Office 365, Windows и Azure-сервисами.
Okta — коммерческая платформа с мощным UI, жизненным циклом пользователей и MFA.

Авторизация — "Что тебе разрешено?"

В информационных системах принцип наименьших привилегий (Principle of Least Privilege) предполагает, что любой субъект — будь то человек, программный агент или устройство — должен обладать ровно тем объёмом прав, который необходим и достаточен для выполнения его текущей задачи, и ни более того. Реализация этого принципа невозможна без чёткого разделения двух фундаментальных процессов — аутентификации — установления идентичности субъекта, и авторизации — определения, какие действия этот субъект уполномочен совершать в отношении конкретных ресурсов системы.

Если аутентификация отвечает на вопрос "Кто ты?", то авторизация отвечает на "Что тебе разрешено?". Это самостоятельный, логически и временно последующий этап контроля доступа, выполняемый только после успешного подтверждения подлинности субъекта. Без верифицированной идентичности любая проверка прав теряет смысл: нельзя разрешать или запрещать действия лицу, чья принадлежность не установлена.

С точки зрения архитектуры, авторизация — это процесс принятия решения о допустимости операции на основе трёх компонентов:

субъекта (subject) — того, кто инициирует запрос;
объекта (object) — того, к чему запрашивается доступ (файл, API-метод, настройка, данные);
действия (action) — того, что субъект намерен сделать с объектом (чтение, запись, исполнение, удаление).

Это решение принимается в рамках так называемой модели управления доступом (Access Control Model) — формализованной схемы, определяющей, каким образом права субъектов связываются с объектами и как интерпретируются условия доступа. Выбор модели критически влияет на выразительную мощность, гибкость, производительность и управляемость системы. Некоторые модели ориентированы на простоту и масштабируемость (например, в корпоративных приложениях), другие — на тонкую настройку под динамические и контекстно-зависимые сценарии (например, в облачных или регулируемых средах, где требуется соответствие GDPR, HIPAA или ФЗ-152).

Важно понимать, что авторизация — это динамический процесс, в котором могут участвовать как предварительно рассчитанные правила (например, назначенные роли), так и условия, вычисляемые в момент запроса (например, геопозиция клиента или состояние MFA). Поэтому современные системы всё чаще комбинируют несколько подходов: базовый уровень — RBAC для упрощения администрирования, дополненный атрибутивными и политико-ориентированными проверками для реализации сложных сценариев.

Если аутентификация отвечает на вопрос "Кто ты?", то авторизация отвечает на "Что тебе разрешено?". Это процесс проверки прав доступа субъекта (пользователя, сервиса, устройства) к объекту (файлу, API-эндпоинту, функции).

Авторизация выполняется после успешной аутентификации. Без подтверждённой личности проверка прав не имеет смысла.

Модели управления доступом

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

RBAC (Role-Based Access Control)
Доступ определяется через роли. Пользователь назначается одной или несколькими ролями, а каждой роли присваивается набор разрешений (permissions).
Пример: Роль admin может удалять пользователей, роль user — только просматривать профиль.
ABAC (Attribute-Based Access Control)
Доступ определяется на основе атрибутов — пользователя (отдел, должность), ресурса (категория, владелец), среды (время суток, геолокация, IP-адрес).
Пример: Пользователь из отдела "Финансы" имеет доступ к документу "Бюджет", если время запроса — в рабочие часы и IP принадлежит корпоративной сети.
PBAC (Policy-Based Access Control)
Более обобщённый подход, где доступ управляется политиками — логическими правилами, которые могут включать условия из ABAC, временные ограничения, контекст устройства и т.п.
Пример: "Доступ к административной панели разрешён только с доверенного устройства и только при включённой 2FA".
ACL (Access Control List)
Классический подход — у каждого ресурса есть список, где указано, какие субъекты имеют к нему доступ и с какими правами. Гибок, но трудно масштабируем при большом числе пользователей и ресурсов.

Механизмы авторизации

Списки разрешений (Permissions)
Минимальная единица контроля доступа. Например — read:documents, write:users, delete:posts. Комбинируются в роли или политики.
Делегирование доступа
Пользователь может временно передавать свои права другому субъекту (например, через OAuth). Это особенно важно в SaaS-системах и интеграциях.
Сессии и токены
После аутентификации система должна каким-то образом помнить, что пользователь уже прошёл проверку. Это реализуется через:
- Сессии (сервер хранит состояние в памяти или БД, клиент получает session ID в cookie);
- Токены (клиент хранит состояние, сервер проверяет подпись и содержимое токена — stateless подход).

JSON Web Tokens (JWT)

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), предназначенный для компактной и безопасной передачи утверждений (claims) между двумя сторонами. JWT часто используется как механизм аутентификации и авторизации в stateless-приложениях, особенно в RESTful API и микросервисных архитектурах.

В современных распределённых системах, где клиенты и серверы взаимодействуют по протоколу HTTP — изначально stateless-протоколу, — возникает фундаментальная задача — как идентифицировать запросы, принадлежащие одному и тому же субъекту (пользователю, системе или сервису), при отсутствии встроенного механизма сохранения состояния между обращениями. Традиционно для решения этой задачи использовались серверные сессии — при аутентификации сервер создавал запись состояния (например, в памяти или базе данных), а клиенту выдавал идентификатор сессии (обычно в виде cookie), по которому сервер при каждом последующем запросе извлекал контекст. Такой подход, несмотря на простоту, обладает рядом ограничений: необходимость хранения и синхронизации состояния усложняет горизонтальное масштабирование, повышает потребление ресурсов и вносит дополнительные задержки при обработке запроса.

В ответ на эти вызовы был разработан альтернативный подход — stateless-аутентификация, в основе которой лежит идея передачи всего необходимого контекста непосредственно в теле запроса, без сохранения состояния на стороне сервера. Именно в этом контексте и появился JSON Web Token (JWT) — открытый, JSON-ориентированный стандарт, формализованный в документе RFC 7519, предназначенный для компактного, самодостаточного и проверяемого представления утверждений (claims) между двумя и более доверяющими друг другу сторонами.

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

содержимое токена не было изменено после генерации;
токен был выдан именно этим сервером (или доверенным удостоверяющим центром);
срок действия токена не истёк;
утверждения, содержащиеся в нём, соответствуют политике доступа.

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

Ключевая особенность JWT — его самодостаточность. В отличие от идентификатора сессии, который требует обращения к внешнему хранилищу для получения контекста, JWT содержит в себе и метаданные (в заголовке), и полезную нагрузку (в теле), и механизм проверки подлинности (в подписи). Это позволяет каждому получателю токена — будь то основной API-шлюз, микросервис или сторонний партнёр — независимо валидировать и интерпретировать его содержимое, не прибегая к централизованному хранилищу. Такая автономность особенно ценна в архитектурах, ориентированных на микросервисы, API-first-подход и федерацию идентификации (например, OpenID Connect), где минимизация межкомпонентных зависимостей и задержек критична для производительности и отказоустойчивости.

Важно подчеркнуть, что JWT — это чётко структурированный объект, следующий строгим правилам кодирования и композиции. Его структура состоит из трёх сегментов, каждый из которых имеет своё функциональное назначение и формат представления, а именно: заголовок (header), полезная нагрузка (payload) и подпись (signature). Эти компоненты, последовательно закодированные в URL-safe Base64Url и объединённые символом точки (.), образуют компактную, транспортно-нейтральную строку, пригодную для передачи в HTTP-заголовках, URL-параметрах или теле запроса. Ни одна из частей не является опциональной в подписанном JWT (JWS — JSON Web Signature); утверждения о "безопасных", но неподписанных токенах (например, с "alg": "none") носят скорее академический характер и в продакшен-средах категорически недопустимы.

Структура JWT

JWT состоит из трёх частей, разделённых точками (.):

Header — метаданные токена. Содержит тип токена ("typ": "JWT") и алгоритм подписи ("alg"). Пример:

   {
     "alg": "HS256",
     "typ": "JWT"
   }

Payload — тело токена. Содержит утверждения (claims). Существуют три типа claims:
- Зарезервированные (iss, exp, sub, aud и др.) — стандартизированы, но не обязательны.
- Публичные — согласованные между сторонами (например, role, department).
- Приватные — специфичные для приложения (например, user_id, is_premium).
Пример payload:

   {
     "sub": "1234567890",
     "name": "Тимур Тагиров",
     "role": "admin",
     "exp": 1730000000
   }

Signature — криптографическая подпись, гарантирующая целостность токена. Формируется путём:
- Кодирования header и payload в Base64Url;
- Конкатенации их через точку;
- Подписи полученной строки с использованием секретного ключа (HMAC) или закрытого ключа (RSA/ECDSA).
Пример подписи (для HMAC):

   HMACSHA256(
     base64UrlEncode(header) + "." + base64UrlEncode(payload),
     secret
   )

Результирующий токен выглядит так:
xxxxx.yyyyy.zzzzz

Применение JWT

Аутентификация
После успешного входа пользователь получает JWT. При последующих запросах он передаёт токен (обычно в заголовке Authorization: Bearer <token>). Сервер проверяет подпись и срок действия, после чего считает запрос аутентифицированным.
Авторизация
Роли и разрешения кодируются в payload. Например, наличие "role": "admin" позволяет контроллеру разрешить доступ к защищённому эндпоинту.
Единый вход (SSO)
JWT может использоваться как токен обмена между сервисами в рамках единой экосистемы. Например, сервис аутентификации генерирует токен, который принимают все микросервисы.

Ограничения и риски

JWT не отменяется
Поскольку JWT stateless, его нельзя инвалидировать до истечения срока действия (exp). Решения:
- Использовать короткий срок жизни (например, 15 минут) и пару access/refresh tokens;
- Вести чёрный список недействительных токенов (например, в Redis).
Хранение на клиенте
Хранение JWT в localStorage подвержено атакам XSS; в HttpOnly cookie — атакам CSRF. Оптимальный выбор зависит от архитектуры и уровня угроз.
Подделка токена
Если сервер использует слабый или утечку секретного ключа, злоумышленник может сгенерировать валидный JWT. Требуется тщательное управление ключами.

Валидация входных данных и управление доверием

Аутентификация и авторизация не защищены, если входные данные не проходят строгую валидацию. Уязвимости типа insecure direct object reference (IDOR) или injection часто возникают из-за отсутствия проверки входных параметров.

Белый и чёрный списки

Белый список (allowlist) — явное разрешение только известных, ожидаемых значений.
Пример: разрешить выбор роли только из ["user", "moderator", "admin"].
Чёрный список (blocklist) — попытка запретить опасные значения. Не рекомендуется, так как невозможно перечислить все возможные векторы атаки.

Белый список — единственный надёжный подход в критичных местах (ролях, путях файлов, идентификаторах).

Библиотеки валидации

Для обеспечения типобезопасности и валидации структуры данных используются специализированные библиотеки:

Python: Marshmallow — декларативная валидация и сериализация объектов.
Node.js: Joi (ныне @hapi/joi) или Zod — строгая схема валидации с поддержкой кастомных правил.
C#: встроенные механизмы Data Annotations ([Required], [StringLength]) и библиотеки вроде FluentValidation.
Java: Bean Validation (@NotNull, @Pattern) + Hibernate Validator.

Пример на Python (Marshmallow):

from marshmallow import Schema, fields

class LoginSchema(Schema):
    username = fields.Str(required=True, validate=validate.Length(min=3, max=32))
    password = fields.Str(required=True, validate=validate.Length(min=8))

Такой подход предотвращает передачу неожиданных или вредоносных данных на уровень аутентификации.

Управление сессиями и stateful-подход

Хотя JWT популярен, сессионная аутентификация остаётся актуальной, особенно в монолитных веб-приложениях.

Как работает сессия

Пользователь отправляет логин и пароль.
Сервер проверяет учётные данные.
При успехе создаётся объект сессии на сервере (в памяти, Redis, БД).
Клиенту возвращается session ID (обычно в Set-Cookie).
При последующих запросах браузер автоматически отправляет cookie с session ID.
Сервер находит сессию по ID и проверяет её валидность.

Преимущества сессий

Возможность мгновенной отмены (удаление из хранилища).
Отсутствие передачи чувствительных данных клиенту.
Встроенная защита от XSS при использовании HttpOnly cookie.

Недостатки

Требует stateful-архитектуры (сложнее масштабировать).
Неудобно в мобильных и SPA-приложениях без дополнительной обвязки.

Готовые фреймворки — Identity, Keycloak, Auth0

ASP.NET Core Identity

Встроенная система управления пользователями в .NET. Включает:

CRUD-операции над пользователями и ролями.
Хранение в таблицах — AspNetUsers, AspNetRoles, AspNetUserRoles.
Поддержку внешних провайдеров (Google, Facebook).
Встроенную двухфакторную аутентификацию (2FA) через TOTP или SMS.

Пример включения 2FA:

// Включение 2FA
await _userManager.SetTwoFactorEnabledAsync(user, true);

// Генерация секретного ключа для Google Authenticator
var key = await _userManager.GetAuthenticatorKeyAsync(user);
if (string.IsNullOrEmpty(key))
{
    await _userManager.ResetAuthenticatorKeyAsync(user);
    key = await _userManager.GetAuthenticatorKeyAsync(user);
}

Проверка TOTP-кода:

var isValid = await _userManager.VerifyTwoFactorTokenAsync(
    user, _userManager.Options.Tokens.AuthenticatorTokenProvider, code);

Keycloak

Open-source Identity и Access Management (IAM) сервер. Поддерживает:

OAuth 2.0, OpenID Connect, SAML.
RBAC, fine-grained permissions.
Адаптеры для Java, JavaScript, .NET, Python.
UI для управления пользователями и ролями.

Auth0 и Okta

Облачные решения с минимальной настройкой. Подходят для стартапов и SaaS-продуктов. Предоставляют:

Готовые экраны входа/регистрации.
Аналитику аутентификации.
Поддержку социальных провайдеров.
Управление MFA, блокировку брутфорса, anomaly detection.

Единый вход (Single Sign-On, SSO)

Single Sign-On (SSO) — архитектурный паттерн, позволяющий пользователю аутентифицироваться один раз и получить доступ к множеству взаимодействующих систем без повторного ввода учётных данных.

Принцип работы

Пользователь пытается получить доступ к приложению A.
Приложение A перенаправляет его на Identity Provider (IdP).
Если пользователь не аутентифицирован в IdP — ему предлагается войти.
После успешной аутентификации IdP генерирует утверждение (assertion) и перенаправляет пользователя обратно в приложение A с этим утверждением.
Приложение A проверяет подлинность утверждения и создаёт локальную сессию.

Стандарты SSO

SAML (Security Assertion Markup Language)
XML-ориентированный стандарт, доминирующий в корпоративном секторе (особенно в интеграциях с Microsoft, SAP, Salesforce). Обеспечивает надёжную передачу атрибутов и поддержку федеративной идентификации.
OpenID Connect (OIDC)
Современный, JSON/REST-ориентированный стандарт на базе OAuth 2.0. Широко используется в облачных и веб-приложениях. Проще в реализации, чем SAML, и лучше подходит для SPA и мобильных клиентов.
OAuth 2.0 как основа
Хотя OAuth 2.0 изначально не предназначен для аутентификации, в связке с OIDC он становится полноценным SSO-решением. Провайдеры (Google, Microsoft, GitHub) предоставляют OIDC-эндпоинты (/.well-known/openid-configuration).

Преимущества SSO

Улучшение UX: пользователь входит один раз.
Централизованный контроль: администратор управляет доступом в одном месте.
Снижение рисков: меньше паролей → меньше утечек.
Упрощённый аудит и логирование.

Риски

Единая точка отказа: компрометация IdP даёт доступ ко всем системам.
Сложность отмены доступа: требуется своевременная синхронизация статуса учётной записи.

Интеграция аутентификации и авторизации в разные типы приложений

Веб-приложения

Традиционные (server-rendered)
Используют сессионную аутентификацию с HttpOnly cookie. CSRF-токены обязательны. Авторизация реализуется через middleware (например, [Authorize] в ASP.NET, @login_required в Django).
SPA (React, Angular, Vue)
Чаще используют токен-ориентированный подход (JWT). Токен хранится в памяти (не в localStorage) для защиты от XSS. Авторизация на фронтенде — декоративна; окончательная проверка всегда на бэкенде.
API-first архитектура
Все эндпоинты защищаются через заголовок Authorization: Bearer <token>. Используются кастомные middleware или библиотеки (express-jwt, Flask-JWT-Extended, Microsoft.AspNetCore.Authentication.JwtBearer).

Десктопные приложения

Native-приложения (WPF, WinForms, Electron)
Аутентификация часто реализуется через браузерную перенаправляющую модель (OAuth 2.0 Authorization Code + PKCE). Это безопаснее хранения логина/пароля в приложении.
После получения токена он сохраняется в защищённом хранилище ОС — Windows Credential Vault, Keychain (macOS), libsecret (Linux).
Автономные системы
В отсутствие сети может применяться локальная аутентификация (например, хэши паролей в зашифрованном файле), но с ограничениями: нет централизованного управления, нет SSO.

Мобильные приложения

OAuth 2.0 + PKCE — рекомендуемый стандарт (RFC 7636). Предотвращает перехват authorization code.
Biometric Unlock — после первоначального входа пользователь может разблокировать приложение отпечатком, но JWT/refresh token остаются в защищённом хранилище (Android Keystore, iOS Secure Enclave).
Refresh Tokens — критически важны из-за долгой сессии. Должны быть привязаны к устройству и иметь механизм отмены.

Типичный сценарий ошибки доступа (и как исправить)

Частая ситуация — пользователь успешно вошёл в систему, а дальше API проверяет только факт входа, но не проверяет право на конкретный ресурс. Так появляются IDOR и "горизонтальное" повышение привилегий.

Безопасная последовательность:

Подтвердить подлинность субъекта (аутентификация).
Проверить право на действие над конкретным объектом (авторизация на уровне ресурса).
Залогировать решение с причиной "разрешено/запрещено".
Вернуть минимально необходимый ответ без утечки внутренних деталей.

Практический минимум для production

единый Identity Provider для всех приложений компании;
короткоживущие access tokens и контролируемые refresh tokens;
MFA для администраторов и чувствительных операций;
централизованный аудит входов, отказов доступа и изменений ролей;
регулярные проверки на broken access control из OWASP Top 10.

RBAC и ABAC: как комбинировать без перегруза

Рабочая модель для большинства команд:

RBAC как "база" (понятные роли и простое администрирование);
ABAC как "надстройка" для контекста (время, локация, риск сессии, тип устройства);
политики документируются как код, проходят ревью и тесты.

Такой гибрид даёт баланс: не слишком сложно поддерживать и при этом достаточно гибко для реальных сценариев.

Связанные статьи

Контроль и отслеживание — как аудит помогает расследовать ошибки доступа;
Шифрование — как защищать токены и секреты;
SSH и HTTPS — транспортная безопасность для auth-потоков;
Управление конфигурациями и окружениями — безопасное хранение параметров доступа.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.