Есть несколько других ответов (например: - это и это ), объясняющих фон состояния и как его избежать csrf.
Лучше всего сослаться на то, что дано создателями спецификаций. RFC6810 - Модель угроз OAuth 2.0 и соображения безопасности содержат множество угроз и контрмер для OAuth 2.0.В этом Угроза: CSRF Attack против redirect-uri дает четкий обзор угрозы.Ниже приводится выдержка:
Злоумышленник может авторизовать «код» авторизации для своих собственных защищенных ресурсов на сервере авторизации.Затем он прерывает поток перенаправления обратно на клиент на своем устройстве и заставляет жертву выполнить перенаправление обратно на клиент.Клиент получает перенаправление, получает токены с сервера авторизации и связывает сеанс клиента жертвы с ресурсами, доступными с помощью токена.
Теперь у клиента есть токены, принадлежащие злоумышленнику.Нет, злоумышленник не сможет получить доступ ко всему, что принадлежит клиенту на сервере ресурсов.Но если клиент выполнит операцию сохранения (например, - Создание документа), он будет отправлен злоумышленнику.Теперь злоумышленники получают права доступа к этим недавно созданным ресурсам.Это выделено, как показано ниже:
Эффективное влияние зависит от типа используемого ресурса.Например, пользователь может загружать личные элементы на ресурсы злоумышленника.Или, при использовании OAuth в сторонних сценариях входа, пользователь может связать свою учетную запись клиента с идентификационной информацией злоумышленника во внешнем поставщике идентификационных данных.Таким образом, злоумышленник может легко получить доступ к данным жертвы на клиенте, войдя в систему с другого устройства со своими учетными данными во внешнем провайдере идентификации.
Таким образом, в основном угроза связана со свежими даннымисоздано на сервере ресурсов .