OAuth, JWT и шлюзы: разделяйте меры безопасности

Кратко

OAuth 2.0 организует делегированную авторизацию; OpenID Connect добавляет аутентификацию. JWT — формат токена, шлюз — точка контроля: роли различны.

Вымышленная пустая комната проверки доступа: два ключа безопасности, чистая карта и бордовая папка
В этой статье

Выбрать роль до инструмента

Токен доступа OAuth может быть непрозрачным или использовать JWT. Декодирование JWT не проверяет подлинность; подписанный JWT не шифрует содержимое автоматически. Шлюз не заменяет бизнес-авторизацию в сервисах.

ЭлементРольВидимое ограничение
OAuth 2.0Делегированная авторизация.Сам по себе не протокол входа пользователя.
OpenID ConnectАутентификация поверх OAuth 2.0.Нужна проверка профиля и токенов.
JWTФормат утверждений.Декодирование, подпись и шифрование различны.
API-шлюзОбщие входные проверки.Не заменяет объектные права.

Проверять протокол и каждый доступ

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

Планировать срок действия, отзыв и инциденты

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

Первоисточники

Шлюз не заменяет авторизацию объектов.

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

  • Отклоняйте действительный токен, предназначенный для другой аудитории.
  • Проверяйте доступ между учетными записями, закрытые поля и административные операции.
  • Проверяйте истечение срока действия и изменение роли без записи токенов в журналы.

Первичный источник: IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. Связанный метод: прочитать практическое руководство.

Passkey: подготовить смену домена и RP ID

Разделить учётную запись, веб-источник и RP ID, чтобы не переназначать данные входа скрытно.

  • Запишите старые и новые источники, RP ID и связанные записи. Одинаковое имя записи не делает passkey действительным для другого RP ID. Проверьте допустимые сочетания WebAuthn и доступные пути входа на переходе.
  • В разрешённой тестовой среде проверьте challenge, источник, RP ID и связь с записью подходящей библиотекой. Испытайте неожиданный источник и повтор challenge. Смена RP ID требует новой аутентифицированной регистрации: копирование строки не переносит ключ.
  • Проверьте пользователя только со старым credential, восстановление и открытые сессии. Задайте открытие и закрытие путей с проверенным возвратом. Регистрация на новом домене не доказывает отзыв всех старых сессий.

Воспроизводимый приёмочный случай

Вымышленный пример: данные не описывают клиента или наблюдаемый результат.

Посмотреть данные случая
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

Ожидаемое решение

Вымышленный пример: запись та же, но old.example меняется на new.example с другим RP ID. Старый credential нельзя скрытно перепривязать; новая регистрация проходит предусмотренный аутентифицированный путь.

W3C — Web Authentication Level 2

Можно ли изменить RP ID passkey редактированием базы?

Нет. RP ID входит в проверяемую область credential. Подготовьте допустимую новую регистрацию и аутентифицированную связь записи.

Первичный источник: W3C — Web Authentication Level 2. Связанный метод: прочитать практическое руководство.

Продление TLS: проверить реально выдаваемый сертификат

Проследить продление до точек завершения TLS и клиентов перед закрытием изменения.

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

Воспроизводимый приёмочный случай

Вымышленный пример: данные не описывают клиента или наблюдаемый результат.

Посмотреть данные случая
{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}

Ожидаемое решение

Вымышленный пример: продление успешно, но один из двух прокси выдаёт просроченный сертификат. Изменение не завершено; исправьте прокси и проверьте клиентские пути, не отключая TLS.

Let’s Encrypt — Integration Guide

Первичный источник: Let’s Encrypt — Integration Guide. Связанный метод: прочитать практическое руководство.

Обзор каталога CISA KEV

Подробные справочные заметки в этой версии доступны на английском.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Каталог и метод →

CISA KEV · 2026.11.06 · Documentary review : 2026-11-07

Расширения: разрешения и доступ

Подробные справочные заметки в этой версии доступны на английском.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent