Архитектура безопасной авторизации на примере протоколов OAuth и OIDC

Кто я

1. 14+ лет в вебе. Прошел путь fullstack, teamlead
2. Работаю CTO в Вебпрактик (~140 человек)
3. Член программного комитета TechLeadConf, Podlodka Crew
4. Пишу на Typescript, Nodejs (Nest) и React, PHP
5. Организатор Ростовского PHP-сообщества (500+ человек)
6. Влюблен в Linux, OpenSource.

Авторизация

Вопросы в зал

• Кто из вас реализовывал авторизацию в SPA-приложениях?
• Кто использовал для этого JWT-токены?
• Кто читал OWASP-рекомендации (или RFC 8725 JSON Web Token Best Current Practices), как сделать это безопасно?

Проблемы первого раза для авторизации в SPA

• Масса статей, которые очень поверхностно разбирают лишь самые базовые аспекты
• Отсутствие знаний по грамотной эксплуатации
  и защите токенов
• Следовать предписаниям велосипеда бэкендеров, которые также часто не имеют должной экспертизы

Как следствие, мы можем встречать решения
с плохими практиками в области безопасности
на многих проектах

Терминология

• Аутентификация — процедура проверки подлинности, доказательство, что пользователь именно тот, за кого себя выдает.
• Авторизация — предоставление определённых прав.

Вас поставили пилить новый проект

• На проекте должна быть авторизация
• Сервис публичный, есть персональные данные
• На проекте есть SSR

JWT

Stateful (session) аутентификация

Классическая аутентификация в монолитных приложениях

• Простота
• Проще обеспечить безопасность
• Плохо подходит SOA/MSA (потери скорости, проблемы с масштабированием)

Stateless (JWT)

• Масштабирование
• Скорость
• Сложнее обеспечить безопасность

Бэкендер выплевывает
JWT-токен
в ответе на метод авторизации...

Какие вопросы перед нами встают?

Где хранить JWT-токен на клиенте?

Local storage

Я могу сэкономить, не дергать лишний раз бэкенд для получения данных пользователя, его групп и проч.

• сохраню его локально
• буду прикреплять к каждому запросу
• и использовать данные для своего приложения

Где хранить JWT-токен на клиенте?

Как читать данные с токена?

• Токен должен быть зашифрован! (JWE)
• Делаем доп. запрос на сервер, чтобы его расшифровать
  (Можно использовать BFF)

Сколько должен жить JWT-токен?

Best Practices: 1-15min

А как его обновлять?

• Refresh token
• Длительность: должен быть больше, чем access token
• Хранение аналогично: localStorage / cookie httpOnly

Механика обновления access token

Ротация Refresh token

• При запросе нового access token, выдавать в т.ч. новый refresh token, делая старый устаревшим
• Идем дальше: объединять цепочку токенов в семейство. При попытке использовании старого refresh token — убивать всю семью.
• И все это больно делать, если до этого мы сохраняли токен в storage, опять прийдется работать ручками

Как защитить токен от кражи? (Token Sidejacking)

• csrf token в виде отдельной http_only cookie,
  в котором хранить user context + random SHA256

Как отозвать токен?

• blacklist (OWASP)
• Но как же stateless?
• Можно хранить на конкретном bff в отдельном кеше (redis)
• А раз у нас все равно появляется состояние на bff, то, может, и токены положить в редис, а на клиент отдавать старую добрую сессию
• Ну а stateless останется для микросервисов, которые за bff

JWT: другие проблемы

• Уязвимости криптографии
• Множество векторов атак: Signature Forgery, Token Hijacking, Replay Attack, Key Exposure, Brute Force Key Attack, Key ID Injection, JWT Injection, CSRF, Leakage of Sensitive Data
• Прежде чем ее использовать, убедитесь, что вам это точно (!) нужно. Может, просто сессии?

JWT: готовые решения

• Всего несколько библиотек
• Многие по умолчанию хранят в local storage
• Плохо обновляются
• AuthJS

Разбор Auth.JS: Безопасность

1. Реализовано шифрование JWS / JWE / JWK
2. httpOnly SameSite Secure cookie
3. Запрос данных расшифрованной cookie с сервера
4. Автоматическая ревалидация
5. CSRF
6. Ротация токенов
7. Нет Refresh-токена => нет механизма отзыва токенов

Разбор Auth.JS: Функциональность

1. Готовые обвязки с 50+ разными провайдерами авторизации

Разбор Auth.JS: Функциональность

