Одной из самых значимых новинок является **Demonstration of Proof of Possession (DPoP)**. Классический OAuth 2.0 страдает от уязвимости, когда токен доступа (access token), будучи строкой, может быть перехвачен и повторно использован злоумышленником (replay attack), даже если используется HTTPS. DPoP решает эту проблему, привязывая токен к конкретному клиенту криптографически. Механизм работает так: клиент создаёт пару ключей, а при запросе токена отправляет открытый ключ и доказательство владения приватным ключом (JWT, подписанный этим ключом). Сервер авторизации выдает токен доступа, который привязан (bound) к открытому ключу. Далее, при каждом вызове защищённого ресурса, клиент должен предъявлять свежее доказательство владения (DPoP JWT) вместе с токеном. Сервер ресурсов проверяет, что токен и доказательство связаны одним ключом. Совет: начните изучать DPoP для публичных клиентов (Single-Page Applications, мобильные приложения), где риски компрометации токена наиболее высоки.
Следующее важное расширение — **JWT Secured Authorization Response Mode (JARM)**. Традиционно ответ авторизационного сервера (с кодом или токеном) передаётся через параметры URL или форму POST, что может быть уязвимо для атак, таких как подмена фрагмента URL (fragment injection). JARM шифрует весь ответ авторизации в JWT, который подписывается (а часто и шифруется) ключами сервера авторизации. Это обеспечивает целостность, конфиденциальность и возможность проверки подлинности источника ответа. Совет: если вы разрабатываете сервер авторизации (Authorization Server) для чувствительных данных (финтех, здравоохранение), реализация JARM — это большой шаг вперёд в безопасности.
**Financial Grade API (FAPI)** — это не отдельная спецификация, а профиль безопасности, построенный поверх OAuth 2.0 и OpenID Connect, разработанный OpenID Foundation для высокорисковых сценариев, таких как открытый банкинг. FAPI 2.0 активно продвигает использование DPoP, JARM, а также строгие требования к использованию PKCE (Proof Key for Code Exchange) для всех потоков, обязательное шифрование запросов объектов (Request Object) и многое другое. Совет: даже если вы не работаете в финтехе, изучите требования FAPI — это отличный чек-лист максимальной безопасности для любого enterprise-приложения.
Также стоит отметить растущую популярность **Device Authorization Grant** (поток для устройств с ограниченным интерфейсом, например, Smart TV или IoT) и **Token Exchange** (поток для обмена одного токена на другой, полезный в микросервисных архитектурах).
Помимо новинок, критически важно следовать современным best practices:
- **Всегда используйте PKCE**. Ранее он рекомендовался только для публичных клиентов. Теперь RFC 6749 обновлён, и PKCE настоятельно рекомендуется для *всех* типов клиентов, использующих Authorization Code flow. Это защищает от атак подменой кода авторизации.
- **Откажитесь от Implicit Grant и Resource Owner Password Credentials flows**. Они признаны устаревшими и небезопасными. Используйте Authorization Code Flow с PKCE для веб- и мобильных приложений.
- **Тщательно управляйте жизненным циклом токенов**. Используйте короткоживущие токены доступа (минуты) и механизм refresh token rotation. При использовании нового refresh token всегда отзывайте старый. Это минимизирует окно уязвимости в случае утечки.
- **Валидируйте всё на стороне сервера ресурсов**. Никогда не доверяйте данным, пришедшим от клиента. Всегда проверяйте scope токена, audience (`aud` claim в JWT), issuer (`iss`) и срок действия. Используйте библиотеки, которые делают это автоматически.
- **Защищайте свои эндпоинты**. Эндпоинт токена и эндпоинт авторизации должны быть защищены от DDoS, brute-force и подделки межсайтовых запросов (CSRF для эндпоинта авторизации).
- **Используйте специализированные библиотеки и решения**. Не пишите свою реализацию OAuth 2.0/OpenID Connect с нуля. Для Spring-приложений используйте Spring Authorization Server или проверенные продукты вроде Keycloak, Okta, Auth0, которые уже поддерживают многие современные спецификации.
Комментарии (13)