2026-06-22. OTUS. OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию

Описание

Что будет на вебинаре:
- спроектируем сквозной сценарий аутентификации для веба, мобильных и десктоп-клиентов прямо в Use Case: покажем, как на уровне требований защитить Access и Refresh токены без привязки к конкретному языку программирования;
- на реальном кейсе разберем классическую уязвимость «Bearer token + localStorage»: увидите, как эта дыра выглядит со стороны требований, и за 2 шага перестроите спецификацию на безопасную модель (BFF + httpOnly Secure Cookie) с помощью sequence-диаграмм;
- соберем «радар» типовых атак: научимся встраивать в функциональные и нефункциональные требования защиту от подбора, брутфорса и повторного воспроизведения (Replay Attack) так, чтобы эти сценарии не выпали из поля зрения разработки;
- разложим OAuth 2.0 на язык аналитика: перестанем путаться в Implicit Flow, Authorization Code Flow и PKCE — вместо этого соберём чек-лист выбора гранта на основе бизнес-процесса и типа клиента.

Каким слушателям вебинар будет полезен:
- системным аналитикам уровня, которые уже пишут требования, но хотят уверенно закрывать вопросы безопасности в ТЗ и не ждать критических замечаний от аудита.
- аналитикам, участвующим в проектировании интеграций (в том числе SSO) между своими сервисами и коробочными продуктами вроде Keycloak, кому нужны готовые формулировки для раздела аутентификации.

Что в результате вебинара узнают и смогут пользователи:
- выбирать корректный OAuth 2.0 Flow, задав бизнесу всего 3 вопроса, и обосновывать его в ТЗ;
Для чего мне это: чтобы не пропускать дыры в сценариях и не полагаться "опыт" разработчика — теперь вы сами укажете правильный поток.
- описывать ролевую модель (RBAC/ABAC) в привязке к токенам так, чтобы изменение прав применялось мгновенно без перевыпуска токена.
Для чего: чтобы эти требования были прозрачны для бизнеса и разработчиков, и реализация с первого раза соответствовала задумке.
- формулировать нефункциональные требования к хранению сессий и ключам: время жизни, поведение при высоких нагрузках.
Для чего: чтобы на 100k одновременных пользователей система аутентификации осталась стабильной, и вы могли аргументированно защитить эти цифры перед командой.
- получить готовый артефакт — «Навигатор СА по безопасной аутентификации»: схему и шаблон раздела ТЗ в PlantUML/JSON.
Для чего: чтобы вы могли скопировать этот шаблон в свой проект, адаптировать и сразу закрыть целый блок требований по безопасности без поиска разрозненных материалов.

Преподаватель: Дмитрий Бритин - архитектор платформенных решений в блоке корпоративной архитектуры банка ТОП-10

Связаться с автором канала TG -﹥ @mglazman