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
Что будет на вебинаре: - спроектируем сквозной сценарий аутентификации для веба, мобильных и десктоп-клиентов прямо в 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