Безопасность
OAuth/OIDC: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый отражает решение в реальном инциденте или ревью дизайна — не определение для заучивания, а обязательную проверку, которую надо защитить. Тезис юнита: пропусти любую одну — и ты выкатил CVE.
Убедись, что связываешь PKCE, точное совпадение redirect_uri, восемь проверок id_token, ротацию refresh token, sender-constrained-токены и валидацию аудитории в одну модель безопасности «полного набора».
Твой OAuth-клиент — конфиденциальное серверное приложение с client_secret. Ревьюер спрашивает, зачем ты всё равно шлёшь PKCE. Какой ответ верный?
Команда регистрирует redirect_uri как префиксное совпадение (https://app.example/callback*), чтобы поддержать динамические пути возврата. Почему это уязвимость?
OIDC-клиент проверяет подпись id_token, iss, exp и nonce — но берёт алгоритм проверки из собственного заголовка alg токена. В чём изъян?
Refresh token утёк через access-лог. Ротация refresh token включена. Каково максимальное окно вреда?
Supply-chain-атака внедряет JavaScript в твой SPA и выводит access token из памяти. Токен привязан через DPoP. Почему украденный токен не проходит на resource server?
Один authorization server выпускает токены для API-A и API-B. Валидатор API-B делает: если token.aud содержит любой известный client_id, принять. Почему это уязвимость audience-confusion?
Сквозная линия юнита — одно правило полного набора: PKCE привязывает code к клиенту, точное совпадение redirect_uri удерживает code в пределах домена, восемь проверок id_token (с закреплённым на сервере алгоритмом) аутентифицируют пользователя, ротация refresh token превращает кражу в сигнал тревоги, sender-constrained-токены (DPoP/mTLS) обезвреживают кражу bearer-токена, а валидация аудитории по захардкоженному идентификатору блокирует межсервисную confusion. Каждый реальный взлом OAuth — Facebook, Slack, GitHub Enterprise, Azure AD — сводится ровно к одной из этих проверок, пропущенной или вывернутой.