Аутентификация OAuth 2.0 и OpenID Connect¶
Требования этого документа применяются к web- и нативным mobile-приложениям,
API, backend-сервисам и межсервисному взаимодействию. Уровни обязательности
определены в корневом README.md.
SEC-AUTHN-001. OpenID Connect для аутентификации пользователя¶
Уровень: MUST
Применяется к: входу пользователя в приложение
Аутентификация пользователя должна выполняться через OpenID Connect 1.0 поверх OAuth 2.0 с корпоративным Identity Provider.
OAuth 2.0 без OpenID Connect не должен использоваться как протокол аутентификации пользователя. Локальная проверка пароля приложением запрещена, если она не является назначением самого Identity Provider.
Обоснование¶
OAuth 2.0 определяет делегированную авторизацию, а OpenID Connect добавляет проверяемую идентичность пользователя.
Проверка¶
- review discovery metadata и конфигурации клиента;
- integration-тест входа через корпоративный Identity Provider;
- проверка отсутствия локального password authentication в приложении.
Исключения¶
Другой протокол аутентификации требует утверждённого ADR и согласования владельца информационной безопасности.
SEC-AUTHN-002. Безопасный пользовательский flow¶
Уровень: MUST
Применяется к: интерактивной аутентификации пользователя
Должен использоваться Authorization Code Flow. Публичный клиент должен использовать Proof Key for Code Exchange (PKCE). Confidential client должен аутентифицироваться перед token endpoint утверждённым для него способом и также должен использовать PKCE, если Identity Provider его поддерживает.
Клиент должен проверять state, а при запросе OpenID Connect — nonce.
Redirect URI должен точно совпадать с заранее зарегистрированным значением и не
должен допускать произвольный redirect.
Обоснование¶
Code Flow, PKCE, state и nonce защищают authorization response от перехвата,
подмены запроса и повторного использования.
Проверка¶
- integration-тест полного flow;
- security-тест отсутствующего или неверного
state,nonceи PKCE verifier; - проверка зарегистрированных redirect URI.
Исключения¶
PKCE для confidential client может не применяться, если Identity Provider его не поддерживает и это ограничение зафиксировано в проектной документации.
SEC-AUTHN-003. Запрещённые OAuth flows¶
Уровень: MUST NOT
Применяется к: OAuth 2.0 и OpenID Connect клиентам
Запрещено использовать Implicit Flow и Resource Owner Password Credentials Grant. Приложение не должно получать пароль пользователя для обмена на token.
Authorization Code не должен передаваться через незашифрованный канал, повторно использоваться или сохраняться как credential приложения.
Обоснование¶
Эти flows раскрывают token или пароль среде клиента и не предоставляют современных механизмов защиты authorization response.
Проверка¶
- review разрешённых grant types клиента;
- проверка исходного кода и конфигурации;
- security-тест повторного использования Authorization Code.
Исключения¶
Не допускаются для новых проектов.
SEC-AUTHN-004. Назначение token¶
Уровень: MUST
Применяется к: вызову защищённого API
Клиент должен передавать API только access token, выпущенный для audience этого API. ID token подтверждает результат аутентификации клиенту и не должен использоваться как access token или как самостоятельное основание разрешить операцию API.
Факт успешного декодирования значения как JWT не должен использоваться для определения назначения token.
Обоснование¶
ID token и access token имеют разных получателей и назначение; их подмена нарушает границу доверия.
Проверка¶
- integration-тест отклонения ID token API;
- проверка
audaccess token; - review middleware аутентификации.
Исключения¶
Не допускаются.
SEC-AUTHN-005. Проверка access token¶
Уровень: MUST
Применяется к: каждому защищённому API и backend-сервису
До выполнения защищённой операции resource server должен проверить token.
Для JWT должны проверяться подпись, разрешённый алгоритм, iss, aud, exp,
nbf, а также обязательные проектом claims. Алгоритм из token не должен
автоматически становиться разрешённым алгоритмом проверки.
Opaque token должен проверяться через утверждённый introspection endpoint. Неуспешная, неполная или недоступная проверка должна завершаться отказом в доступе.
Обоснование¶
Наличие и синтаксическая корректность token не подтверждают его подлинность, назначение и срок действия.
Проверка¶
- тест неверной подписи, issuer, audience, срока и алгоритма;
- тест неактивного opaque token;
- тест недоступности metadata, keys или introspection endpoint.
Исключения¶
Допустимое clock skew должно иметь конечное документированное значение.
SEC-AUTHN-006. Metadata и ротация ключей¶
Уровень: MUST
Применяется к: OpenID Connect клиентам и resource servers
Endpoints, issuer и JSON Web Key Set должны получаться из доверенной конфигурации или проверенного discovery document. Discovery URL не должен приниматься из пользовательского ввода.
Ключи проверки подписи должны кэшироваться ограниченное время и обновляться
при появлении неизвестного kid. Уже полученный набор ключей не должен
бессрочно использоваться после истечения заданного срока.
Обоснование¶
Управляемое discovery и обновление ключей поддерживают ротацию без доверия произвольному issuer.
Проверка¶
- integration-тест ротации signing key;
- тест неизвестного
kid; - review источника discovery URL и политики cache.
Исключения¶
Статическая конфигурация endpoints допускается, если её обновление входит в управляемый процесс поставки.
SEC-AUTHN-007. Аутентификация не заменяет авторизацию¶
Уровень: MUST
Применяется к: каждой защищённой операции
Backend должен проверять технические OAuth scopes, необходимые endpoint. Решение о доступе subject к предметной операции и объекту должно приниматься по применимой модели AuthZ. Наличие аутентифицированного пользователя или роли в token само по себе не предоставляет доступ.
Клиентский интерфейс может скрывать недоступное действие, но эта проверка не заменяет авторизацию backend. Решение должно следовать принципу минимальных привилегий и по умолчанию запрещать доступ.
Централизованная проверка AuthZ выполняется по требованиям SEC-AUTHZ-001,
SEC-AUTHZ-002 и SEC-AUTHZ-012, если они применимы к проекту.
Обоснование¶
Клиент и его claims presentation контролируются вызывающей стороной, а права могут зависеть от конкретной операции и объекта.
Проверка¶
- unit-тест матрицы разрешений;
- integration-тест доступа к чужому объекту и повышению привилегий;
- проверка deny-by-default для неизвестной роли или scope.
Исключения¶
Публичная операция должна быть явно объявлена публичной в контракте API.
SEC-AUTHN-008. Межсервисная аутентификация¶
Уровень: MUST
Применяется к: вызову без пользовательского контекста
Сервис должен использовать отдельный OAuth 2.0 client с Client Credentials Grant и минимальными scopes для целевого API. Запрещено использовать пользовательский token, общий client secret нескольких сервисов или интерактивный пользовательский flow.
Идентичность вызывающего сервиса должна отличаться по сервису и окружению.
Обоснование¶
Отдельная service identity позволяет ограничивать доступ, отзывать credential и аудировать фактического вызывающего.
Проверка¶
- review клиентов и scopes в Identity Provider;
- integration-тест service-to-service token;
- проверка отсутствия общего credential между сервисами и окружениями.
Исключения¶
Передача пользовательского access token допускается только для явно спроектированного delegated flow с проверяемой audience и моделью делегирования.
SEC-AUTHN-009. Защита token¶
Уровень: MUST
Применяется к: хранению и передаче token
Token должен передаваться только по TLS и не должен присутствовать в URL,
логах, трассах, событиях ошибок или аудит-данных. Backend-секреты OAuth-клиента
должны обрабатываться по требованиям BE-CONF-005 и BE-CONF-007.
Browser-based приложение не должно сохранять access token или refresh token в
localStorage или другом доступном JavaScript долговременном хранилище. Если
используется server-side session, cookie должна иметь Secure, HttpOnly и
подходящий контексту SameSite.
Обоснование¶
Token является credential предъявителя; получившая его сторона может действовать с предоставленными token правами.
Проверка¶
- security review хранения token;
- сканирование URL и телеметрии;
- проверка cookie attributes;
- browser security-тест при применимости.
Исключения¶
Способ хранения token в публичном клиенте требует отдельной модели угроз, если архитектура не позволяет server-side session.
SEC-AUTHN-010. Жизненный цикл token и сессии¶
Уровень: MUST
Применяется к: token и пользовательским сессиям
Access token должен иметь ограниченный срок действия. Refresh token должен использовать ротацию или иной механизм обнаружения повторного использования, если это поддерживает Identity Provider.
Logout должен завершать локальную сессию и инициировать предусмотренное Identity Provider завершение сессии или отзыв token. Изменение критичных прав, блокировка пользователя и компрометация credential должны иметь документированный путь досрочного прекращения доступа.
Обоснование¶
Ограниченный срок и отзыв уменьшают период использования украденного или уже не соответствующего правам token.
Проверка¶
- тест истечения access token;
- тест ротации и повторного использования refresh token;
- integration-тест logout, блокировки и изменения прав.
Исключения¶
Отсутствие online revocation должно компенсироваться коротким сроком access token и зафиксированным максимальным временем отзыва доступа.
SEC-AUTHN-011. Ошибки и аудит аутентификации¶
Уровень: MUST
Применяется к: результатам аутентификации и авторизации
API должен отвечать 401 Unauthorized с применимым WWW-Authenticate при
отсутствующей или недействительной аутентификации и 403 Forbidden при
успешной аутентификации, но недостаточных правах. Ответ не должен раскрывать
внутреннюю причину проверки token.
Успешные и неуспешные события, перечисленные моделью аудита проекта, должны
регистрироваться по OBS-AUD-001. Token, Authorization Code, cookie и client
secret не должны попадать в diagnostic context.
Обоснование¶
Единая семантика ошибок нужна клиенту, а аудит — для обнаружения атак и расследования без раскрытия credentials.
Проверка¶
- contract-тест ответов защищённого API;
- integration-тест аудит-событий;
- secret scanning логов, трасс, GlitchTip и аудит-данных.
Исключения¶
Не допускаются для запрета записи credentials.
SEC-AUTHN-012. Защита cookie-сессии от CSRF¶
Уровень: MUST
Применяется к: browser-based приложению с cookie-сессией
Запрос, изменяющий состояние, должен быть защищён от Cross-Site Request
Forgery (CSRF) проверяемым token, проверкой Origin/Referer или другим
утверждённым механизмом, соответствующим архитектуре приложения.
Cookie attributes Secure, HttpOnly и SameSite должны применяться по
SEC-AUTHN-009, но SameSite не должен считаться единственной защитой, если
сценарии приложения требуют cross-site cookie или поддерживают небезопасный
user agent.
Обоснование¶
Browser автоматически прикладывает cookie к запросу, поэтому аутентифицированная сессия без проверки происхождения может выполнить действие со страницы атакующего.
Проверка¶
- security-тест cross-site запроса без CSRF token;
- тест отсутствующего и неверного
Origin/Referer, если они проверяются; - review cookie attributes и исключённых endpoints.
Исключения¶
Операция, доказуемо не изменяющая состояние, может не применять CSRF-проверку.