Вот мы и подобрались к финальной части нашего разбора OIDC 🧩 В прошлых выпусках уже обсудили: 📎 Что такое OIDC, как он применяется, где используется, базовые термины и кратко — как выглядит реализация Authorization Code Flow. 📎 PKCE: магия безопасности и почему Implicit Flow уходит в прошлое. Сегодня предлагаю поговорить: насколько использование OIDC безопасно? ⚡️ Безопасность сильно зависит от используемого flow и корректности реализации: 1. Некорректная валидация ID Token: RP должен проверять подпись, issuer (iss), audience (aud), время жизни (exp, iat) токена. 2. Использование устаревших flow: Implicit Flow токен в URL fragment — опасен и устарел. Избегайте его! 3. Отсутствие PKCE для публичных клиентов: мобильные и SPA приложения без PKCE уязвимы к перехвату кода. 4. Утечка кода авторизации: код из URL должен немедленно обмениваться на токены на backend. Никогда не обрабатывайте код в фронтенде. 5. Отсутствие state параметра: защита от CSRF-атак. RP должен генерировать случайный state и проверять его при возврате. 6. Некорректные redirect_uri: OP должен строго проверять, что redirect_uri, куда вернется пользователь, зарегистрирована для этого RP. 7. Слабые секреты клиента: client_secret должен храниться безопасно (не в коде фронтенда!) Полезные ресурсы от OpenID Foundation: OAuth 2.0 Security Best Practices OIDC Security Best Practices Подытожим: OIDC — элегантное и мощное решение для аутентификации в современном мире. Но ключ к безопасности — правильный выбор Flow и аккуратная реализация. Запомните простое правило: ❗️PKCE — для публичных клиентов; ❗️Authorization Code — для конфиденциальных; ❗️Implicit Flow — в утиль; ♻️ А в карточках — забирайте шпаргалку для ТЗ аналитиков, чтобы ничего важного не потерять при внедрении и интеграции ❤️ #гайды@DiagnosisAnalyst