1. Готовые обвязки с 50+ разными провайдерами авторизации
2. SSR Friendly
3. Готовые удобные хуки (или другое API для вашего Frontend Framework)
4. Синхронизация вкладок

Custom JWT авторизация: выводы

• Фронтендер должен обладать знаниями в области основ безопасности авторизации JWT
• В данном случае, т.к. у нас есть персданные и приложение публичное — по-хорошему сказать бэкендеру переделать на cookie httpOnly
• Бонусом: сильно меньше велосипедного кода на фронтенде, клиент более глупый и тонкий
• Вариант с localStorage: во внутренней доверенной сети и для приложений без чувствительных данных
• Нет универсальных готовых библиотек которые реализуют за вас большинство bestpractices на фронтенде

Session-аутентификация

• Простота
• Проще обеспечить безопасность
• Хуже подходит SOA/MSA

Session: выводы

• Этот метод является предпочтительным практически всегда, когда у вас нет микросервисов
• Даже если есть микросервисы — фронт по прежнему может жить на сессиях, а JWT оставить для внутреннего контура

OAuth/OIDC

• OAuth — стандарт авторизации
• Open ID Connect (OIDC) — стандарт аутентификации , построенный на базе OAuth
• Использование OAuth в качестве аутентификации считается некорректным и может приводить к дополнительным уязвимостям и векторам атаки

Применимость: Когда нужен OIDC

Применимость: корпоративное или cервисное SSO

Применимость: корпоративное или cервисное SSO

Применимость: сторонние поставщики

Применимость: аутсорс сервис

Применимость

• Использование OIDC усложнит вашу архитектуру
  и добавит накладные расходы
• Нерационально использовать, если у вас нет группы приложений

OAuth/OIDC — не один стандарт

• OAuth/OIDC включает в себя десятки стандартов
• Не каждая реализация oAuth/OIDC имплементирует все стандарты
• Не каждая реализация ПРАВИЛЬНО реализует стандарты

OpenID Connect Protocol Suite

Различия: токены

Общие для OAuth и OIDC

• access token
• refresh token

Только OIDC

• ID token

Различия: FLOW

Общие для OAuth и OIDC

• Authorization Code Flow основной
• Implicit Flow: устаревший, небезопасный

Только OIDC

• Hybrid Flow

Authorization Code Flow

Способы защиты oAuth/OIDC

1. Вспоминаем часть защиты JWT
2. PKSE
3. nonce, c_hash, at_hash

PKSE

1. PKCE предотвращает атаку, при которой злоумышленник перехватывает authorization code, чтобы получить access-токен
2. Когда нужно: когда нет доверия каналам клиентом и сервером

Защищаемся от векторов атак на клиенте:

• Access Token Injection (внедрение поддельного токена доступа)
• Replay Attack (атака повторного воспроизведения)
• Authorization Code Interception (перехват кода авторизации)

nonce (Number used Once)

• Клиент генерирует случайную строку
• Передает ее в запросе на авторизацию
• Клиент проверяет что строка появилась в ID-токене

c_hash (Code Hash)

• Хешируем код авторизации, вставляем его в ID токен на сервере
• Проверяем совпадение на клиенте

at_hash (Access Token Hash)

• Проверяем что access token принадлежит ID-токену
• Хешируем access token и вставляем его в ID токен на сервере
• Проверяем совпадение на клиенте

OAuth/OIDC серьезно поднимает
complexity (сложность)
вашего приложения

Готовые решения

1. Гейткиперы (для ряда решений вроде Keycloack / Ory)
2. Библиотеки

Гейткиперы

Гейткиперы

• Забирает почти всю боль с приложений бэкенда и фронтенда
• Рекомендации по безопасности из коробки
• Нет дублирования кода авторизации в каждом микросервисе

Где посмотреть подробнее:

Готовые библиотеки

1. Стоит доверять в первую очередь сертифицированным и обновляемым решениям
2. Есть несколько сертифицированных поддерживаемых библиотек, но их реализацию под капотом рекомендую просмотреть.

Выводы

• Протоколы oAuth/OIDC иногда over engineering
• Авторизация на сессиях — простая и надежная классикой
• Кастомная реализация на JWT-токенах имеет право на жизнь, но нужно капитально взвесить все "за" и "против".
• Какой бы подход ни был выбран — желательно не хранить токены в localStorage, хранить в httpOnly cookie
• Хороший разработчик должен поверхностно разбираться в вопросах безопасности авторизации

Полезные ссылки

• JWT Attack Playbook
• OWASP JWT Best Practices
• Authjs
• OIDC RFC
• oAuth RFC
• Gatekeeper