Как предотвратить уязвимости аутентификации OAuth

Чтобы предотвратить уязвимости аутентификации OAuth, крайне необходимо как для провайдера OAuth, так и для клиентского приложения внедрить надёжную валидацию ключевых входных данных, особенно параметра redirect_uri. В спецификации OAuth практически отсутствует встроенная защита, поэтому именно разработчики должны сделать поток OAuth максимально безопасным.

Важно отметить, что уязвимости могут возникать как на стороне клиентского приложения, так и на стороне самого сервиса OAuth. Даже если ваша реализация выполнена безупречно, вы всё равно зависите от того, что приложение на другой стороне будет столь же устойчивым.

Для провайдеров OAuth

• Требуйте, чтобы клиентские приложения регистрировали белый список допустимых redirect_uris. Где это возможно, используйте строгую посимвольную проверку для валидации URI во всех входящих запросах. Разрешайте только полные и точные совпадения, а не сопоставления по шаблону. Это предотвращает попадание злоумышленников на другие страницы в пределах домена из белого списка.

• Принудительно используйте параметр state. Его значение также должно быть привязано к сеансу пользователя путем включения некоторых непредсказуемых данных, специфичных для сеанса, таких как хэш, содержащий cookie сессии. Это помогает защитить пользователей от атак типа CSRF и делает использование украденных кодов авторизации гораздо более сложным.

• На сервере ресурсов убедитесь, что вы проверяете:

  • что токен доступа был выдан тому же client_id, который сейчас делает запрос;

  • запрошенный scope соответствует scope, для которого изначально выдавался токен.

Для клиентских приложений OAuth

• Убедитесь, что вы полностью понимаете детали работы OAuth до внедрения. Многие уязвимости возникают из-за банального непонимания того, что именно происходит на каждом шаге и как это может быть использовано злоумышленником.

• Используйте параметр state, даже несмотря на то, что он не является обязательным.

• Передавайте параметр redirect_uri не только на конечную точку /authorization, но и на конечную точку /token.

• При разработке мобильных или нативных OAuth‑клиентов зачастую невозможно хранить client_secret в секрете. В этих случаях используйте механизм PKCE (RFC 7636), чтобы обеспечить дополнительную защиту от перехвата или утечки кодов авторизации.

• Если вы используете id_token из OpenID Connect, убедитесь, что он корректно валидируется в соответствии со спецификациями JWS, JWE и OpenID.

• Будьте осторожны с кодами авторизации. Они могут утечь через заголовки Referer, когда загружаются внешние изображения, скрипты или CSS‑контент. Также крайне важно не включать их в динамически генерируемые JavaScript‑файлы, так как они могут быть выполнены с внешних доменов через теги <script>.